What Is New in Terraform 0.6
Terraform 0.6 introduces foundational changes that shift how you manage infrastructure state and dependencies. The focus is on robust state management and explicit resource connections.
| Category | Key Changes |
|---|---|
| New Features | State Management Commands, Explicit DependsOn, Remote State |
| Improvements | Enhanced Provisioner Logging, Interpolation Functions |
| Backwards Incompatibilities | State File Format Change, Provisioner Failure Handling |
How does Terraform 0.6 change state management?
This release adds first-class commands for interacting with the state file. You can now directly manage state without manual file edits.
The new terraform state command includes subcommands like list, mv, rm, and pull/push. This is a game-changer for refactoring; you can rename resources without destroying and recreating them. In practice, this makes large codebase refactoring much safer and less disruptive.
Remote state is now a built-in feature, allowing teams to more easily share state files. This foundational feature sets the stage for future collaboration enhancements.
What is the new depends_on for?
The depends_on parameter lets you explicitly define dependencies that Terraform's graph can't automatically detect.
Before 0.6, Terraform inferred dependencies from interpolations. Now, you can force an order of operations for resources that don't directly reference each other. This is crucial for managing resources that have hidden dependencies, like IAM policies that need to exist before a resource that uses them, even if the ARN isn't directly interpolated.
You use it by adding depends_on = ["module_name.resource_type.name"] to a resource block. This gives you more control over the execution graph.
How did provisioning get better?
Provisioner output is now much more verbose, making debugging failed scripts easier.
Previously, you'd often get a generic failure message. Now, Terraform streams all stdout and stderr output from provisioners like chef, local-exec, and remote-exec directly to the console. This matters because you can see exactly where a bootstrap script is failing instead of guessing.
The behavior on failure has also changed. A failed provisioner now taints the resource by default, ensuring it gets recreated on the next apply.
What are the breaking changes in Terraform 0.6?
The state file format changed, so you must run terraform refresh after upgrading. This is a mandatory one-time migration.
Another key change is how provisioner failures are handled. They now taint the resource, which alters the plan for the next run. If you were relying on the old behavior, you'll need to adjust your workflows.
Always back up your .tfstate file before running the 0.6 version for the first time. The upgrade process is one-way and irreversible with older versions.
FAQ
Do I have to change my state file when upgrading to Terraform 0.6?
Yes. The state file format is incompatible. You must run `terraform refresh` with version 0.6 to migrate your state to the new format. This is a one-way operation.
When should I use the new depends_on parameter?
Use it for hidden dependencies that Terraform can't see. A common example is when one resource's creation script (via provisioner) sets up something that another resource needs, but there's no direct interpolation between them in the config.
Can I still use the old state commands?
The new `terraform state` commands replace the old method of manually editing the state file. The CLI commands are now the supported and safe way to manipulate state.
What happens if my remote-exec script fails now?
The resource it was attached to will be marked as tainted. This means Terraform will plan to destroy and recreate that resource on the next `terraform apply`.
Is remote state storage automatic?
No, you must configure it. The capability is now built-in, but you need to add a `terraform { backend "..." }` configuration block to define where to store the state remotely (e.g., S3, Consul).