OpenTofu in Production: The First Year After the Fork

Actualizado: 2026-05-03

OpenTofu^[1] forked Terraform in August 2023 after HashiCorp’s license change to BSL (non-OSI). Linux Foundation took governance, with AWS, GCP, Oracle, Datadog and the community backing. Reached GA as version 1.6 in January 2024, and 1.7 in May 2024 brought the first real feature divergence. Six months post-GA: stable drop-in replacement or diverging ecosystem?

Key takeaways

• OpenTofu 1.6 is drop-in compatible with Terraform: same configs, same state format, same CLI syntax.
• OpenTofu 1.7 introduced native state encryption, the first exclusive feature with a real technical advantage over Terraform.
• Typical migration is a days-long project, not weeks.
• For new projects, OpenTofu is the reasonable default if there is no prior HashiCorp contract.
• Startups and mid-size are actively migrating; large enterprises with HashiCorp contracts are staying on Terraform.

Compatibility state

OpenTofu 1.6 (January 2024): Terraform 1.6 fork. Drop-in compatible on all dimensions:

• Terraform configs work unchanged.
• Providers (AWS, Azure, GCP, etc.) are identical.
• State format compatible.
• Identical CLI syntax: tofu plan, tofu apply.

OpenTofu 1.7 (May 2024): first real divergence:

• Native state encryption: exclusive feature Terraform lacks without external plugins.
• More flexible provider iteration.
• Improved error messages.

Terraform 1.7 and 1.8 also added their own features. Paths are beginning to separate.

OpenTofu versus Terraform in production

Drop-in migration

For most Terraform setups:

# Install OpenTofu
brew install opentofu

# Alias for gradual transition
alias terraform=tofu

# Works the same as before
tofu init
tofu plan
tofu apply

Typically works first try. Configs do not change. State compatible. For more complex setups with private modules or specific backends, test in an isolated staging environment first.

State encryption: the first real advantage

The most important feature of OpenTofu 1.7 is native state encryption:

terraform {
  encryption {
    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 is encrypted at rest. Before OpenTofu 1.7, this required external plugins or manual management. For environments with compliance requirements that secrets in state (DB credentials, API tokens) be encrypted, this feature alone may justify migration.

Current adoption

Cloud providers:

• AWS: OpenTofu in official documentation.
• Google Cloud: documented support.
• Oracle: strong backer from the start.
• DigitalOcean, Linode, Vultr: documented support.

IaC CI/CD managed services:

• Env0^[2]: OpenTofu support.
• Spacelift^[3]: OpenTofu support.
• Scalr^[4]: OpenTofu support.
• HashiCorp Cloud: no — Terraform only. The SaaS is tied to the vendor.

Public real cases: Cloudflare, Bumble and DigitalOcean have migrated to OpenTofu internally.

When to migrate to OpenTofu

Valid reasons:

• BSL license is unacceptable for your company (OSS-first policy, redistribution).
• You want Linux Foundation governance instead of a single-vendor control.
• You need native state encryption.
• You want to hedge against HashiCorp’s future direction under IBM.

When to stay on Terraform

Valid reasons:

• You have an active HashiCorp Enterprise contract with SLA.
• You use HCP Terraform (the SaaS) with features that have no equivalent.
• Your audit or compliance requires “Terraform” by specific name.
• The team has too much operational load for a migration right now.

Tools ecosystem

Most tooling is agnostic:

• Terragrunt^[5]: supports both Terraform and OpenTofu.
• Atlantis^[6]: both.
• tfsec^[7] and checkov^[8]: security scanning on both.
• terraform-docs^[9]: works with both.

To combine OpenTofu with configuration management, see the article on Ansible and Pulumi: the same dynamic inventory pattern applies with OpenTofu.

Typical migration plan

A days-long project in most cases:

1. Test tofu commands on an existing Terraform config in an isolated environment.
2. Resolve differences (rarely any in 1.6, occasionally in 1.7).
3. Update CI/CD to use tofu instead of terraform.
4. Update internal documentation.
5. Train the team (minimal — syntax is identical).

Conclusion

OpenTofu in production is stable and growing reality. For new projects, it is the reasonable default: free, Linux Foundation governance, sufficient feature parity with Terraform. Migrations from Terraform are trivial in most cases. Native state encryption already provides positive reasons to prefer OpenTofu beyond just the license. Terraform remains valid for those with a specific reason (active contract, HCP SaaS). For the open-source community, the fork was healthy: it showed open licenses are defensible.

1. OpenTofu
2. Env0
3. Spacelift
4. Scalr
5. Terragrunt
6. Atlantis
7. tfsec
8. checkov
9. terraform-docs