What Is New in Terraform 0.11
Terraform 0.11 brings a major new workflow feature with first-class modules and a host of core improvements. Here's a summary of the key changes.
| Category | Key Changes |
|---|---|
| New Features | First-class modules, terraform init command |
| Core Enhancements | Improved plan output, ignore_changes wildcards |
| Provider Updates | New Google Cloud DNS provider, AWS S3 bucket improvements |
| Backend & Remote State | Azure Storage Account backend support |
| Bug Fixes | Numerous fixes across core and providers |
How does first-class module support change my workflow?
This is the headline feature. You can now directly reference modules from Terraform registries or version control systems without manually managing their source code. The new terraform init command automatically handles downloading and installing these modules, along with providers.
In practice, this means your root configuration can be much cleaner. Instead of cloning modules locally, you reference them directly like source = "terraform-aws-modules/vpc/aws". This makes sharing and reusing modules across teams significantly easier.
What core improvements make debugging easier?
The plan output got a major readability upgrade. It now uses a tree structure to show the relationship between resources, which is a huge help for understanding complex changes, especially when modules are involved.
Another small but powerful change is the ignore_changes wildcard. You can now use ignore_changes = all to ignore all attribute changes on a resource, instead of listing each one individually. This is great for managed resources where external processes might modify tags or other metadata.
Which provider updates should I know about?
The new Google Cloud DNS provider (google-dns) splits out DNS functionality from the main Google provider, allowing for more focused management and independent versioning.
The AWS provider added the ability to force destroy an S3 bucket even if it's not empty. This is a destructive but sometimes necessary option for cleaning up test environments. Always double-check you're not in production before using it.
Are there any new remote state options?
Yes, the backend support expanded to include Azure Storage Accounts. You can now configure remote state using the azurerm backend type, which integrates seamlessly with Azure's infrastructure.
This matters because it provides a native, reliable option for teams standardizing on Azure for their Terraform state storage, alongside the existing support for S3, Consul, and others.
FAQ
Do I have to use the new terraform init command?
Yes. This new command is now mandatory before running terraform plan or terraform apply. It's responsible for installing both providers and modules, replacing the old ad-hoc method of fetching them.
Is the module registry feature only for HashiCorp's public registry?
No. While the public registry is the default, you can also reference modules directly from version control systems like GitHub, Bitbucket, and GitLab, or from private registries using a different source string.
Can I still use local module paths?
Absolutely. The new module system is backward compatible. You can continue to use local relative paths (e.g., source = "./modules/vpc") exactly as you did before.
What happens to the old terraform get command?
It's been deprecated and replaced by terraform init. The new command does everything the old one did, plus handles provider installation.
Will the new plan output break my existing CI/CD scripts?
Potentially, yes. If your automation scripts parse the specific text output of terraform plan, you will need to update them to handle the new structured tree format.