OpenTofu in Production: The First Year After the Fork

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

To migrate an existing Terraform setup:

# Install OpenTofu
brew install opentofu

# Alias for gradual transition
alias terraform=tofu

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

Works first try unless you have private modules or custom backends. 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 if the config has no private modules or custom backends:

• Test tofu commands on an existing Terraform config in an isolated environment.

• Resolve differences (rarely any in 1.6, occasionally in 1.7).

• Update CI/CD to use tofu instead of terraform.

• Update internal documentation.

• 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 take no work unless you have private modules or custom backends. Native state encryption is already a positive reason 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.

Frequently asked questions

Do I have to rewrite my Terraform configurations to move to OpenTofu?

No. OpenTofu 1.6 is drop-in compatible: configs work unchanged, the AWS, Azure or GCP providers are identical, the state format is compatible and the CLI is the same with tofu init, tofu plan and tofu apply. It works on the first try unless the setup has private modules or specific backends; in that case, test first in an isolated staging environment.

How long does a typical Terraform-to-OpenTofu migration take?

It is a days-long project, not weeks. The steps are testing the tofu commands on an existing config in an isolated environment and resolving differences (rarely any in 1.6, occasionally in 1.7). Then you update CI/CD to use tofu instead of terraform, update internal documentation and minimally train the team, since the syntax is identical. The usual tooling (Terragrunt, Atlantis, tfsec, checkov, terraform-docs) works with both.

What does OpenTofu offer that Terraform doesn't?

Native state encryption arrived in OpenTofu 1.7. An encryption block with an aes_gcm method and a key provider such as pbkdf2 leaves the state file encrypted at rest, which in Terraform requires external plugins or manual management. For environments with compliance requirements on secrets in state (DB credentials, API tokens), this feature alone may justify the migration, on top of the MPL 2.0 license and Linux Foundation governance.

Sources

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