OpenTofu in 2026: Where the Terraform Fork Stands

The Fork Is Two Years Old. Where Did It Land?

Cast your mind back to August 2023. HashiCorp dropped the Business Source License (BUSL) on Terraform and every IaC practitioner on the internet had A Take. The drama was loud, the Discord servers were sweaty, and within weeks the OpenTF Manifesto had thousands of signatures.

Then IBM acquired HashiCorp in mid-2024 for $6.4 billion. At that point even the skeptics stopped calling OpenTofu a “panic fork” and started treating it like actual infrastructure.

Here we are in mid-2026. OpenTofu is at 1.9.x, the Linux Foundation is stewarding it, and it has features Terraform proper still doesn’t have. Meanwhile Terraform 1.x hit end-of-life for some older minors and the 2.x migration path involves… the HCP Terraform platform doing more lifting than you’d expect.

So should you migrate? Should you stay? Is the whole thing a tire fire? Let’s actually look at what happened.

What the BUSL Mess Actually Meant

Quick recap for anyone who blocked it out: HashiCorp moved Terraform (and Vault, Nomad, Consul) from MPL 2.0 to BUSL 1.1. Under BUSL, you can use the software freely unless you’re building a competing commercial product. Terraform Cloud and Spacelift, for example, are the kind of services that are potentially in murky territory depending on how HashiCorp defines “competitive.”

For most teams running Terraform to manage their own infra? The license change probably doesn’t affect you directly. The problem is “probably” is doing a lot of work in that sentence, and “probably fine” is not how you want to describe your core infrastructure tooling to your legal team.

The OpenTofu fork side-stepped this entirely. It’s MPL 2.0, community-governed under the Linux Foundation, and explicitly committed to staying open. If you run a platform that touches Terraform in any commercial context, this isn’t a theoretical concern anymore — it’s a reason to actually migrate.

Feature Parity: Honestly, It’s Good

OpenTofu 1.9 has near-complete parity with Terraform 1.x for the things people actually use day-to-day. The provider ecosystem is compatible — OpenTofu reads the same provider registry protocol, and you can point it at registry.terraform.io or the new registry.opentofu.org. Most providers work without a single line change.

Where OpenTofu has pulled ahead:

Early Variable Evaluation

OpenTofu lets you use variables in backend and provider blocks. This sounds boring until you’ve spent three years writing wrapper scripts to interpolate backend configs because Terraform couldn’t do it.

variable "environment" {
  type    = string
  default = "prod"
}

terraform {
  backend "s3" {
    bucket = "my-tf-state-${var.environment}"
    key    = "infra/terraform.tfstate"
    region = "us-east-1"
  }
}

This works in OpenTofu 1.8+. In Terraform, you’re still passing -backend-config flags or using partial config files and pretending that’s fine.

State Encryption

OpenTofu has built-in state encryption at the provider level. Your state file can be encrypted with a KMS key (AWS, GCP, OpenBSD, or a passphrase) and it’s configured directly in the terraform block:

