One of the most overlooked aspects of managing infrastructure as code is keeping track of version end-of-life dates(EOL/EOS). I once had to scramble through an emergency upgrade when a Terraform version we were running in production reached EOL. Today, let’s dive deep into Terraform’s version support policy and explore how to safely manage versions.
1. What Exactly is Terraform?
Terraform is an Infrastructure as Code (IaC) platform developed by HashiCorp. Simply put, it’s a tool that lets you write and manage infrastructure components like servers, networks, and databases as code.
Instead of clicking through AWS Console or Azure Portal to create resources, Terraform defines the entire process in code. Writing infrastructure as code enables version control, easier team collaboration, and consistent deployment across multiple environments.
Terraform is an infrastructure as code software tool distributed under the BUSL-1.1 license, allowing you to codify APIs through declarative configuration files. Prior to August 2023, it was available under the Mozilla Public License 2.0, but has since switched to the Business Source License.
2. HashiCorp’s Version Support Philosophy – Core Principles You Need to Know
To understand Terraform’s version support policy, you first need to grasp HashiCorp’s overall support philosophy.
HashiCorp provides support for all GA (Generally Available) releases for up to two (2) years. This means from the moment a specific version is officially released, you can receive security patches and critical bug fixes for up to 2 years.
Here’s an important detail: Code fixes and hot-fixes are only provided via new minor releases on the latest “major release” branch, for up to two (2) releases from the most current major release. The versioning follows X.Y.Z format, where changes to X or Y are considered major releases.
For example, if the current latest version is 1.13:
- 1.13.x → Latest version (Full Support)
- 1.12.x → 1 release behind (Support)
- 1.11.x → 2 releases behind (Support)
- 1.10.x and below → Official support ended
For End of Life, HashiCorp provides customers with at least twelve (12) months’ prior written notice. This ensures sufficient time for migration planning.
3. Detailed Release and Support Information for All Terraform Versions
Here’s a comprehensive breakdown of all major Terraform versions as of October 2025.
3-1. Terraform 1.x Versions (June 2021 ~ Present)
Terraform 1.0 achieved Generally Available (GA) status in June 2021, marking a major milestone in workflow maintenance automation, upgrade simplification, and interoperability.
| Version | Latest Patch | Release Date | Expected EOL | Support Status | Key Features |
|---|---|---|---|---|---|
| 1.13 | 1.13.3 | August 2025 | August 2027 | ✅ Active | Stacks command, enhanced filesystem function validation |
| 1.12 | 1.12.2 | May 2025 | May 2027 | ✅ Active | Linux kernel 3.2+ required, cloud integration improvements |
| 1.11 | 1.11.4 | January 2025 | January 2027 | ✅ Active | Module output sensitivity improvements |
| 1.10 | 1.10.5 | November 2024 | November 2026 | ⚠️ Limited | Performance optimizations, bug fixes |
| 1.9 | 1.9.8 | June 2024 | June 2026 | ⚠️ Limited | Test command parallel execution support |
| 1.8 | 1.8.5 | April 2024 | April 2026 | ⚠️ Limited | Provider-defined functions support |
| 1.7 | 1.7.5 | January 2024 | January 2026 | ⚠️ Limited | Config-driven import, remove blocks |
| 1.6 | 1.6.6 | October 2023 | October 2025 | ⚠️ Limited | Test command GA, S3 state locking improvements |
| 1.5 | 1.5.7 | June 2023 | June 2025 | ⚠️ Limited | Import blocks, check blocks added |
| 1.4 | 1.4.7 | March 2023 | March 2025 | ⚠️ Limited | Static evaluation improvements |
| 1.3 | 1.3.10 | September 2022 | September 2024 | ❌ EOL | Optional attributes, function improvements |
| 1.2 | 1.2.9 | May 2022 | May 2024 | ❌ EOL | Precondition/Postcondition |
| 1.1 | 1.1.9 | December 2021 | December 2023 | ❌ EOL | Refactoring blocks, moved blocks |
| 1.0 | 1.0.11 | June 2021 | June 2023 | ❌ EOL | First GA version, compatibility promise begins |
Legend: ✅ Active = Full support, ⚠️ Limited = Limited support (security patches only), ❌ EOL = End of Life
3-2. Terraform 0.x Versions (2014 ~ 2021)
All 0.x versions are now legacy and officially unsupported.
| Version | Final Patch | Release Date | EOL Status | Key Features |
|---|---|---|---|---|
| 0.15.x | 0.15.5 | April 2021 | ❌ EOL | Improved sensitive variable handling, console UTF-8 support |
| 0.14.x | 0.14.11 | December 2020 | ❌ EOL | Introduced lock file (.terraform.lock.hcl) |
| 0.13.x | 0.13.7 | August 2020 | ❌ EOL | Explicit provider source addresses, for_each in modules |
| 0.12.x | 0.12.31 | May 2019 | ❌ EOL | HCL2 syntax improvements, for expressions, dynamic blocks |
| 0.11.x | 0.11.15 | November 2017 | ❌ EOL | Workspaces introduced, module registry |
| 0.10.x | 0.10.8 | August 2017 | ❌ EOL | Provider separation begins |
| 0.9.x | 0.9.11 | March 2017 | ❌ EOL | State environment improvements |
| 0.8.x | 0.8.8 | December 2016 | ❌ EOL | Remote state data source |
| 0.7.x | 0.7.13 | August 2016 | ❌ EOL | Provider plugin architecture |
| 0.6.x and below | – | Before 2016 | ❌ EOL | Initial versions |
Oracle Cloud Infrastructure Resource Manager will stop allowing creation of stacks with Terraform versions earlier than 1.5.x starting November 1, 2025.
3-3. Major Breaking Changes Summary by Version
| Upgrade Path | Key Changes | Difficulty |
|---|---|---|
| 0.11 → 0.12 | Major HCL syntax overhaul, first-class expressions | ⚠️⚠️⚠️ High |
| 0.12 → 0.13 | Explicit provider source required, module for_each | ⚠️⚠️ Medium |
| 0.13 → 0.14 | Lock file introduction, sensitive variable handling | ⚠️ Low |
| 0.14 → 0.15 | Deprecated feature removal | ⚠️ Low |
| 0.15 → 1.0 | Stability enhancements, minimal breaking changes | ✅ Very Low |
| 1.x → 1.y | Compatibility promise maintained, incremental features | ✅ Very Low |
4. Special Support Policy for Terraform Enterprise
Terraform Enterprise users need to be aware of a slightly different support policy.
The Replicated Native Scheduler deployment method for Terraform Enterprise has its final release in March 2025 and will be supported until March 2027. This timeline differs from Terraform OSS, so Enterprise users must pay special attention.
4-1. Terraform Enterprise Key Dates
| Item | Date | Notes |
|---|---|---|
| Final Replicated Release | March 2025 | Migration to FDO recommended |
| Replicated End of Support (EOS) | April 1, 2026 | No security patches after this date |
| Recommended Migration Completion | Before November 2024 | Allow sufficient testing time |
Enterprise users should consider migrating to Flexible Deployment Options (FDO), which support various deployment methods including Docker, Kubernetes, Podman, and Nomad.
References: Terraform Enterprise Releases | HashiCorp Support Policy
5. Terraform Support Status by Cloud Provider
Major cloud providers also maintain their own Terraform version support policies.
5-1. Minimum Supported Versions by Cloud Service
| Cloud Service | Minimum Version | Recommended Version | Notes |
|---|---|---|---|
| AWS (Terraform Cloud) | 1.5.x | 1.11.x or higher | Latest AWS resources recommend 1.9+ |
| Azure (Resource Manager) | 1.0.x | 1.10.x or higher | AzureRM Provider 4.x requires 1.9+ |
| GCP (Cloud Foundation) | 1.3.x | 1.11.x or higher | GKE Autopilot recommends 1.6+ |
| Oracle Cloud Infrastructure | 1.5.x | 1.11.x or higher | Versions below 1.5 blocked from Nov 1, 2025 |
| IBM Cloud Schematics | 0.13.x | 1.9.x or higher | Legacy 0.x support phasing out |
6. How to Prepare for Version Upgrades
When end of support approaches, you need to consider upgrading. Here are some practical tips.
6-1. Check Your Current Version
First, identify which version you’re currently running:
terraform version
This command displays your installed Terraform CLI version and provider versions.
6-2. Step-by-Step Upgrade Strategy
Rather than jumping multiple major versions at once, upgrade incrementally for safety:
- Set up test environment – Test in development before applying to production
- Backup state files – Always backup terraform state files before upgrading
- Check provider compatibility – Verify Terraform and provider version compatibility
- Run plan and verify – Use
terraform planto ensure no unexpected changes - Progressive rollout – Upgrade in small increments
6-3. Using Version Pinning
Explicitly specifying versions in your terraform block ensures the entire team uses the same version:
terraform {
required_version = ">= 1.11.0, < 1.14.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
This prevents issues from unintended version upgrades.
6-4. Version Management in CI/CD Pipelines
In CI/CD environments, use Docker images or version management tools (tfenv, asdf, etc.) to maintain consistent Terraform versions:
# Install specific version with tfenv
tfenv install 1.13.3
tfenv use 1.13.3
7. Risks of Using Unsupported Versions
What problems can arise from continuing to use outdated versions?
Security Vulnerability Exposure Unsupported versions don’t receive patches for newly discovered security vulnerabilities. Security is critical for infrastructure management tools.
Unable to Use New Provider Features When cloud providers launch new services, the supporting providers often require the latest Terraform versions.
Reduced Community Support Finding answers to questions about old versions becomes increasingly difficult on Stack Overflow or GitHub Issues.
Increased Migration Burden The longer you delay version updates, the more work accumulates for eventual upgrades, and breaking changes compound.
8. Frequently Asked Questions (FAQ)
Q. Will upgrading Terraform affect existing infrastructure? A. While state file formats maintain backward compatibility, some providers or syntax may change. Always verify with terraform plan before proceeding.
Q. I’m using a pre-1.0 version. How should I upgrade? A. We recommend upgrading incrementally: 0.15 → 1.0 → 1.5 → 1.11. Consult each version’s Upgrade Guide.
Q. Do Terraform Cloud and Terraform Enterprise have different version policies? A. They generally follow the same policy, but Enterprise’s Replicated deployment has a separate EOL schedule.
Q. Where can I check the list of supported versions? A. endoflife.date/terraform provides real-time updated information.
Q. I’m currently using 1.3 or 1.4. How long is that okay? A. Versions 1.3 and 1.4 have already passed their 2-year support period and are officially EOL. Since you won’t receive security patches, we recommend upgrading to at least 1.11.
While Terraform’s version support policy seems straightforward, operational environments require consideration of provider compatibility, cloud provider support, and team standardization.
The key is regular monitoring and planned upgrades. Start planning your upgrade 6 months before support ends, and proceed safely with thorough testing.
Check your current Terraform version’s support status right now. If you’re running version 1.10 or below, consider upgrading to 1.11 or higher.
Related Resources:
- HashiCorp Official Support Policy
- Terraform Releases Page
- Terraform Version EOL Information
- Terraform Enterprise Releases
- HashiCorp Release Server