OpenTofu

OpenTofu is a drop-in, open-source fork of Terraform created in 2023 after HashiCorp relicensed Terraform under the non-open-source Business Source License (BSL). It speaks the same HCL, uses the same provider and module ecosystem, and accepts the same CLI commands — but it is governed by the Linux Foundation under a vendor-neutral, MPL 2.0 license. If you care about long-term openness, want to avoid a license you cannot redistribute commercially, or simply prefer a community-driven roadmap, OpenTofu is the most direct path off proprietary Terraform with essentially zero rewrite cost.

Why OpenTofu forked

For most of its life Terraform was licensed under the permissive Mozilla Public License 2.0 (MPL “2.0”). In August “2023”, HashiCorp switched all of its core products — including Terraform — to the Business Source License. The BSL is a “source-available” license: you can read the code and use it, but you may not use it to build a product that competes with HashiCorp’s commercial offerings.

That clause spooked the ecosystem. Vendors building Terraform-based platforms, and even teams worried about ambiguous “competition” language, no longer had the legal certainty that MPL gave them. A coalition of companies and individuals forked the last MPL-licensed Terraform release and launched it as OpenTF, which was quickly accepted into the Linux Foundation and renamed OpenTofu. The fork is permanent: OpenTofu tracks its own roadmap and will never adopt the BSL.

The license change applies to Terraform’s source, not to your own configuration. Your .tf files were never affected — the fork is about which engine binary you trust to stay open.

Drop-in compatibility

OpenTofu’s headline promise is compatibility. The tofu binary is a near-perfect substitute for terraform: same commands, same flags, same state file format, same .tf and .tf.json syntax. Providers and modules are pulled from a registry that mirrors the public Terraform Registry, so hashicorp/aws, hashicorp/azurerm, and the rest resolve unchanged.

Installing it is a single binary. On macOS with Homebrew:

brew install opentofu
tofu version

Output:

OpenTofu v1.8.0
on darwin_arm64

A standard configuration runs without modification:

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

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "logs" {
  bucket = "acme-app-access-logs"

  tags = {
    Environment = "prod"
    ManagedBy   = "opentofu"
  }
}

You run it with the same lifecycle you already know — init, plan, apply:

tofu init
tofu plan
tofu apply

Output:

OpenTofu used the selected providers to generate the following execution plan.

  # aws_s3_bucket.logs will be created
  + resource "aws_s3_bucket" "logs" {
      + bucket = "acme-app-access-logs"
      + id     = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Governance under the Linux Foundation

The most consequential difference is not technical — it is governance. Terraform is steered by a single company; OpenTofu is a Linux Foundation project with an open, multi-vendor steering committee, a public RFC process, and decisions made on a GitHub-visible roadmap. Anyone can propose a feature, contributions are accepted under a community CLA, and no single vendor can unilaterally relicense the project again. For organizations that treat their IaC engine as critical infrastructure, that neutrality is the whole point.

Where the two are diverging

Early OpenTofu releases focused on parity. Newer ones ship features Terraform either lacks or implemented differently, so the codebases are slowly diverging.

Capability	OpenTofu	Terraform
License	MPL 2.0 (open source)	BSL 1.1 (source-available)
Governance	Linux Foundation, multi-vendor	HashiCorp (now IBM)
State encryption	Built-in client-side encryption	Not built in
`-exclude` plan flag	Yes	No (only `-target`)
Early variable evaluation	In backend/module sources	More limited
Provider registry	Community-run mirror	Official HashiCorp registry

A standout OpenTofu-only feature is native state encryption, which encrypts state and plan files at rest before they touch a backend:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "encrypted" {
      keys = key_provider.pbkdf2.passphrase
    }

    state {
      method = method.aes_gcm.encrypted
    }
    plan {
      method = method.aes_gcm.encrypted
    }
  }
}

Migrating from Terraform

Because the state format and configuration are shared, migration is usually just swapping the binary. The recommended steps:

# 1. Make sure your existing state is committed/backed up first
tofu init   # reads your existing backend and state unchanged
tofu plan   # should show: No changes. Your infrastructure matches the configuration.

Output:

No changes. Your infrastructure matches the configuration.

OpenTofu has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

A clean “No changes” plan after tofu init is your signal that the switch was lossless. In CI, replace terraform invocations with tofu (the opentofu/setup-opentofu GitHub Action mirrors hashicorp/setup-terraform).

Only migrate from a Terraform version at or below OpenTofu’s compatibility line. Going back the other way — opening an OpenTofu-written state in older Terraform — can fail if you have used OpenTofu-only features like state encryption.

Best Practices

Pin an explicit required_version and a CI-pinned tofu version so plans stay reproducible across machines.
Run tofu plan immediately after migrating and require a clean “No changes” result before you trust the cutover.
Adopt OpenTofu-only features (state encryption, -exclude) only once your whole team and CI are off Terraform, to avoid a one-way door.
Keep using the standard hashicorp/<provider> source addresses — they resolve through OpenTofu’s registry mirror without changes.
Back up state before the first tofu init, exactly as you would for any backend or engine change.
Track the OpenTofu roadmap and RFCs; the open governance means you can influence features that matter to you.

OpenTofu

Why OpenTofu forked

Drop-in compatibility

Governance under the Linux Foundation

Where the two are diverging

Migrating from Terraform

Best Practices

Related Topics