OpenTofu in 2026: Open-Source Terraform Fork Explained

OpenTofu is the Linux Foundation's open-source fork of Terraform — forked from Terraform 1.5.x in August 2023 after HashiCorp moved the upstream to the Business Source Licence, and shipping v1.11.6 (April 8, 2026) under MPL 2.0 with v1.12.0-rc1 already in the wild. The stakes are concrete: the BSL forbids building competing products on top of Terraform, OpenTofu does not, which is why every managed IaC platform you can name — Spacelift, env0, Scalr, Gruntwork — defaulted to tofu within months of the relicense. The HCL hasn't changed since the fork, but the two projects have visibly diverged: state encryption, ephemeral values, early variable evaluation, and provider for_each ship in OpenTofu first and have no Terraform equivalent in 2026.

This page is the field guide. What OpenTofu actually is, what changed when IBM closed the HashiCorp acquisition in December 2024, the version-by-version feature timeline, a 60-second install, the binary-swap migration path from Terraform, and where OpenTofu still loses. For the broader IaC landscape including Pulumi see the Pulumi vs Terraform vs OpenTofu primer, and for the variable model that OpenTofu inherits intact see the Terraform variables guide.

What Is OpenTofu?

OpenTofu is an infrastructure-as-code tool that reads HCL configuration files, talks to a provider plugin, diffs your desired state against a state file, and applies the difference. If that sentence reads like the Terraform tagline, that is the entire point — OpenTofu is the same thing, with the same .tf files, the same providers, the same terraform.tfstate, and the same plan/apply verbs. The CLI binary is named tofu.

What is different is who owns it. HashiCorp owns Terraform; the Linux Foundation hosts OpenTofu under a Technical Steering Committee drawn from Gruntwork, Spacelift, env0, Harness, Scalr, and independent maintainers. No single vendor controls the roadmap. The OpenTF Manifesto — the document that triggered the fork — sits in a GitHub repo with 35.8k stars and signatures from over a hundred companies. The first independent release, OpenTofu 1.6.0, shipped January 9, 2024. CNCF accepted the project at Sandbox maturity on April 23, 2025.

Why Did OpenTofu Get Forked in the First Place?

The timeline is short and the stakes were enormous for a slice of the ecosystem most users never see — the platform vendors.

OpenTofu vs Terraform: What Actually Differs?

For most teams running apply against their own infrastructure, almost nothing differs. The HCL is identical, the providers are identical, the state format is interchangeable. The differences live at the edges: licence, governance, and a growing set of OpenTofu-exclusive features.

The compatibility line is sharp. As soon as you turn on encryption, ephemeral resources, or the enabled meta-argument, the state and configuration are no longer round-trippable with Terraform. Decide upfront whether your team wants OpenTofu compatibility or OpenTofu features — you cannot have both on the same stack.

What Did Each OpenTofu Release Add?

OpenTofu's minor-version cadence is roughly every six months, mirroring the Terraform support policy: three concurrent release lines supported at any time (latest plus two prior). Each release line gets a year of security patches.

How Do You Install OpenTofu?

There is no installer wizard, no signup, no licence key. OpenTofu ships a single static binary for every major OS and architecture, signed with cosign. The fastest path on a developer machine is a package manager; the repeatable path for CI is the official install script.

# macOS / Linux (Homebrew)
brew install opentofu

# Linux (Snap)
sudo snap install --classic opentofu

# Debian / Ubuntu (apt repository)
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh -o install.sh
chmod +x install.sh
./install.sh --install-method deb

# Windows (Winget)
winget install OpenTofu.Tofu

# Standalone binary (any platform)
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh -o install.sh
chmod +x install.sh
./install.sh --install-method standalone

# Container image (CI, locked version)
docker run --rm -v "$PWD:/src" -w /src ghcr.io/opentofu/opentofu:1.11.6 init

Verify the install: tofu version should print the major version line plus the platform tuple. From there the workflow is identical to Terraform: tofu init, tofu plan, tofu apply, tofu destroy.

How Do You Migrate From Terraform?

For a single stack the migration is a five-minute swap. The cost scales with the number of stacks, the cleanliness of your registry references, and how many CI pipelines hard-code the terraform binary name.

