OpenTofu
OpenTofu is an open-source, community-driven fork of Terraform — the same HCL configuration language, the same workflow (plan/apply), the same provider ecosystem, under a truly open license (MPL 2.0) governed by the Linux Foundation. It exists because in August 2023 HashiCorp relicensed Terraform from the open-source MPL to the Business Source License (BSL), and a large slice of the community responded by forking the last MPL version.
For anyone doing infrastructure as code, OpenTofu is significant as both a tool and a precedent: a near-drop-in Terraform replacement that stays open, and one of the highest-profile "the community forks in response to a license change" events in recent open-source history. It has since shipped features Terraform didn't have, making it a genuine alternative rather than merely a frozen copy.
TL;DR
- OpenTofu is a fork of Terraform created after HashiCorp switched Terraform to the non-open-source BSL license in 2023.
- It's highly compatible: same HCL, same commands (
tofu plan/tofu apply), same state model, and it uses the same provider and module registries (AWS, Azure, GCP, etc.). - Governed by the Linux Foundation under the open MPL 2.0 — community-driven, not single-vendor-controlled.
- Migration from Terraform is usually trivial (swap the binary), diverging only as versions drift apart over time.
- OpenTofu has added its own features — notably client-side state encryption and enhanced dynamic provider configuration — that Terraform lacks.
- Choosing between them is now partly licensing/governance philosophy and partly a real feature/ecosystem comparison, since they've begun to diverge.
Why OpenTofu Exists
The short history matters because it explains the whole tool:
The BSL doesn't affect most end users' day-to-day use of Terraform, but it removed the open-source guarantee and specifically constrains vendors building on Terraform — which is what triggered the fork. OpenTofu's pitch: the IaC tool you depend on should be community-governed and can't be relicensed out from under you.
How Compatible Is It?
Very — that's the entire point of a fork:
Migration from a compatible Terraform version is typically: install tofu, run tofu init, run tofu plan (verify no changes), done. The divergence grows only as the two projects add different features over time — new Terraform features won't automatically appear in OpenTofu and vice versa, so the "drop-in" quality is strongest between contemporaneous versions and weakens the further they drift.
What OpenTofu Adds
OpenTofu isn't just a frozen snapshot — it ships features on its own roadmap:
- Client-side state encryption — a frequently-requested capability Terraform long lacked. State files hold secrets (passwords, keys) in plaintext by default; OpenTofu can encrypt state at rest client-side, a real security improvement. (See the Terraform page on why state is sensitive.)
- Enhanced dynamic provider/module configuration — more flexible use of variables in places Terraform restricts (e.g.,
for_eachon provider configurations). - Community-driven feature process — an open RFC process where the roadmap is set in the open rather than by one vendor.
Terraform, meanwhile, continues shipping its own features (Stacks, enhanced testing, tighter HCP Terraform integration). The two are now genuinely different products with overlapping-but-diverging capabilities — which turns "OpenTofu vs Terraform" from a pure licensing question into a real technical comparison.
Choosing Between OpenTofu and Terraform
Practical reality: for most teams, either works, and the decision is often values-driven (open-source commitment) plus whether OpenTofu's specific features (state encryption) or Terraform's platform (HCP Terraform) matter to you. New projects wanting open-source assurance increasingly default to OpenTofu; teams heavily using Terraform Cloud/HCP tend to stay on Terraform. Both share the provider ecosystem, so you're not betting the farm either way — and the concepts (state, plan/apply, modules) in the Terraform and Infrastructure as Code pages apply identically.
Common Mistakes
Assuming Perpetual Drop-In Compatibility
The two projects diverge over time — a config using a Terraform-only feature won't work in OpenTofu (and vice versa). Compatibility is strong today and between close versions, but pin and test rather than assume any Terraform config runs unchanged forever.
Mixing Both Against One State
Running terraform apply and tofu apply against the same state as versions diverge risks state-format or feature mismatches. Pick one tool per project/state and standardize.
Treating State as Non-Sensitive (Either Tool)
Terraform and OpenTofu both write state containing secrets. OpenTofu's encryption helps, but the fundamentals apply to both: secure the state backend, restrict access, and never commit state to git. See Secrets Management.
Choosing on License Alone Without Checking Features
Since the projects have diverged, "OpenTofu because open source" can miss that you depend on a Terraform-only feature (or vice versa). Check the actual feature and tooling fit, not just the license.
FAQ
Is OpenTofu production-ready?
Yes — it's stable, Linux Foundation-governed, backed by multiple companies, and used in production by many organizations. It uses the same battle-tested provider ecosystem as Terraform. The "younger project" caveat is about the fork's age, not instability.
Is it hard to migrate from Terraform?
Usually easy for projects on a compatible Terraform version — install OpenTofu, tofu init, verify tofu plan shows no changes, and switch. Complications arise if you use Terraform-version-specific features newer than the fork point or HCP Terraform-specific functionality. Test in a non-production workspace first.
Why did HashiCorp change the license?
To restrict competitors (companies building commercial products on Terraform, like some IaC platforms) from doing so under the permissive MPL — the BSL allows most use but forbids offering a competing commercial product. Whether that was justified is debated; the community's response was the fork. HashiCorp was later acquired by IBM, which added further context to the ecosystem's calculus.
Do I need OpenTofu, or is Terraform fine?
For most users, Terraform's BSL doesn't restrict normal use, so Terraform remains fine day-to-day. Choose OpenTofu if open-source governance matters to you, you want its specific features (state encryption), or you use vendor platforms aligned with it. Both are legitimate; this is not an urgent forced migration for typical teams.
Are Terraform modules and providers compatible?
The provider ecosystem is shared — the same providers (AWS, Azure, GCP, etc.) work with both. Modules are largely compatible; OpenTofu also runs its own registry. This shared foundation is why switching is low-risk.
Related Topics
- Terraform — The tool OpenTofu forked from (concepts apply to both)
- Infrastructure as Code — The discipline both implement
- GitOps — The declarative-config philosophy, one level up
- Secrets Management — Why state encryption matters
- Pulumi — The programming-language IaC alternative
- Open Source Licensing — The BSL-vs-MPL question that drove the fork
- Cloud Networking — Common target of both tools