OpenTofu: The Open Terraform Fork

By Khimananda Oli | Last reviewed: August 2026

When HashiCorp changed Terraform’s license to the Business Source License (BSL) in late 2023, many organizations realized their infrastructure-as-code dependency was no longer truly open source. OpenTofu: The Open Terraform Fork emerged as the direct response, preserving the original MPL 2.0 license and community governance model that enterprises relied on for compliance and freedom. If you are evaluating whether to stay with Terraform or adopt its fork, understanding the practical differences in state management, provider ecosystems, and long-term viability is essential before making any production changes.

What exactly is OpenTofu: The Open Terraform Fork?

OpenTofu is a fork of Terraform 1.5.x created under the Linux Foundation to guarantee perpetual open-source licensing. Unlike a simple copy, it has evolved into an independent project with its own release cadence, feature roadmap, and governance structure. For DevOps engineers and platform teams, the critical distinction is legal and operational: OpenTofu remains under the Mozilla Public License 2.0, meaning you can use, modify, and distribute it commercially without the usage restrictions imposed by the BSL.

In practice, this matters most for managed service providers, SaaS platforms embedding IaC, and organizations with strict compliance requirements that prohibit BSL-licensed tooling. The fork maintains full backward compatibility with existing Terraform state files and HCL configurations up to version 1.5, allowing teams to evaluate the transition without rewriting infrastructure definitions. As of mid-2026, OpenTofu has stabilized its own provider registry and introduced features like client-side encryption for state backends that Terraform lacks.

Key technical differentiators in 2026

• State encryption: Native support for encrypting state files at rest using KMS, GCP KMS, or local keys before writing to remote backends like S3 or GCS.
• Provider ecosystem: A separate but largely compatible registry; most official AWS/Azure/GCP providers work identically, though some niche third-party providers may lag.
• No telemetry: Removed all optional usage tracking present in newer Terraform versions, simplifying air-gapped and restricted-network deployments.
• Community RFC process: Feature decisions follow a public RFC model rather than vendor-driven prioritization.

How do you migrate from Terraform to OpenTofu safely?

Migration is straightforward for standard setups but requires discipline for complex state. Because OpenTofu reads Terraform state files directly, you do not need to export and re-import resources. The primary risk lies in provider version mismatches and backend configuration nuances. Always test in a non-production environment first and ensure your CI/CD pipeline references the correct binary.

1. Audit provider dependencies: Run tofu providers lock against your existing lock file to verify all required providers are available in the OpenTofu registry at compatible versions.
2. Update CLI commands: Replace terraform with tofu in scripts, Makefiles, and CI pipelines. The subcommands (init, plan, apply) remain identical.
3. Validate state integrity: Execute tofu plan -refresh-only to confirm the state file parses correctly and matches real infrastructure without proposing destructive changes.
4. Test backend connectivity: Verify remote state access works with your existing credentials; OpenTofu supports S3, GCS, Azure Blob, Consul, and HTTP backends natively.
5. Enable state encryption (optional): Add an encryption block to your backend config if you want to leverage this OpenTofu-exclusive feature during migration.

# Example: Backend config with native state encryption
terraform {
  backend "s3" {
    bucket         = "infra-state-prod"
    key            = "global/network.tfstate"
    region         = "us-east-1"
    encrypt        = true
  }
  encryption {
    method = "aws_kms"
    kms_key_id = "arn:aws:kms:us-east-1:123456789:key/abcd-efgh"
  }
}

A common mistake is assuming all Terraform Cloud-specific features have equivalents. OpenTofu does not support Terraform Cloud workspaces, private module registries, or Sentinel policies. Teams relying on these must adopt alternatives like Terragrunt for workspace orchestration or OPA for policy-as-code before migrating.