Comparison
Three years after the fork, which engine should you run?
The verdict
Starting from scratch, use OpenTofu. It is MPL 2.0 under Linux Foundation governance, it reads the same HCL and the same state, it ships features Terraform has not matched - client-side state encryption being the obvious one - and the migration cost from a small project is close to zero. Stay on Terraform if you are already invested in HCP Terraform, if Sentinel policy or Stacks are load-bearing, or if you buy vendor support and need a name on a contract. What you should not do is migrate a large working estate purely on principle: the two engines are still compatible enough that switching later is cheap, so the cost of waiting is low.
The context, briefly: HashiCorp relicensed Terraform from MPL 2.0 to the Business Source Licence in August 2023, the community forked it, and the fork became OpenTofu under the Linux Foundation. IBM completed its acquisition of HashiCorp in early 2025. By April 2026 OpenTofu sat around 12 percent adoption among infrastructure practitioners with roughly another quarter evaluating or expanding it, while Terraform remained the clear incumbent by installed base.
Terraform vs OpenTofu on the dimensions that decide it
Both engines were at comparable maturity in mid-2026: Terraform in the 1.14 line, OpenTofu in the 1.12 line. Neither is a beta project and neither is standing still.
| Dimension | Terraform | OpenTofu |
|---|---|---|
| Licence and governance | Business Source Licence 1.1, single vendor, now inside IBM. Free for the overwhelming majority of users, but the terms can change again. | MPL 2.0, OSI-approved, multi-vendor governance under the Linux Foundation. The licence cannot be pulled back. |
| Cost at real usage | CLI is free. HCP Terraform is priced per managed resource, which scales with your estate whether or not it changes. | Free, with paid managed backends available from several independent vendors. Competition on that layer is the point. |
| State encryption | Relies on the backend encrypting at rest. State reaching the bucket in plain text is accepted as normal. | Native client-side encryption of state and plan files with AWS KMS, GCP KMS, or PBKDF2 key providers. The standout differentiator. |
| Recent feature direction | List resources and a query command for bulk discovery of unmanaged infrastructure, plus action blocks that invoke provider operations on lifecycle triggers. | Early variable evaluation in backends and module sources, for_each on providers, OCI registries, dynamic prevent_destroy. |
| Provider ecosystem | The HashiCorp registry is the canonical distribution point and where new providers land first. | Its own registry mirrors the same mostly MPL-licensed providers. In practice, coverage is a non-issue for mainstream clouds. |
| Managed platform | HCP Terraform with remote runs, private module registry, Sentinel policy, and Stacks. Mature and deeply integrated. | No first-party platform by design. Third parties fill the gap, which means choice and also means integration work. |
| Documentation and hiring | Every vendor tutorial, every Stack Overflow answer, and every job posting says Terraform. | Good first-party docs, but you translate community material. The HCL is identical, so translation is mechanical. |
| Exit cost | Low leaving for OpenTofu, unless you depend on HCP Terraform features that have no direct equivalent. | Low returning to Terraform, provided you have not adopted OpenTofu-only syntax such as an encryption block. |
When each engine is the right call
Choose OpenTofu when
- The project is greenfield. There is no migration to pay for and no reason to inherit a restrictive licence.
- Secrets end up in state and your security team wants them encrypted before they leave the machine, not merely encrypted at rest by the bucket.
- You ship software that provisions infrastructure for customers, which is exactly the scenario the Business Source Licence exists to restrict.
- Procurement or legal has an open question about the licence, and an OSI-approved answer closes it permanently.
- You want a backend vendor you can replace, rather than one bundled with the engine.
- You keep hitting the multi-region provider boilerplate that provider-level for_each removes.
Choose Terraform when
- HCP Terraform already runs your workflow. Remote state, run tasks, Sentinel policy, and Stacks are not one-for-one replaceable.
- You have a support contract and an escalation path, and someone senior wants a vendor name on the incident.
- You need to adopt a large existing estate and the new list resources and query workflow saves you weeks of import scripting.
- Your team is large, junior-heavy, and learns from vendor documentation that assumes the Terraform binary.
- You depend on a niche provider or partner integration that has only ever been certified against Terraform.
- Nothing is broken and the estate is enormous. "It works and the licence does not restrict us" is a legitimate reason to stay.
What the fork looks like in practice
Start with what the licence actually says, because the internet is bad at this. The Business Source Licence does not stop you using Terraform to manage your own infrastructure, at any scale, for free. What it restricts is offering a competing product to HashiCorp's - a hosted Terraform service, essentially. For a normal engineering organisation this is not a functional constraint. It is a governance risk: the terms were changed once by a single vendor, and nothing prevents a future change. Whether that risk matters is a question for your legal team, not your platform team.
What has genuinely changed since the fork is that the codebases stopped tracking each other. For the first year, OpenTofu was mostly Terraform with a different logo. It no longer is. State encryption arrived on the OpenTofu side and Terraform still has no equivalent, which is the single most concrete reason to pick the fork. Terraform meanwhile shipped list resources and the query workflow, which turns bulk discovery of unmanaged infrastructure into a supported operation instead of a weekend of scripting. Neither project is coasting.
Migration in the common case is genuinely a one-liner. Install the tofu binary, run tofu init against the existing backend, and the state is read as it stands. The work that takes real time is everywhere else: CI jobs that invoke a named binary, wrapper tooling such as Terragrunt or Atlantis, pre-commit hooks, policy-as-code, container images, and the internal runbook that says "run terraform apply". Budget for the plumbing, not the engine. Then run a plan and confirm it proposes zero changes before you let anyone apply.
Large organisations have converged on a dual-engine pattern that is worth knowing about: keep Terraform where HCP Terraform is embedded and use OpenTofu for new stacks and for anything where state encryption is a requirement. Because HCL and the state format remain compatible, teams can share modules across both. It is more moving parts than one engine, and it is a reasonable way to stop a migration decision from blocking new work for two quarters.
One caution in the other direction. The compatibility that makes this all cheap is a shrinking asset. Every OpenTofu-only feature you adopt - an encryption block, a variable in a backend, provider-level for_each - makes the return trip harder. That is fine, and it is what forks are for. Just make the choice deliberately rather than discovering it during an audit. Documentation: opentofu.org and developer.hashicorp.com/terraform.
Where this fits in an infrastructure stack
Whichever engine you pick, the syntax is shared: the Terraform and OpenTofu cheatsheet covers HCL blocks, the type system, state commands, and workspaces for both, and flags the divergences in one callout.
If HCL itself is what you are questioning, the infrastructure as code roundup weighs Pulumi, SST, and Ansible against both engines. To run plan and apply on every pull request, see the CI/CD pipeline guide, and for the platforms these configurations target, the hosting directory.