OpenTofu Reaches 2.0 Maturity — and It Is Now the Smarter Alternative to Terraform

In August 2023, HashiCorp switched Terraform from the MPL 2.0 open-source license to the Business Source License 1.1 (source-available). In February 2025, IBM closed its $6.4 billion acquisition of HashiCorp. In May 2026, OpenTofu shipped version 1.12 with native state encryption, the -exclude flag, provider for_each, and early variable evaluation — four features Terraform’s open-source CLI still does not offer.

The fork is three years old now. The picture is clear: OpenTofu is no longer the resentment fork — it is the sensible fork.

Why the fork still exists — and why it is winning

The OpenTofu-versus-Terraform conversation has shifted. In 2023, the fork was a defensive reflex: a community refusing to work under a license that bans building a competing product. In 2026, it is a project that has pulled ahead of Terraform on multiple technical fronts.

OpenTofu sits under the CNCF within the Linux Foundation, governed by a multi-company Technical Steering Committee. No single entity can change its license or redirect its roadmap. Terraform, meanwhile, is an IBM product under the BSL 1.1 — the source is visible, but each release only converts back to MPL four years after it ships. For any SaaS or platform that bundles infrastructure automation, that is a real legal exposure.

Compatibility is near-total. OpenTofu was forked from Terraform 1.5.x, the last MPL release, and reads the same state format (.tfstate JSON). Providers from the Terraform registry work unmodified. HCL syntax is identical. The binary is called tofu instead of terraform — that is the only visible day-to-day change.

What OpenTofu has that Terraform still does not

The divergence is not about syntax. It is about features the community asked for over years — features HashiCorp deprioritized in favor of HCP Terraform (formerly Terraform Cloud).

Native state encryption

Your state file holds everything: resource identifiers, sensitive outputs, sometimes API keys. By default, it sits in plaintext in your backend. If someone reads your S3 bucket, they read your state.

OpenTofu 1.7 introduced native at-rest encryption, including for remote state and plans. You configure a key provider — AWS KMS, GCP KMS, Vault, or a passphrase — and OpenTofu handles the rest.

terraform {
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abcd-1234"
      region     = "us-east-1"
      key_spec   = "AES_256"
    }

    method "aes_gcm" "main" {
      keys = key_provider.aws_kms.main
    }

    state {
      method = method.aes_gcm.main
    }

    plan {
      method = method.aes_gcm.main
    }
  }
}

Terraform’s open-source CLI has no equivalent. To get encryption, you need HCP Terraform — a paid product.

provider for_each and -exclude

OpenTofu lets you define multiple provider instances and iterate over them — the clean answer to the old problem of managing one provider per region or account without copy-pasting blocks. The -exclude flag is the inverse of -target: it lets you plan or apply everything except a resource you want to leave alone.

# Apply everything except the database, handled separately
tofu apply -exclude=aws_db_instance.primary

Early variable evaluation

OpenTofu evaluates variables earlier than Terraform, which means you can use them in module source and backend configuration — two places where Terraform still rejects them. An entire class of workarounds disappears.

The removed block with destroy = false

Introduced in v1.12 (May 2026), the removed block lets you take a resource out of state without destroying it, declaratively. The old way required a manual terraform state rm.

removed {
  from = aws_instance.legacy_server

  lifecycle {
    destroy = false
  }
}

None of these features justifies a migration on its own. Together, they show the fork is shipping real value — not just chasing compatibility.

The migration is a non-event

This is the part most teams get backwards. They treat the migration as the risk. It is not.

Terraform and OpenTofu share the same state format. Migrating means swapping the terraform binary for tofu, running tofu init, then tofu plan. If the plan shows zero changes, the migration is clean.

# 1. Back up your state
terraform state pull > terraform.tfstate.backup

# 2. Install OpenTofu
curl -fsSL https://get.opentofu.org/install-opentofu.sh | bash

# 3. Initialize
tofu init

# 4. Verify — a clean plan shows no changes
tofu plan

# 5. Update CI/CD: replace terraform with tofu

The migration is reversible as long as you do not adopt OpenTofu-only features. The real lock-in starts when you enable native state encryption: at that point, going back to Terraform requires decrypting and migrating state by hand.

The real cost of staying on Terraform

Staying on Terraform in 2026 is not free either. The cost plays out on three fronts.

First, licensing. The BSL 1.1 forbids using Terraform to build a competing product. The language is intentionally broad. If your company builds a platform that exposes IaC to its customers, the legal risk is real. OpenTofu, under MPL 2.0, has no such restriction.

Second, encryption. Without HCP Terraform, your state is plaintext. Encrypting the S3 bucket is not enough: state stays readable to anyone with access to the bucket. OpenTofu’s application-layer encryption protects even against a compromised backend.

Third, governance. IBM controls Terraform’s roadmap. The recent track record shows community features (state encryption, -exclude) deprioritized in favor of HCP Terraform integration. With OpenTofu, governance is open and multi-company.

Replacing Terraform Cloud without losing capabilities

Switching to OpenTofu cuts access to HCP Terraform (née Terraform Cloud). Here is what replaces it, depending on your scale.

For a team of 5 to 20 people, the S3 + DynamoDB + GitHub Actions + Atlantis stack costs under $50 per month and covers 90% of the needs teams pay HCP Terraform for. Spacelift and env0 go upmarket with drift detection, OPA policies, and approval workflows — at a competitive price versus HCP Terraform.

# S3 + DynamoDB backend — zero recurring cost beyond storage
terraform {
  backend "s3" {
    bucket         = "my-tofu-state"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tofu-state-lock"
    encrypt        = true
  }
}

Verdict

OpenTofu is now the rational default for any new IaC project — and a legitimate migration target for existing Terraform estates.

The decision turns on three criteria:

• You are starting a new project. Pick OpenTofu. Native encryption, no license restrictions, and open governance have no equivalent on the Terraform side. You will never have to ask the fork question.
• You have an existing Terraform estate with no dependency on HCP Terraform. Migrate in batches. Start with staging environments, validate with tofu plan, then flip production. The migration is a binary swap.
• You are locked into HCP Terraform by contract or non-substitutable features. Stay, but audit your dependency. Every HCP-exclusive feature is a future exit cost. Evaluate Spacelift or env0 for new projects.

OpenTofu is no longer the resentment fork. With v1.12 in May 2026, the CNCF behind it, and three years of releases pulling ahead of Terraform on real features, it has become the sensible fork.

References

• OpenTofu v1.12 Release Notes — May 2026
• OpenTofu in 2026: Should You Switch from Terraform — DevOps Daily, June 2026
• OpenTofu and the Future of Infrastructure as Code After Terraform’s License Change — Dev Note, May 2026
• OpenTofu vs Terraform: The 2026 Comparison for Linux Admins — FOSS Linux, April 2026
• OpenTofu official documentation — accessed May 2026
• HashiCorp License Change (BSL) — August 2023
• IBM Completes Acquisition of HashiCorp — February 2025