Terraform 0.14 reached General Availability on December 02, 2020, as a workflow centric release that hardens provider management, improves plan readability, and adds safety controls for sensitive data. The release is positioned as a final stepping stone toward a 1.0 release of Terraform and is immediately available for download as well as for use in Terraform Cloud. The version continues the stability work started in 0.13 while introducing changes that affect how practitioners run terraform init, terraform plan, terraform apply, and terraform show in interactive use and automation.
Release Context and Positioning
Terraform 0.14 is all about workflow. Practitioners love the Terraform workflow and the HashiCorp team focused on continuing to improve it. The release helps every practitioner make critical decisions about infrastructure with the addition of a concise diff, sensitive input variables, and a provider dependency lockfile. These improvements are designed to help better control Terraform’s behavior in both interactive use and when used in automation.
Forward compatibility for state files is also introduced. Terraform will now support reading and writing all compatible state files, even from future versions of Terraform. This means that users of Terraform 0.14.0 will be able to share state files with future Terraform versions until a new state file format version is needed. There are no plans to change the state file format at this time.
Getting started resources were updated for 0.14 for new and existing users. HashiCorp Learn tutorials were updated for Terraform 0.14. To adopt 0.14 users can download the Terraform 0.14 release and, if upgrading from a previous release, read the upgrade guide to learn how to adopt the new features. The full changelog is available for detailed changes and the release includes code contributions from the community.
Core New Features
The release introduces three headline workflow features that together change day to day Terraform operations.
Concise Diff Renderer
Terraform 0.14 includes a new experimental, on-by-default, concise diff renderer. This small but significant new behavior is designed to help practitioners quickly understand what changes Terraform is about to make to existing infrastructure.
The diff renderer used by terraform plan, terraform apply, and terraform show <planfile> has been updated to hide unchanged and irrelevant fields. If any attributes, collection elements, or blocks are hidden, a count will be kept and displayed at the end of the parent scope.
In Terraform 0.13 the diff output could become unclear due to many modifications and unchanged configuration being displayed. In 0.14 the output is lighter and clearer. The new renderer does not display the unchanged configuration, which makes plan output easier to scan.
Sensitive Input Variables and Propagation
Terraform now supports marking input variables as sensitive, and will propagate that sensitivity through expressions that derive from sensitive input variables. When you mark an input variable or module output as sensitive, Terraform will redact that value from its console output and log files.
This matters because it prevents accidental leakage of secrets like passwords or API keys in your CI/CD logs, logging or version control. Sensitivity propagation means that any expression derived from a sensitive input is also treated as sensitive, reducing manual redaction.
Upgrade notes require attention here. Outputs that reference sensitive values, which includes variables marked as sensitive, other module outputs marked as sensitive, or attributes a provider defines as sensitive if the provider_sensitive_attrs experiment is activated, must also be defined as sensitive, or Terraform will error at plan.
Provider Dependency Lockfile
Terraform 0.14’s new dependency lock file, focused on providers, simplifies managing Terraform automation. Starting in Terraform 0.13, the possibility of installing providers from customer-controlled or third-party remote registries increases the need to be able to replicate Terraform runs in automation. Remote and automated Terraform workflows need to be able to duplicate previous runs exactly.
The dependency lock file launching with Terraform 0.14 is generated automatically when terraform init is run. The generated lockfile should be committed into version control systems so that Terraform can guarantee to select exactly the same provider versions on future runs. The lock file is written to a .terraform.lock.hcl file in the configuration directory.
The lockfile pins the exact versions of all providers used in your configuration. In practice, this means terraform init will install the same provider versions every time, preventing unexpected changes from a new patch version. You have to explicitly run terraform init -upgrade to get newer versions, which is perfect for controlled rollouts.
If you want to retain the previous behavior of always taking the newest version allowed by the version constraints on each install, you can run terraform init -upgrade to see that behavior. Upgrading to a new provider or collection of providers can be completed via terraform init -upgrade.
Before 0.14, if you did not have provider version constraints in your backend file, every terraform init command could upgrade a provider version. This could cause issues like breaking changes in infrastructure and be very painful. Having version constraints is an excellent practice and is recommended as much as possible to have the exact versions you want.
Improvements and Platform Support
Terraform 0.14 also adds official support for Linux ARM64 builds. Linux ARM64 support was added in the latest 0.13.x releases as well.
A community contribution adds two new validation conditions for practitioners using variable validation: any and all. These provide more expressive validation rules.
Core and provider installation behavior is improved. The release also includes improvements to validation rules and bug fixes across core and providers.
Deprecations are introduced with warnings. The version argument inside provider configuration blocks has been documented as deprecated since Terraform 0.12. As of 0.14 it will now also generate an explicit deprecation warning.
Category Summary
The release can be summarized by category for planning upgrades.
| Category | Key Changes |
|---|---|
| New Features | Provider Dependency Lock File, Sensitive Input Variables, Concise Diff |
| Improvements | Core and Provider Installation, Validation Rules |
| Bug Fixes | Various fixes across core and providers |
| Deprecations | Deprecation of certain template functions |
Upgrade Notes and Migration Experience
Migration from 0.13 to 0.14 was reported as smooth in practitioner experience. For one project the migration from 0.13 to 0.14 was very smooth. The only problem encountered was resolved immediately by running terraform fmt. The new features in terraform fmt were noted as pretty cool.
A significant new feature in release 0.14 is the lock file. Terraform now creates a lock file to avoid new potential issues with providers. Before, if you did not have provider version constraints in your backend file, every terraform init command could upgrade a provider version. This could cause issues like breaking changes in your infrastructure and be very painful.
Enhancement: clearer diffs for terraform plan. In Terraform 0.13 the diffs result for terraform plan and terraform apply was not liked by some practitioners. Many modifications can make this representation unclear. Terraform made the improvement a reality with a lighter and clearer output. The diff does not display the unchanged configuration.
Practical Lockfile Workflow
- Run
terraform initto generate.terraform.lock.hcl - Commit the lockfile to version control
- Run
terraform init -upgradewhen you want to intentionally update providers
Example init commands:
terraform init
terraform init -upgrade
Sensitive Variable Declaration
Marking variables as sensitive:
variable "api_key" {
type = string
sensitive = true
}
When used in outputs, the output must also be marked sensitive:
output "secret" {
value = var.api_key
sensitive = true
}
Failure to mark the output as sensitive will cause a plan error when the output references a sensitive value.
Workflow Impact
The combination of concise diff, sensitive variables, and lockfile changes how teams operate in CI/CD and interactive sessions.
The concise diff reduces noise in plan output, allowing faster review of changes. Hiding unchanged and irrelevant fields with a count kept at the end of the parent scope makes large configurations readable.
Sensitive input variables and propagation close a long standing risk of secret leakage in logs and console output. Redaction in console output and log files helps prevent accidental exposure of passwords or API keys.
The provider dependency lockfile brings reproducible builds to Terraform. By pinning exact provider versions and requiring explicit upgrade, teams can prevent unexpected provider upgrades from breaking infrastructure. The lockfile is generated automatically on terraform init and should be committed to version control.
Forward compatible state files reduce friction when sharing state between Terraform versions. Users of Terraform 0.14.0 will be able to share state files with future Terraform versions until a new state file format version is needed.
Conclusion
Terraform 0.14 is a workflow hardening release rather than a flashy feature release. The concise diff renderer improves readability of terraform plan and terraform apply by hiding unchanged fields while keeping counts, which speeds up human review of infrastructure changes. Sensitive input variables with propagation and mandatory sensitive outputs enforce secret hygiene across interactive use and automation, preventing leakage into CI/CD logs and console output. The provider dependency lockfile generated by terraform init and stored as .terraform.lock.hcl provides deterministic provider selection, requiring explicit terraform init -upgrade to change versions and enabling safe controlled rollouts.
Forward compatibility for state files and Linux ARM64 support extend the operational envelope. The addition of any and all validation conditions and continued deprecation warnings for the version argument inside provider configuration blocks show ongoing refinement of the language and core. Practitioner reports of smooth migration from 0.13 to 0.14, often resolved with terraform fmt, suggest low friction adoption.
Together these changes move Terraform closer to production grade collaborative workflows at organizations of all sizes. The release strengthens reproducibility, security, and clarity without changing the fundamental Terraform workflow that practitioners value. For teams running Terraform in automation, committing the lockfile and adopting sensitive variable marking should be immediate priorities to capture the safety gains of 0.14.