Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. The entire lifecycle of Terraform is visualized across release, patch and end-of-life cycles with the latest patch version, the long-term support characteristics and the periods for version provision, maintenance and support.
The product life cycle of Terraform is presented as a visualised product life cycle. You can see all releases with the latest patch version, the long-term support characteristics, orange flag in the green circle, the periods for version provision, maintenance and support. Understanding that visual model is essential for planning upgrades, maintaining compliance, and avoiding unsupported infrastructure runs.
Terraform Release Strategy Overview
HashiCorp will support Generally Available releases of active products for up to two years. Eligible code-fixes and hot-fixes are provided via a new minor release, Z on top of the latest major release branch, for up to two releases from the most current major release. A major release is identified by a change in the first X or second Y digit in the following versioning nomenclature: Version X.Y.Z.
As a best practice, HashiCorp expects customers to stay current within two releases from the latest major release in order to receive optimal support. This expectation is reinforced across documentation for both Terraform core and Terraform Enterprise.
How Does Terraform Handle Version Support and Lifecycle? HashiCorp supports Generally Available releases of Terraform for up to two years. Eligible code fixes and hot fixes are provided via a new minor release Z on top of the latest major release branch, for up to two releases from the most current major release.
Provider maintainers typically cease testing against that branch, so new provider versions may no longer work reliably with your older Terraform core. You can continue running the binary, but you assume all responsibility for stability, security, and compatibility issues going forward.
Hashicorp uses the same support period and EoL Policy for all its products. Terraform Enterprise follows a 2-year Advisory support policy.
Versioning Nomenclature and Support Windows
The versioning nomenclature Version X.Y.Z is central to support eligibility.
- X is the major version digit
- Y is the minor version digit
- Z is the patch version digit
A major release is identified by a change in the first X or second Y digit. A change in Z indicates a patch or hot-fix on the existing major release branch.
Support is delivered on the latest major release branch with eligible code-fixes and hot-fixes provided via a new minor release Z on top of the latest major release branch, for up to two releases from the most current major release.
The policy is summarized in the following table.
| Policy Element | Description |
|---|---|
| GA Support Duration | Up to two years for Generally Available releases |
| Patch Provisioning | New minor release Z on top of latest major release branch |
| Release Window | Up to two releases from the most current major release |
| Major Release Identifier | Change in first X or second Y digit |
| Best Practice | Stay current within two releases from latest major release |
FAQ: How many major releases back does Terraform officially support? HashiCorp provides fixes for up to two releases from the most current major release.
Release Cadence and Frequency
Terraform has a regular release cadence tracked across public release monitoring.
- Frequency: 1 week 2 days
- Last Release: tracked in the release feed
- Stars: 48.8K
- Releases: 457 releases
Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
The release feed shows stability determined by the version string. Recent entries include the following stable and pre-release versions.
| Version | Stability |
|---|---|
| v1.16.0-alpha20260701 | Alpha |
| v1.16.0-alpha20260626 | Alpha |
| v1.16.0-alpha20260624 | Alpha |
| v1.15.7 | Stable |
| v1.16.0-alpha20260617 | Alpha |
| v1.15.6 | Stable |
| v1.16.0-alpha20260603 | Alpha |
| v1.15.5 | Stable |
| v1.15.4 | Stable |
| v1.16.0-alpha20260513 | Alpha |
| v1.15.3 | Stable |
| v1.15.2 | Stable |
| v1.15.1 | Stable |
| v1.15.0 | Stable |
| v1.15.0-rc4 | RC |
| v1.15.0-rc3 | RC |
| v1.14.9 | Stable |
| v1.15.0-rc2 | RC |
| v1.15.0-rc1 | RC |
| v1.15.0-beta2 | Beta |
| v1.14.8 | Stable |
| v1.15.0-beta1 | Beta |
| v1.14.7 | Stable |
| v1.15.0-alpha20260304 | Alpha |
| v1.14.6 | Stable |
The version list illustrates the coexistence of stable patch releases on the 1.15 and 1.14 lines alongside alpha, beta and RC streams for the upcoming 1.16 line.
A specific release entry shows detailed feature content for v1.16.0-alpha20260701.
1.16.0-alpha20260701 (July 01, 2026)
NEW FEATURES:
- Store PlannedPrivate data for providers
- New store block in terraform_data that can handle ephemeral and sensitive values
- Providers can now use nested blocks as computed values
- import: add support for import blocks inside modules
- We now produce builds for Linux s390x (zLinux)
- workspace: The workspace list command can now produce machine-readable output when supplied with the-json flag
- Resource action triggers can now use on_failure modes of halt, taint, or continue
ENHANCEMENTS:
- feat(cli): terraform state show accepts a -json flag
- Show info when resources are left behind due to skip_cleanup
- Action configuration now has a new caller symbol which contains the object value from the calling resource
- Actions can now use beforedestroy and afterdestroy events
- cloud: Render a summary of Terraform policy evaluation outcomes for plan and apply runs against HCP Terraform
- policy: Resolve the policy plugin entitlement (host, token, organization) from the configured cloud/remote backend for init, plan, and apply, instead of the plugin reading credentials itself
- child module outputs with unreferenced deprecated nested attributes no longer return deprecation warnings
This level of detail is typical for alpha releases and illustrates the feature velocity that precedes a stable release.
Terraform Enterprise Release Streams
Terraform Enterprise Releases table shows Terraform Enterprise releases, deployment methods, and prerequisites. Each version links to detailed release notes, which are also available in the sidebar navigation.
Below is a list of the most recent Terraform Enterprise Releases that can deploy Terraform Enterprise natively in a Kubernetes environment.
- Refer to 2.0.x for details
- Refer to 1.2.x for details
- Refer to 1.1.x for details
- Refer to 1.0.x for details
Terraform Enterprise follows the same two-year Advisory support policy applied across HashiCorp products. The Enterprise release streams are tracked separately from core Terraform but align with the overall support windows.
The Enterprise release page provides deployment method information and prerequisites for each version family. Teams using Kubernetes native deployments reference the 2.0.x, 1.2.x, 1.1.x and 1.0.x lines for compatibility.
Checking Installed Version and Maintaining Support
How Do You Check Your Current Terraform Version?
Run the following command in your terminal to see the installed version:
terraform version
For JSON output including provider versions, use:
terraform version -json
Include this check early in your CI/CD pipeline to ensure you are always running a supported release.
Show Product Identifiers is available via:
terraform --version
A JSON version of this page is available. You can subscribe to the RSS feed or to the iCalendar feed for release notifications.
You should be running one of the supported release numbers listed above in the rightmost column.
Maintaining a supported release is a operational requirement. Continuing to run an unsupported binary means you assume all responsibility for stability, security, and compatibility issues going forward.
Pre-release Stability Channels
Stability is determined by the version string and may be inaccurate for some feeds. Pre-release channels are part of the normal release flow.
- Alpha releases such as v1.16.0-alpha20260701, v1.16.0-alpha20260626, v1.16.0-alpha20260624, v1.16.0-alpha20260617, v1.16.0-alpha20260603, v1.16.0-alpha20260513, v1.15.0-alpha20260304 are early feature previews
- Beta releases such as v1.15.0-beta2, v1.15.0-beta1 provide feature complete testing
- RC releases such as v1.15.0-rc4, v1.15.0-rc3, v1.15.0-rc2, v1.15.0-rc1 indicate release candidate builds
- Stable releases such as v1.15.7, v1.15.6, v1.15.5, v1.15.4, v1.15.3, v1.15.2, v1.15.1, v1.15.0, v1.14.9, v1.14.8, v1.14.7, v1.14.6 are Generally Available
The coexistence of multiple stable lines demonstrates the two-release support window in practice. While 1.15 receives active patches, 1.14 remains within the support window until the window expires.
Support Implications for Providers and Workloads
Provider maintainers typically cease testing against that branch, so new provider versions may no longer work reliably with your older Terraform core.
This means that even if Terraform core remains functional, provider compatibility can degrade. Teams should track both Terraform core version and provider version matrices.
The support policy also covers hot-fixes. Eligible code-fixes and hot-fixes are provided via a new minor release Z on top of the latest major release branch, for up to two releases from the most current major release.
This ensures critical security and stability issues are addressed without requiring an immediate major version migration, provided the installation is within the supported window.
Conclusion
The Terraform release model balances rapid feature delivery with a defined support horizon. Generally Available releases are supported for up to two years, with eligible code-fixes and hot-fixes provided via new minor release Z on top of the latest major release branch for up to two releases from the most current major release. A major release is identified by a change in the first X or second Y digit in Version X.Y.Z.
Best practice is to stay current within two releases from the latest major release in order to receive optimal support. The release cadence of approximately one week two days, with 457 releases tracked and 48.8K stars, reflects active development. Stability channels from alpha through RC to stable allow early testing while production workloads remain on stable patch lines such as 1.15.7, 1.15.6 and 1.14.9.
Terraform Enterprise maintains its own release streams for Kubernetes native deployments with 2.0.x, 1.2.x, 1.1.x and 1.0.x references, following the same two-year Advisory support policy. Checking version with terraform version and terraform version -json should be integrated into CI/CD pipelines to ensure supported releases are used.
Provider compatibility and testing cessation outside the support window means unsupported core versions carry operational risk even if the binary continues to run. Staying within the defined support window is the primary mechanism for stability, security and compatibility assurance.