---
title: "OpenTofu vs Terraform in 2026: Is the Fork Worth Switching To?"
description: "OpenTofu vs Terraform in 2026: why the fork happened, what actually differs (state encryption, provider for_each, licensing), a comparison table, and an honest verdict on switching."
author: Aleksei Aleinikov
date: 2026-07-17
lang: en
tags: [opentofu, terraform, infrastructure-as-code, iac, opentofu-vs-terraform, devops, hashicorp]
canonical: https://www.alekseialeinikov.com/en/blog/topics/devops/opentofu-vs-terraform-2026
source: alekseialeinikov.com
---

# 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.

![Timeline of the fork: Terraform up to 1.5 was MPL; in August 2023 HashiCorp relicensed to BUSL and the community forked the last MPL version into OpenTofu under the Linux Foundation. Terraform went to HCP Terraform and IBM ownership; OpenTofu added state encryption and reached 1.12.](https://www.alekseialeinikov.com/blog/opentofu-fork-timeline-2026.webp)

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.

![Three-column comparison: OpenTofu-only features (state encryption, provider for_each, -exclude, open registry), shared foundation (HCL, providers, plan/apply, modules, testing), and Terraform-only features (HCP Terraform, Stacks, Sentinel, official support).](https://www.alekseialeinikov.com/blog/opentofu-vs-terraform-features-2026.webp)

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:

```hcl
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

| | **OpenTofu** | **Terraform** |
|---|---|---|
| **Licence** | MPL-2.0 (open source) | BUSL 1.1 (source-available) |
| **Governance** | Linux Foundation (vendor-neutral) | HashiCorp / IBM (single vendor) |
| **Current version (2026)** | 1.12 | 1.x (HashiCorp) |
| **Config language** | HCL | HCL |
| **Providers** | Same plugin protocol | Same plugin protocol |
| **State & plan encryption** | Native (KMS / PBKDF2, AES-GCM) | Not built in |
| **Provider `for_each` (iteration)** | Yes | No |
| **`-exclude` targeting** | Yes | No |
| **Registry** | Open MPL registry | HashiCorp registry (restrictive ToS) |
| **Managed platform** | Third-party (Spacelift, env0, Scalr) | HCP Terraform (first-party) |
| **Policy engine** | OPA / third-party | Sentinel (first-party) + OPA |
| **Stacks / orchestration** | Via CI platforms | Terraform Stacks (first-party) |
| **Official vendor SLA** | No (community + vendors) | Yes (IBM/HashiCorp) |
| **Migration** | Drop-in from Terraform ≤ 1.5/1.6 | — |

## 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](https://www.alekseialeinikov.com/en/blog/topics/cloud/gke-autopilot-vs-standard-2026) for the cluster-mode decision, and [Secure-by-Default GKE Reference Architecture](https://www.alekseialeinikov.com/en/blog/topics/architecture/secure-by-default-gke-reference-architecture-2026) for hardening what your IaC deploys.