OpenTofu Explained: The Terraform Fork, the Migration, and Whether to Switch

Pull up a Terraform module today and you face a question that did not exist three years ago: is the binary running this code terraform, or is it tofu? IBM completed its HashiCorp acquisition on February 27, 2025, for $6.4 billion, OpenTofu became a CNCF Sandbox project on April 23, 2025, and the migration path between the two tools is officially documented. The decision is no longer hypothetical.

This article is written from an infrastructure-operations perspective, not from the perspective of a managed Terraform platform. The goal is to separate the real migration costs from the licensing and governance noise. That means I can be straight about what breaks during migration, the legitimate governance questions, and the cases where staying on Terraform is the right call.

This article covers four things: what OpenTofu is in 2026, the features Terraform does not have, what the migration looks like in practice, and a clear recommendation for the common decision shapes.

The Short Version

• OpenTofu is an open-source fork of Terraform, MPL 2.0 licensed, hosted by the Linux Foundation, and a CNCF Sandbox project since April 23, 2025. It forked from Terraform 1.5.x after HashiCorp moved Terraform to the Business Source License in August 2023.
• As of July 26, 2026, the current maintenance release is v1.12.5; the GitHub repository has more than 29,000 stars, and the OpenTofu project site lists 3,900+ providers and 23,600+ modules.
• It ships OpenTofu-only or OpenTofu-leading capabilities Terraform does not currently match in the same way: client-side state and plan encryption, provider for_each, early variable evaluation, the enabled meta-argument, and dynamic prevent_destroy. Ephemeral resources are not OpenTofu-only; Terraform has supported them since 1.10.
• For a small Terraform 1.5.x project with local or S3 state, the happy path can be a short, reversible migration. CI/CD references, HCP-specific workflows, and dependency-lock changes are where the work expands.
• For a new IaC project in 2026, start with OpenTofu. For an existing Terraform deployment, switch when the BSL bites, when you need a feature OpenTofu has and Terraform does not, or when IBM-owned roadmap is a real concern. Otherwise the cost-benefit is thin.

What OpenTofu Is in 2026

OpenTofu is an open-source fork of Terraform, hosted by the Linux Foundation, accepted into the CNCF as a Sandbox project on April 23, 2025, and licensed under the Mozilla Public License 2.0. The binary is tofu. The configuration language is HCL, the same HCL Terraform uses. For most simple-to-medium projects, an existing Terraform codebase runs unchanged on OpenTofu.

The fork started in August 2023 after HashiCorp moved Terraform from MPL 2.0 to the Business Source License 1.1 on August 10, 2023. The BSL is source-available rather than OSI-approved and restricts production use that "competes with HashiCorp's commercial offerings." Within five days, the OpenTF Manifesto was published and a fork was announced. The Linux Foundation announcement formally introduced OpenTofu on September 20, 2023.

The Linux Foundation announcement named Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver, and Terramate among the founding supporters, with at least 18 engineers pledged full-time for a minimum of five years. OpenTofu forked from Terraform 1.5.x, the last MPL 2.0 line.

Where the project sits today: v1.12.5 is the current maintenance release, and the official site lists 3,900+ providers and 23,600+ modules. Adoption signals are no longer limited to protest-fork momentum: a Fidelity migration case study describes a program spanning more than 50,000 state files and four million resources.

The relevant business context: IBM completed its acquisition of HashiCorp on February 27, 2025, for $6.4 billion. Terraform's roadmap is now set inside a much larger enterprise vendor. That is not automatically good or bad for users, but it is part of the calculation teams are making in 2026.

Where OpenTofu Differs From Terraform

Since the fork, the two projects have taken different feature paths. The table below is the short version; the notes that follow explain what each difference changes for practitioners.

