OpenTofu forked Terraform in August 2023 after HashiCorp’s license change to BSL (non-OSI). Linux Foundation took governance, with AWS, GCP, Oracle, Datadog, and community backing. Reached GA as 1.6 in January 2024 and 1.7 in May 2024 brought first feature divergence. Six months post-GA: stable drop-in replacement or diverging ecosystem?
Compatibility State
OpenTofu 1.6 (January 2024): Terraform 1.6 fork. Drop-in compatible:
- Terraform configs work unchanged.
- Providers (AWS, Azure, GCP, etc) identical.
- State format compatible.
- Identical CLI syntax (
tofu plan,tofu apply).
OpenTofu 1.7 (May 2024): first divergence:
- Native state encryption.
- More flexible provider iteration.
- Some error-message improvements.
Terraform 1.7 and 1.8 added their own features. Paths starting to diverge.
Terraform vs OpenTofu in 2024
| Aspect | Terraform 1.8 | OpenTofu 1.7 |
|---|---|---|
| License | BSL (not OSI) | MPL 2.0 |
| Governance | HashiCorp (IBM) | Linux Foundation |
| Registry | Terraform Registry | OpenTofu Registry |
| Providers | 3500+ | TF-compatible |
| State encryption | Not native | Native |
| Cloud features | HCP Terraform | — |
| Community | Large, declining | Growing |
| Enterprise support | HashiCorp Cloud/Terraform | Community / Env0, Spacelift, others |
Drop-In Migration
For most Terraform setups:
# Stop using Terraform
# Install OpenTofu
brew install opentofu
# Rename commands
alias terraform=tofu
# Apply as before
tofu init
tofu plan
tofu apply
Typically works first try. Configs don’t change. State compatible.
New OpenTofu Features
State Encryption
Native in 1.7:
terraform {
encryption {
method "unencrypted" "migrate" {}
method "aes_gcm" "secure" {
keys = key_provider.pbkdf2.mykey
}
key_provider "pbkdf2" "mykey" {
passphrase = var.encryption_passphrase
}
state {
method = method.aes_gcm.secure
}
}
}
State file encrypted at-rest. Previously required external plugins.
Removed Block
removed {
from = aws_instance.old_server
}
Cleaner syntax to remove resources from state without destroying.
2024 Adoption
Cloud providers:
- AWS: OpenTofu in official documentation.
- Google Cloud: similar.
- Oracle: strong backer.
- DigitalOcean, Linode, Vultr: supported.
Managed services:
Enterprises:
- Tangible adoption but not universal.
- Startups and mid-size actively migrating.
- Large enterprises with HashiCorp contracts staying Terraform.
Provider Registry
Terraform Registry remains canonical. OpenTofu Registry compatible mirror.
In 1.7, OpenTofu can install providers from Terraform Registry or own. Most use Terraform Registry for now.
For enterprise (private) registries, most work with both.
Why Migrate?
Valid reasons:
- Legal: BSL not acceptable for some OSS-first enterprises.
- Governance: Linux Foundation vs single-company control.
- Specific features: state encryption if needed.
- Future-proof: hedge against HashiCorp direction.
Why Stay with Terraform?
Valid reasons:
- Existing HashiCorp contract.
- HCP Terraform (the SaaS) has unique features.
- Larger ecosystem (though closing).
- Stability: Terraform has more production time in BSL version.
For most, OpenTofu is safe choice. Terraform continues for those with specific reason.
Migration Path
Plan:
- Test: run
tofucommands on existing Terraform config. - Resolve differences (rarely any).
- Update CI/CD to use
tofu. - Update docs.
- Train team (minimal — same syntax).
Days, not weeks, in most cases.
Features That Will Continue Diverging
OpenTofu 1.8+ plans:
- More flexible provider signing.
- Async plan for large plans.
- Continuously better error messages.
Terraform maintains its separate roadmap with HCP integration as focus.
Tools Ecosystem
Many tools adapt to both:
- Terragrunt: supports Terraform and OpenTofu.
- Atlantis: both.
- tfsec / checkov: security scanning both.
- terraform-docs: works with both.
Tool ecosystem agnostic — smart strategy.
Real Cases
- Cloudflare: migrated to OpenTofu.
- Bumble: public adopters.
- DigitalOcean: uses OpenTofu internally.
- Many startups: default OpenTofu.
Cases Where Terraform Still Wins
- HCP Terraform adoption: the SaaS is Terraform-only.
- Enterprise with contracts: value of commercial support.
- Specific compliance: if audits accept only Terraform by name.
Conclusion
OpenTofu in 2024 is stable and growing reality. For new projects, it’s the reasonable default — free, community-governed, sufficient feature parity. Terraform migrations are trivial in most cases. Diverging features (state encryption) already give positive reasons to prefer OpenTofu beyond just license. Terraform remains valid but with commercial-first trajectory. For OSS community, the fork was healthy — showed open licenses are defensible, incentivising other vendors to think carefully.
Follow us on jacar.es for more on IaC, OpenTofu, and open-source governance.