OpenTofu vs Terraform in 2026: Is the Fork Worth Switching To?

If you write infrastructure as code, the ground shifted under you in 2023. Terraform — the default IaC tool for a decade — stopped being open source, and the community responded by forking it. That fork is OpenTofu, and by 2026 it is a mature, production-grade tool on version 1.12.

So the real question every platform team is asking: do I stay on Terraform, or switch to OpenTofu? This is an honest, up-to-date answer — why the split happened, what genuinely differs, and when each one is the right call.

Why There Are Suddenly Two Tools

For most of its life, Terraform was licensed under the Mozilla Public License 2.0 (MPL-2.0) — a proper open-source licence. In August 2023, HashiCorp relicensed Terraform (from v1.6 onward) to the Business Source License 1.1 (BUSL) — a source-available licence that restricts competing commercial use. That is not OSI open source.

The community forked the last MPL-2.0 version, and the project — now OpenTofu — moved under the Linux Foundation for vendor-neutral governance. Then IBM announced its acquisition of HashiCorp in 2024 (closed in early 2025), putting Terraform’s stewardship inside a single large vendor. OpenTofu kept going the other direction: open licence, open governance, open registry.

This matters beyond ideology. A BUSL licence changes what your legal team signs off on, what you can build a product around, and whether the tool’s roadmap is controlled by one vendor or a foundation.

What Is Actually the Same

Here is the part the drama obscures: OpenTofu and Terraform are still the same tool underneath. OpenTofu was a fork, not a rewrite. That means they share:

• The HCL configuration language — your .tf files work as-is.
• The provider plugin protocol — the same AWS, Google, Azure, Kubernetes providers run on both.
• The state model, plan/apply workflow, and terraform {} blocks.
• Modules, workspaces, moved/import/check blocks, and a native test framework.

Because the foundation is shared, migration is mostly a drop-in: install OpenTofu, run tofu init against your existing state, and verify with a small change. The official path is safe and reversible.

What OpenTofu Does That Terraform Doesn’t

The fork didn’t just track Terraform — it added features Terraform still lacks in 2026:

• Native state & plan encryption. OpenTofu encrypts state and plan files at rest, client-side, with pluggable key providers — AWS KMS, GCP KMS, Azure Key Vault, OpenBao, or a PBKDF2 passphrase — using AES-GCM. If your state file (full of secrets and access keys) leaks, it’s ciphertext. Terraform has no equivalent; you bolt on backend-level encryption instead.
• Provider iteration with for_each. OpenTofu supports for_each on provider blocks — genuinely useful for multi-region or multi-account setups. It also allows variables in module source and version (dynamic module sources). Terraform still can’t iterate provider configurations.
• The -exclude flag. Target the inverse of a resource set (tofu plan -exclude=...), the complement to -target.
• Early variable evaluation for backend and encryption config, and an open, MPL-licensed provider and module registry (registry.opentofu.org) that isn’t bound by the Terraform Registry’s restrictive terms.

A minimal state-encryption block looks like this:

terraform {
  encryption {
    key_provider "gcp_kms" "prod" {
      kms_encryption_key = "projects/acme/locations/global/keyRings/tofu/cryptoKeys/state"
      key_length         = 32
    }
    method "aes_gcm" "prod" {
      keys = key_provider.gcp_kms.prod
    }
    state { method = method.aes_gcm.prod }
    plan  { method = method.aes_gcm.prod }
  }
}

What Terraform Still Has Over OpenTofu

This isn’t one-sided. Terraform keeps real advantages, mostly around its commercial ecosystem:

• HCP Terraform (formerly Terraform Cloud) and Terraform Enterprise — the managed run environment, private registry, and remote state service, tightly integrated.
• Terraform Stacks — HashiCorp’s higher-level orchestration for managing many configurations together.
• Sentinel — the policy-as-code engine baked into the HCP ecosystem.
• Official vendor support and SLAs from IBM/HashiCorp, which some enterprises contractually require.
• The largest mindshare — tutorials, hiring pool, and third-party integrations still say “Terraform” first.

Side-by-Side: The Full Picture

How to Choose

Decide on dependencies, not on the licence war.

Migrate to OpenTofu if:

• You need a genuinely open-source licence — legal, compliance, or you build a product on top of the tool.
• You want native state encryption without bolting it on.
• You value vendor-neutral governance and an open roadmap.
• You use provider for_each, -exclude, or a platform (Spacelift, env0, Scalr, GitLab, Harness) that already backs OpenTofu.

Stay on Terraform if:

• Your workflow is built on HCP Terraform, Terraform Stacks, or Sentinel.
• You require official IBM/HashiCorp support and SLAs.
• Your organisation mandates the incumbent vendor and you have no compliance pressure to move.

Not sure? Migration is low-risk and reversible, so pilot OpenTofu on one non-critical stack. Because the HCL and providers are identical, the switching cost is genuinely low — that’s the whole point of a compatible fork.

The Field Rule

OpenTofu and Terraform are the same tool wearing different licences and governance. The code you write barely changes; what changes is who controls the tool and how open it is. For a pure IaC workflow with no hard dependency on HCP Terraform, OpenTofu in 2026 is the safer open default — MPL-licensed, foundation-governed, and ahead on state encryption. If you live inside HashiCorp’s commercial platform, Terraform still earns its place. Pick on your real constraints, pilot before you commit, and remember the migration door swings both ways.

If you provision GKE with either tool, pair this with GKE Autopilot vs Standard in 2026 for the cluster-mode decision, and Secure-by-Default GKE Reference Architecture for hardening what your IaC deploys.