Client-side state encryption (v1.7.0, April 30, 2024). OpenTofu can encrypt state and plan files inside the tool with PBKDF2, AWS KMS, GCP KMS, or OpenBao. Terraform generally delegates at-rest encryption to the selected backend, while local state remains plaintext. OpenTofu's client-side encryption can protect a stolen state object or cached plan, provided the decryption key is not exposed with it. It does not replace TLS, backend access controls, or secret-management discipline.

Configuration looks roughly like this:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

Provider for_each (v1.9). You can iterate provider configurations the way you iterate resources. For multi-region or multi-account setups, this removes a long-running class of workaround. You no longer need to hand-roll one aliased provider per region; you can drive a single block from a map.

Early variable evaluation (v1.8). Variables can be referenced in places previously restricted, including backend and module source arguments. This is useful when one root module drives multiple environments that differ by a small set of variables.

Ephemeral resources and the enabled meta-argument (v1.11.0, December 9, 2025). OpenTofu 1.11 added ephemeral resources and the enabled meta-argument. Ephemeral resources exist only inside a single plan/apply cycle and do not persist in state, which is useful for short-lived credentials. They are not OpenTofu-only: Terraform introduced them in 1.10 and added write-only arguments in 1.11. The OpenTofu-specific capability here is enabled, which toggles a resource block from an expression without conditional count gymnastics.

Dynamic prevent_destroy (v1.12). Terraform's prevent_destroy setting accepts only literal values. OpenTofu 1.12 lets you compute it, so one module can keep staging destroyable while protecting production.

The license row is the structural difference that does not show up as a feature. MPL 2.0 is OSI-approved and file-level copyleft. Terraform's BSL 1.1 license is source-available, includes an additional-use restriction, and changes to MPL 2.0 four years after each licensed work is published. For most teams the practical effect is small; for vendors building anything close to HashiCorp's commercial offerings, it is the reason the fork exists.

Migration: What Actually Breaks

The official migration guide is deliberately short and reversible: back up state and code, install OpenTofu, run tofu init, compare tofu plan, and test a small change. The hard parts are not the commands. They are the surrounding CI/CD references, HCP-specific workflows, dependency-lock changes, and the organizational review that comes with adopting a fork.

The Happy Path

For a project that does not use HCP Terraform and does not have a thousand pipeline references to terraform, the migration is straightforward.

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan should match the plan Terraform produced. If there is an unexpected diff, check provider versions, backend settings, and any post-1.5.x Terraform features before applying.

Two pieces of nuance matter before you run anything. First, OpenTofu is broadly configuration-compatible with Terraform-style HCL for the cases this guide describes, but features added after Terraform 1.5.x still need a compatibility check. Second, tofu init -upgrade may update .terraform.lock.hcl, including provider source addresses and checksum entries. Review that metadata separately from infrastructure drift.

The Real Blockers

Three things can turn a quick CLI migration into a broader platform project. None of them are bugs.

HCP Terraform workspaces. OpenTofu includes cloud and remote integrations for compatible remote services, including HCP Terraform in local-execution and state-storage scenarios. The harder part is HCP-specific remote execution and platform features: Sentinel, run triggers, dynamic credentials, Stacks, and any service behavior OpenTofu cannot fully test or support. If those are central, pilot one workspace first; if you are leaving HCP, migrate state and recreate those platform controls.

CI/CD pipelines hardcoded for terraform. Every reference to terraform plan, terraform apply, the binary path, the Docker image, and the GitHub Actions or GitLab CI step needs review. For GitHub Actions, the swap is roughly this:

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

That is the trivial case: one workflow, one repo. In a monorepo with shared composite actions, multiple pipelines, and a reusable workflow library, the review surface is wider. The work is mechanical, but it can take longer than the CLI swap.

Dependency lock-file review. tofu init may update .terraform.lock.hcl, including provider source addresses and checksum entries. OpenTofu 1.12 can also add complete h1: checksum sets. Treat the diff as dependency metadata to review and commit separately, not infrastructure drift.

