← All articles
a laptop computer sitting on top of a desk

OpenTofu: The Open-Source Terraform Fork You Should Know About

Infrastructure 2026-03-17 · 4 min read opentofu terraform infrastructure-as-code devops open-source

When HashiCorp switched Terraform to the Business Source License (BSL) in August 2023, the infrastructure-as-code community had a problem. Teams that built tooling, platforms, and workflows around Terraform's open-source license suddenly faced restrictions on how they could use and distribute the tool. OpenTofu emerged as the community's answer — a Linux Foundation-governed fork that keeps the MPL 2.0 license and adds features Terraform users have wanted for years.

Photo by Bernd 📷 Dittrich on Unsplash

What OpenTofu Actually Is

OpenTofu is a drop-in replacement for Terraform. It forked from Terraform 1.5.x (the last MPL-licensed version) and maintains compatibility with existing Terraform state files, providers, and modules. If you have a working Terraform configuration today, you can switch to OpenTofu with minimal effort.

The project lives under the Linux Foundation, which means no single company controls the roadmap. This matters if your organization has compliance requirements around open-source licensing or if you build commercial products that embed infrastructure-as-code tooling.

Key Differences from Terraform

State Encryption

OpenTofu added native state encryption — something Terraform users have requested for years. State files often contain sensitive values (database passwords, API keys, private IPs), and Terraform stores them in plaintext by default.

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

    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.main
    }

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

With enforced = true, OpenTofu refuses to read or write unencrypted state. This is a significant security improvement for teams that store state in S3, GCS, or other remote backends without additional encryption layers.

Early Variable and Local Evaluation

OpenTofu allows variables and locals in backend and module source blocks — something Terraform explicitly prohibits:

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

terraform {
  backend "s3" {
    bucket = "tfstate-${var.environment}"
    key    = "infra/terraform.tfstate"
    region = "us-west-2"
  }
}

In Terraform, this forces you into wrapper scripts or -backend-config flags. OpenTofu evaluates variables early enough to use them in backend configuration directly.

Provider-Defined Functions

OpenTofu supports functions defined by providers, not just the built-in function set. This lets provider authors ship domain-specific functions alongside their resources:

# Use an AWS provider function to generate a policy document
locals {
  policy = provider::aws::arn_build("iam", "", data.aws_caller_identity.current.account_id, "role/my-role")
}

Terraform added a similar feature later, but OpenTofu shipped it first and the implementation details differ.

Migrating from Terraform

Step 1: Install OpenTofu

# macOS
brew install opentofu

# Linux (Debian/Ubuntu)
curl -fsSL https://get.opentofu.org/install-opentofu.sh | sh

# Or use mise/asdf
mise use -g opentofu@latest

Step 2: Replace the Binary

OpenTofu uses the tofu command instead of terraform. The simplest migration path:

# Test with existing config
cd your-terraform-project
tofu init
tofu plan

If you have CI/CD pipelines that call terraform, update them to call tofu. The flags and subcommands are identical for standard operations.

Step 3: Handle State

OpenTofu reads Terraform state files directly. No migration step is needed — just point tofu at your existing backend:

tofu init -reconfigure
tofu plan  # should show no changes if everything matches

If plan shows unexpected changes, it is usually a provider version mismatch. Pin your provider versions explicitly:

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

Step 4: Update Lock Files

Run tofu init -upgrade to regenerate .terraform.lock.hcl with OpenTofu-compatible hashes. Commit the updated lock file.

When OpenTofu Makes Sense

Use OpenTofu if:

Stick with Terraform if:

Provider and Module Compatibility

OpenTofu uses the same provider protocol as Terraform, and the public Terraform Registry works with both tools. The OpenTofu project also runs its own registry at registry.opentofu.org as a mirror.

Most community modules work without modification. The exceptions are modules that use Terraform-specific features added after the fork point (1.6+). Check the module's required_version constraint — if it requires Terraform >= 1.6, test it with OpenTofu before relying on it in production.

CI/CD Integration

GitHub Actions, GitLab CI, and other platforms have OpenTofu support:

# GitHub Actions
- uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: "1.9.x"

- run: |
    tofu init
    tofu plan -out=tfplan
    tofu apply tfplan

Atlantis, Spacelift, and env0 all support OpenTofu as a backend. If you use Terraform Cloud specifically, you will need an alternative remote execution platform — Terraform Cloud is HashiCorp-only.

The Bottom Line

OpenTofu is not a radical reimagining of infrastructure-as-code. It is Terraform with an open-source license, better state security, and a community governance model. For most teams, the migration is straightforward and the operational differences are minimal. The real value is insurance — your IaC toolchain stays open regardless of any single company's licensing decisions.

If you are starting a new project with no existing Terraform investment, OpenTofu is the safer default. If you have a large Terraform deployment, evaluate the migration cost against your licensing requirements. Either way, having the option matters.