Terraform 0.13 Release Engineering and Upgrade Pathways

Terraform 0.13 is a major release that builds on the language improvements introduced in 0.12 with a focus on module-specific workflows and enhancements to the provider ecosystem. The release is in general availability and is immediately available for download as well as for use in Terraform Cloud. It is the first major release featuring terraform login, which makes it simple to collaborate using Terraform Cloud.

Release Highlights and Module-Centric Workflows

The 0.13 release builds on the powerful language improvements made with 0.12.

Improvements to modules

Module-centric workflows are getting a boost with the count, dependson and foreach features of the Terraform configuration language.

Illustrative example only

locals { resources = { eks-prod = "prod-eks" eks-qa = "qa-eks" eks-dev = "dev-eks" } } module "my-cluster" { source = "terraform-aws-modules/eks/aws" for_each = local.resources cluster_name = each.value cluster_version = "1.17" ... worker_groups = [ { name = each.key instance_type = var.instance_type asg_max_size = 5 } ] }

Automatic Installation of Third-Party Providers

Terraform 0.13 also brings with it a new required providers block. We’ve also backported these changes to Terraform 0.12 to help ease the transition.

Getting Started

We have many resources available for 0.13 for new and existing users. To learn more about the new functionality of 0.13 you can:

Try our HashiCorp Learn tutorials, which have been updated for Terraform 0.13

To get started using 0.13:

Download the Terraform 0.13 release.

If you are upgrading from a previous release, read the upgrade guide to learn about the required upgrade steps.

For more details, please see the full changelog. This release also includes a number of code contributions from the community and wouldn't have been possible without all of the great community feedback we've received via GitHub issues and elsewhere. Thank you!

HashiCorp Terraform 0.13 is the next step on our way to solidifying the Terraform ecosystem and empowering collaborative workflows at organizations of all sizes. You can download Terraform 0.13 here and sign up for a Terraform Cloud account here.

Preparing for an Upgrade from 0.12 to 0.13

Upgrading your Terraform code from version 0.12 to 0.13 might be a very daunting task for developers and DevOps professionals who want to take advantage of the latest features and improvements in Terraform. In this comprehensive guide, we will walk you through the process of updating your Terraform code from 0.12 to 0.13, provide code examples, and highlight the key differences between Terraform version 0.12 and 0.13.

Preparing for the Upgrade

Before you begin the upgrade process, it's crucial to prepare your environment to ensure a smooth transition. Start by backing up your existing Terraform code and state files. Using a version control system like Git can help you track changes and revert back if necessary.

Step 1: Install Terraform 0.13

To upgrade to Terraform 0.13, you first need to install the new version.

Practical Installation and Test Setup for 0.13

This repository contains some Terraform 0.13 examples that demonstrate new features added in that release.

These examples have been tested with terraform 0.13.0-beta2 which you can download from here.

The examples are:

• Determine the location of the Terraform binary in your path. On a Mac of Linux machine, run
  which terraform
  . On a Windows machine, runwhere terraform
  .
• Rename your current terraform binary so you can restore it after using the Terraform 0.13 binary if you want to revert back to an earlier version.
• On a Mac or Linux machine, rename the
  ~/.terraform.d
  directory to something like.terraformd
  ; on a Windows machine, rename%USERPROFILE%\terraform.d
  to%USERPROFILE%\terraformd
  . This way, you can restore the directory (if anything was in it) after the class.
• Download the current Terraform 0.13.x zip file for your OS from https://releases.hashicorp.com/terraform/.
• Unzip the file and copy the terraform or terraform.exe binary to the location where your original terraform binary was. If you did not previously have the terraform binary deployed, copy it to a location within your path or edit your PATH environment variable to include the directory you put it in.
• Clone this repository to your laptop with the command
  git clone https://github.com/hashicorp/terraform-guides.git

Provider Namespace Resolution and State Migration

For providers that were automatically-installable in Terraform 0.12, Terraform 0.13 can automatically determine the new addresses for these using a lookup table in the public Terraform Registry. That lookup table is accessed by using the special namespace -.

When you run init, terraform generates a list of required providers based on both the configuration and state. Legacy-style providers - such as providers in a statefile written with Terraform v0.12 - don't have a namespace, so terraform uses the placeholder namespace - to query the registry. That is why you may see output like this during your first init:

• Finding latest version of -/null...
• Finding latest version of -/random...
• Finding latest version of hashicorp/null...
• Finding latest version of hashicorp/random...

Terraform found providers null and random in the statefile without a namespace. Terraform also found hashicorp/null and hashicorp/random in the configuration files. Providers in configuration are automatically assumed to be default HashiCorp providers, while providers found in state are first looked up in the registry.

While this does not cause any problems for Terraform, it has been confusing.

State replace-provider workflow

After the command succeeds the latest state snapshot will use syntax that Terraform v0.12 cannot understand, so you should perform this step only when you are ready to permanently upgrade to Terraform v0.13.

terraform state replace-provider 'registry.terraform.io/-/happycloud' 'terraform.example.com/awesomecorp/happycloud'

The command above asks Terraform to update any resource instance in the state that belongs to a legacy non-namespaced provider called "happycloud" to instead belong to the fully-qualified source address terraform.example.com/awesomecorp/happycloud.

Whereas the configuration changes for provider requirements are made on a per-module basis, the Terraform state captures data from throughout the configuration and so you only need to run terraform state replace-provider once per configuration.

Running terraform init again after completing this step should cause Terraform to attempt to install terraform.example.com/awesomecorp/happycloud and to find it in the local filesystem directory you populated in an earlier step.

Action: If you use in-house providers that are not installable from a provider registry and your existing state contains resource instances that were created with any of those providers, use the terraform state replace-provider command to update the state to use the new source addressing scheme only once you are ready to commit to your v0.13 upgrade

Version Availability Summary

Package metadata for Terraform releases is tracked in community repositories. The Chocolatey package listing provides version history for Terraform.

The table above reflects the Chocolatey package index entries for recent Terraform releases.

Upgrade Checklist and Operational Notes

• Back up existing Terraform code and state files before any upgrade.
• Use a version control system like Git to track changes and revert if necessary.
• Install Terraform 0.13 binary and isolate previous binary for rollback.
• Rename ~/.terraform.d or %USERPROFILE%\terraform.d to preserve existing plugin cache.
• Run terraform init to observe provider lookup messages with the - namespace.
• Generate a required providers block for module-level provider requirements.
• Use terraform state replace-provider only when ready to permanently leave 0.12 compatibility.
• Validate module workflows with count, dependson and foreach in test configurations.
• Review the full changelog and upgrade guide before production adoption.

Conclusion

Terraform 0.13 consolidates language improvements from 0.12 into a release centered on module usability, provider automation, and collaborative workflows. The introduction of terraform login, required providers block, and automatic third-party provider installation changes how teams manage provider sources and state. The placeholder namespace - used during the first init provides a bridge for legacy state files while the registry lookup resolves addresses. Practical upgrade steps emphasize binary isolation, backup of code and state, and careful use of terraform state replace-provider to update source addressing. The release examples tested with terraform 0.13.0-beta2 demonstrate new features in a controlled environment, and the documented installation procedures allow safe parallel testing before committing to a permanent 0.13 migration. These capabilities together solidify the Terraform ecosystem for organizations of all sizes.

Sources

1. HashiCorp Blog
2. Linux Tech Lab
3. HashiCorp GitHub
4. DevNet Expert Training Docs
5. Chocolatey Community