Stakeholder resistance. "We are running a fork now" lands differently in different organizations. The honest counter is that OpenTofu remains broadly configuration-compatible with Terraform-style HCL for the cases this guide describes, so the swap is usually reversible. If OpenTofu disappeared tomorrow, many teams could reinstall Terraform, review the lock file, and keep using the same .tf files. Validate post-fork features first; that caveat is more credible than promising perfect interchangeability.

When Migration Is Genuinely Hard

That happy path does not apply to every Terraform estate.

Migration gets meaningfully harder when:

• State is large (thousands of resources, dozens of workspaces) and lives in HCP Terraform.
• The codebase uses HCP-only features deeply: Sentinel policies wired into workspaces, run triggers, HCP-managed dynamic provider credentials. Terraform Stacks is HCP-only and has no OpenTofu equivalent, out of scope here.
• An enterprise audit or compliance framework names "Terraform" as the IaC tool of record, which is a procurement and documentation problem on top of the technical one.
• A large module library has internal version constraints that resolved against Terraform-specific registry behavior.

Not every team should migrate. The cost-benefit only makes sense when the BSL restrictions actually affect your use case, when a specific OpenTofu feature unblocks something concrete, or when IBM-controlled roadmap is a real concern for your organization. If none of those apply, staying on Terraform is a perfectly defensible call.

Should You Switch?

There is no single right answer here. When I draw the decision tree for a team, four common shapes show up, and the right move depends on which shape you are in.

New IaC adoption (greenfield). Start with OpenTofu. The license is MPL 2.0, governance sits under the Linux Foundation and CNCF, and the project has an active release cadence. Its differentiators include client-side state encryption, provider for_each, enabled, and dynamic prevent_destroy. There is no BSL friction to plan around. This is the strongest recommendation in this article.

Existing Terraform user, small-to-medium project. Switch if any of three triggers fires. One: you sell or might sell a product that could brush against the BSL "competes with HashiCorp" carve-out; the legal calculus is cleaner on MPL 2.0. Two: you need client-side state encryption, provider for_each, enabled, or dynamic prevent_destroy and the Terraform workaround is no longer worth maintaining. Three: you prefer multi-party governance over a single-vendor roadmap. If none applies and Terraform runs cleanly, stay. Migration is reversible in many estates, but not free.

Heavy HCP Terraform user. Treat this as a platform decision, not automatically as a backend migration. OpenTofu can use compatible remote backends, but HCP-specific remote execution, Sentinel, run triggers, dynamic credentials, and Stacks still need a feature-by-feature assessment. If those controls are central, pilot first. If you are leaving HCP for licensing, cost, or governance reasons, plan the work as a platform migration.

Considering Pulumi or another non-HCL alternative. OpenTofu is the closest path if you want to keep HCL and most existing workflows. Pulumi is a broader platform and language choice: TypeScript, Python, Go, or .NET driving cloud APIs. Moving there may involve conversion or a rewrite, so evaluate it separately from a Terraform-to-OpenTofu binary change.

One more thing worth addressing directly: the legitimate critique that OpenTofu is partly a SaaS-vendor hedge. A Hacker News thread on the BSL change surfaced the concern that the project's founding members are commercial Terraform platforms with a license-flexibility motive of their own. I take that concern seriously. The mitigation is the governance structure, Linux Foundation hosting, CNCF Sandbox, MPL 2.0 on every file, which makes a future relicensing significantly harder than a single-vendor relicensing was. It does not make it impossible. It does make it costly enough that it is a real check.

Quick verdict. For new IaC work in 2026, start with OpenTofu. Its license, governance, active development, and feature set make a strong default. For existing Terraform deployments, switch when one of the three triggers above applies; otherwise, the cost-benefit is thin and staying is fine.

Once the tool choice is clear, the next practical question is where OpenTofu should run. That decision affects secrets handling, cost, repeatability, and how much control your team has over the execution environment.