1. Land a clean plan first. Run terraform apply so the state matches the configuration. Then terraform plan must report no changes — if it does not, fix that before switching tools.
2. Back up the state file. Local: copy terraform.tfstate and .terraform.lock.hcl. Remote: snapshot or version the backend object and confirm restore.
3. Match versions. Migrating from Terraform 1.5.x or older? Install OpenTofu 1.6.x first, then upgrade. From Terraform 1.8.x or 1.9.x? Install matching OpenTofu 1.8.x / 1.9.x and step forward one minor at a time.
4. Install OpenTofu. See above. Keep the terraform binary installed in parallel until you have validated the first tofu apply.
5. Re-initialise. tofu init -upgrade downloads providers from registry.opentofu.org instead of HashiCorp's registry. The providers themselves are byte-identical mirrors for the common ones (AWS, Azure, GCP, Cloudflare, Kubernetes).
6. Plan, then apply, then rest. tofu plan must produce zero changes. If it does not, roll back (re-run terraform init) and investigate before applying. tofu apply a small non-critical change to confirm the round-trip.
7. Patch CI. Swap terraform for tofu in your GitHub Actions / GitLab CI / Jenkins steps. Replace hashicorp/setup-terraform with opentofu/setup-opentofu.

- - name: Setup Terraform
-   uses: hashicorp/setup-terraform@v3
-   with:
-     terraform_version: 1.10.0
-
- - run: terraform init
- - run: terraform plan -out=plan.tfplan
- - run: terraform apply plan.tfplan

+ - name: Setup OpenTofu
+   uses: opentofu/setup-opentofu@v1
+   with:
+     tofu_version: 1.11.6
+
+ - run: tofu init
+ - run: tofu plan -out=plan.tfplan
+ - run: tofu apply plan.tfplan

If teams need to coexist — half on Terraform, half on OpenTofu, same modules — use .tofu file extensions for OpenTofu-only divergence. OpenTofu reads both .tf and .tofu; Terraform ignores .tofu.

How Does State Encryption Work?

State encryption is OpenTofu's flagship feature and the one Terraform users have asked for since 2016. Without it, your state file holds database passwords, private keys, IAM credentials, and instance IPs in plaintext — anyone with read access to the state backend has read access to every secret your IaC ever touched. With it, that file is an opaque AES-GCM blob.

terraform {
  encryption {
    key_provider "aws_kms" "primary" {
      kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abc-..."
      region     = "us-east-1"
      key_spec   = "AES_256"
    }

    method "aes_gcm" "encrypt_state" {
      keys = key_provider.aws_kms.primary
    }

    state {
      method   = method.aes_gcm.encrypt_state
      enforced = true
    }

    plan {
      method = method.aes_gcm.encrypt_state
    }
  }
}

The five supported key providers — each maps to a different ops trade-off:

Three production rules: rotate the key on a schedule (AES-GCM saturates after ~2³² messages with the same key — AWS/GCP KMS automate this), set enforced = true so a misconfigured CI run cannot accidentally write plaintext state, and configure a fallback key during rotations so in-flight plans don't break.

When Should You Not Use OpenTofu?

• You depend on HCP Terraform / Terraform Cloud features. Sentinel policy-as-code, no-code modules, run tasks, drift detection, ephemeral workspaces — those are HashiCorp commercial products, not OpenTofu features. Replace with OPA + Conftest, Spacelift, env0, Scalr, or Terramate before you migrate.
• Your tooling hard-codes the hashicorp/ registry. Any module that uses fully-qualified source = "hashicorp/..." references needs a registry mirror or a search-and-replace pass. The OpenTofu registry resolves bare provider names automatically, but FQN strings don't auto-rewrite.
• You need a specific HashiCorp partner integration. A small set of providers — mostly HashiCorp's own (Vault, Boundary, Waypoint) — get features in Terraform first and may take a release or two to land on the OpenTofu registry. Check registry.opentofu.org before you assume parity.
• You're mid-migration on multiple stacks at once. A single stack flips in minutes. Hundreds of stacks need a migration program — registry audits, CI patching, state-file snapshotting, rollback plans. The technical cost is small per stack; the coordination cost compounds.
• You want a different language entirely. If you're leaving Terraform because of HCL fatigue, see the Pulumi primer — same provider ecosystem, TypeScript / Python / Go / C# instead.

Frequently Asked Questions

References

• OpenTofu official site — project home, docs entry point, and download links
• What's new in OpenTofu 1.11 — official changelog summary for the current stable line
• OpenTofu install guide — per-platform install commands, container image, and standalone binary
• OpenTofu migration guide — official Terraform-to-OpenTofu migration with per-version sub-guides
• OpenTofu state & plan encryption — every key provider, configuration block, and fallback / rotation pattern
• OpenTofu releases (GitHub) — full release notes, signed artifacts, and pre-release tags
• The OpenTF Manifesto — the September 2023 document that triggered the fork, with signatory list
• Linux Foundation — OpenTofu 1.7 press release — the state-encryption launch announcement (April 30, 2024)
• CNCF — OpenTofu project page — Sandbox-maturity acceptance details and ongoing CNCF participation
• endoflife.date — OpenTofu — release dates and security-support timeline for every minor version