terraform {
  encryption {
    key_provider "aws_kms" "my_key" {
      kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/..."
      region     = "us-east-1"
    }

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

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

If you’ve been storing unencrypted state in S3 and relying purely on bucket policies and IAM — this is the upgrade you didn’t know you needed. Terraform has no equivalent native feature.

OCI Registry for Providers and Modules

OpenTofu added OCI artifact support for providers and modules. You can host providers in your own container registry (Harbor, ECR, ACR, whatever you’re already running) and pull from there instead of the public registry. For air-gapped environments, this is massive — no more awkward mirror scripts.

The exclude Flag for Plan/Apply

Small quality-of-life thing that saves real time: tofu plan -exclude=module.this_broken_thing lets you skip specific resources in a plan without commenting them out. Terraform added -target years ago for going narrow; OpenTofu added -exclude for going wide. Both are useful.

The terraform Block vs tofu Block

OpenTofu 1.9 introduced the tofu block as an alias for the terraform block. Your existing code using terraform {} still works fine — this is additive, not breaking.

tofu {
  required_version = ">= 1.8"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

Use tofu {} in new files if you want to be explicit. In mixed codebases where you’re supporting both for a transition period, terraform {} still works in OpenTofu, and that’s intentional.

Migrating an Existing Repo

If you have an existing Terraform codebase, migration is genuinely low-drama. Here’s the typical path:

Step 1: Install OpenTofu

# macOS
brew install opentofu

# Linux (official install script)
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh

# Or via package manager after adding the repo
apt-get install opentofu

Verify:

tofu version

Step 2: Run tofu init in Your Existing Directory

If your code uses registry.terraform.io providers, OpenTofu 1.6+ will transparently redirect to the OpenTofu registry or fall through to the HashiCorp registry depending on availability. Most provider authors publish to both now.

cd your-terraform-project/
tofu init

You’ll see it download providers and write a .terraform.lock.hcl. If you’re committing lock files (you should be), update it:

tofu providers lock -platform=linux_amd64 -platform=darwin_arm64 -platform=windows_amd64

Step 3: Run a Plan

tofu plan -out=tfplan

For the vast majority of codebases, this produces an identical plan to what terraform plan would. If you see differences, they’re almost always related to provider version resolution, not OpenTofu itself.

Step 4: Decide on CI/CD

This is where most of the actual work lives. Replace terraform binary references with tofu. In GitHub Actions:

name: OpenTofu Plan

on:
  pull_request:
    branches: [main]

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup OpenTofu
        uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: "1.9.0"

      - name: Tofu Init
        run: tofu init

      - name: Tofu Plan
        run: tofu plan -no-color
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

GitLab CI is similar — swap the binary name, add the OpenTofu Docker image (ghcr.io/opentofu/opentofu:1.9), done.

Ecosystem Support: Actually Solid

One thing that killed adoption of early OpenTofu in some shops was “but does Atlantis support it?” The answer in 2026 is yes, everything does:

• Atlantis — full OpenTofu support since 0.27. Configure tofu_version in atlantis.yaml and you’re done.
• Spacelift — supports both, you pick per stack. They’ve been explicit that they support OpenTofu as a first-class option.
• Scalr — same deal. Workspace-level configuration, no drama.
• env0 — supports both, provider-agnostic templates work across either.
• GitLab CI — official opentofu image in the container registry. Example above works.
• Forgejo/Gitea Actions — same workflow YAML as GitHub Actions, use the setup-opentofu action.

The “will my tooling support this” concern was valid in 2023-2024. It’s mostly a non-issue now.

Provider Registry: The Practical Reality

One concern that was real in 2023 was “will providers actually work?” The answer today is: mostly yes, with a couple of nuances worth knowing.

OpenTofu uses registry.opentofu.org as its default registry. The registry mirrors providers from registry.terraform.io — the major ones (AWS, Azure, GCP, Kubernetes, Helm, Cloudflare, Datadog, etc.) are all there. For community providers that exist only on the HashiCorp registry, you can still reference them directly:

terraform {
  required_providers {
    some-niche-provider = {
      source  = "registry.terraform.io/vendor/some-niche-provider"
      version = "~> 1.0"
    }
  }
}

OpenTofu will pull it from the HashiCorp registry just fine. You don’t need everything to be mirrored — you just need to be explicit about the source.

For air-gapped or enterprise environments, the OCI registry feature really shines here. You can mirror your required providers into your own Harbor or ECR instance during your build pipeline, then point OpenTofu at that. No public internet required at apply time, no dependency on either registry being up.

Who Should Migrate (And Who Shouldn’t)

Migrate if:

• You run a platform or service that touches Terraform commercially and your legal team is squinting at the BUSL terms.
• You want state encryption without an external wrapper.
• You want early variable evaluation in backends — it’ll save you a pile of CI scripts.
• You’re starting a greenfield project and MPL 2.0 matters to your org.
• Your team is already on Linux Foundation-governed tooling and this fits the pattern.

Don’t bother if:

• You’re a solo homelab person with 200 lines of Terraform managing a Proxmox cluster. The license change doesn’t affect you and migration is work for no real gain.
• Your company has a Terraform Enterprise contract with HashiCorp/IBM and the platform integration is deeply coupled.
• You’re actively using Terraform 2.x features that OpenTofu hasn’t caught up to yet. Check the compatibility matrix before assuming 1:1 parity at the bleeding edge.
• You’re three weeks from a big launch and someone suggested this as a fun project. Your 2 AM self will not appreciate it.

Honest caveat: OpenTofu’s release cadence is solid but it’s a smaller team than HashiCorp/IBM. If Terraform 2.x ships something novel tomorrow, OpenTofu won’t have it in the next week. The fork is mature and well-funded, but it’s not magic.

The Bigger Picture

Two years ago, people were asking “is OpenTofu actually going to survive or is this just angry tweeting?” The answer is pretty clear now: it’s a legitimate, actively-developed project with a real governance structure and real corporate backing (Gruntwork, Spacelift, env0, and others have all contributed significantly).

The IBM acquisition of HashiCorp hasn’t resulted in Terraform becoming dramatically more hostile to open-source use — but it hasn’t reversed the BUSL decision either. The license situation is what it is. IBM has historically not been great at stewarding acquired open-source projects, and the community memory on that is long.

OpenTofu isn’t perfect. The docs are catching up. Some provider edge cases behave differently. If you’re coming from Terraform Cloud with a bunch of remote operations and workspace-level variables, the migration involves more thought than just swapping binaries.

But if you’ve been on the fence because it felt risky? Two years of production use by real companies, an active maintainer team, and a feature set that’s actually pulled ahead of upstream in meaningful ways — that’s not risky anymore. That’s just a choice.

Quick Reference: Terraform vs OpenTofu

The fork landed. It works. If you have a reason to care about the license — or you just want the extra features — the migration path is boring in the best possible way.

Boring migrations are the good kind.

One More Thing: Keeping Up

OpenTofu has a changelog worth actually reading. The project moves deliberately — they don’t ship features just to ship features, and when they diverge from Terraform behavior, they document why. The GitHub discussions are surprisingly low-drama for a fork born out of drama.

Follow github.com/opentofu/opentofu releases if you’re running it in production. The upgrade path between OpenTofu minor versions has been clean — state format is backward compatible, provider lock files don’t need regeneration on minor bumps, and the usual tofu init -upgrade dance works exactly like you’d expect.

If you were waiting for OpenTofu to “prove itself” before committing — two years of production use across major cloud environments, a features-ahead-of-upstream story, and a license that doesn’t require a lawyer’s interpretation is about as proven as a fork gets.

Related Reading

• Ansible vs. Terraform: Cloud Infrastructure Management
• dbt-core for Self-Hosters: SQL With Tests, Without dbt Cloud
• DevOps Tools: Ansible vs. Puppet vs. Salt vs. Chef
• Gitea vs Forgejo vs GitLab CE: Self-Hosted Git
• Terraform vs Pulumi: Infrastructure as Code Without the YAML Nightmares