Running OpenTofu Yourself

OpenTofu is a CLI binary. Where you run it determines a lot about cost, security, and what you can do with it. There are roughly three sensible places to put it.

Laptop or dev machine. Fine for one-off plans, prototyping, and small personal projects. It is a poor default for shared production workflows unless remote state, locking, and review discipline are already enforced. Teams usually benefit from a canonical execution environment instead of whichever laptop last ran tofu apply.

Managed CI runner (GitHub Actions, GitLab CI, etc.). The common path. The opentofu/setup-opentofu action is a drop-in for hashicorp/setup-terraform. This works well for most teams and projects. Trade-offs: secrets transit a third-party CI service, free-tier minutes can run out on large state operations, and the runner environment is ephemeral, which is usually a feature but sometimes a constraint. See GitHub vs GitLab if you are still choosing between hosted CI options, and Best CI/CD Tools for the broader landscape.

Self-hosted runner on a VPS. Useful when managed-CI trade-offs stop working: secrets must stay off a third-party service, CI minutes become expensive, or you want persistent provider caches. The setup is straightforward: a Linux VPS, the OpenTofu binary, a GitHub Actions or GitLab Runner agent, and Docker for job isolation. See Install Docker on VPS if that part is new. For a small-team runner, 4 GB RAM, 2 vCPU, and 60 GB NVMe is a reasonable starting point; scale CPU, memory, and storage for larger plans and higher concurrency.

For teams that need tighter control over runner secrets, persistent provider caches, or predictable CI costs, a self-hosted runner on a VPS can make sense. In that setup, prioritize root access, fast NVMe storage, easy resizing, and enough CPU/RAM for larger plan operations.

Cloudzy Linux VPS instances fit that self-hosted-runner pattern with root access, NVMe storage, and flexible sizing, so you can start small and scale the runner as your OpenTofu workloads grow.

Frequently Asked Questions

Is OpenTofu the Same as Terraform?

Not quite. OpenTofu started as a fork of Terraform 1.5.x and remains broadly configuration-compatible with Terraform-style HCL: the same .tf files, providers, and plan/apply workflow for many projects. They differ in license and in features added after the fork. OpenTofu has client-side state encryption, provider for_each, enabled, and dynamic prevent_destroy; Terraform has its own post-fork features, including ephemeral resources.

Will OpenTofu Support All My Terraform Providers?

For major providers such as AWS, GCP, Azure, Kubernetes, and Helm, generally yes. The OpenTofu Registry reports 3,900+ providers as of July 2026. tofu init may update .terraform.lock.hcl metadata. For niche, vendor-specific, or newly published providers, verify availability and version support directly before switching.

Could OpenTofu Itself Get Relicensed Someday?

A future relicensing is harder than it was for Terraform but not impossible. OpenTofu is MPL 2.0, hosted by the Linux Foundation, and a CNCF Sandbox project since April 23, 2025. The governance is multi-party and the license is OSI-approved. A unilateral relicensing by any single founder would conflict with both the foundation's charter and the existing MPL 2.0 contributions, which would need to be removed or rewritten. The concern is legitimate; the structural barriers are real.

What Does the IBM Acquisition of HashiCorp Mean for Terraform's Future?

IBM completed the HashiCorp acquisition on February 27, 2025, for $6.4 billion. Terraform's roadmap now sits inside a larger enterprise vendor. The acquisition alone does not prove future licensing or product direction; evaluate current release notes, licensing guidance, and HCP product changes instead of treating ownership as a prediction.

Is OpenTofu Production-Ready in 2026?

Yes. v1.12.5 is the current maintenance release, the project is in the CNCF Sandbox, and Fidelity has described production adoption across an IaC estate with more than 50,000 state files and four million resources. Production-ready does not mean feature-identical: teams that rely on HCP-only capabilities such as Terraform Stacks still need a separate compatibility decision.