OpenTofu: product and architecture
This OpenTofu review covers the infrastructure-as-code tool that exists because a licence changed. OpenTofu declares cloud resources in HCL and reconciles them against recorded state — the same model, the same language and the same provider ecosystem as Terraform, from which it was forked in 2023 after HashiCorp moved Terraform to the Business Source Licence. It is now a Linux Foundation project under MPL-2.0 with open governance. We evaluated it on its licence and governance, its documented feature set, and its GitHub repository, which carried 30,226 stars when we checked on 19 September 2026.
Overview
OpenTofu is a fork with an unusual origin: it was not started because the software was inadequate but because its licence stopped being open source. In August 2023 HashiCorp relicensed Terraform under the Business Source Licence, which restricts use in competing offerings. A group of vendors and users who had built businesses and tooling on Terraform responded by forking the last MPL-2.0 release, and the result was donated to the Linux Foundation.
That history determines who the tool is for. If the licence change did not affect you, the case for OpenTofu is governance and insurance rather than capability. If it did — because you sell a product that manages infrastructure for others, or because your legal team will not accept a licence that reserves the right to define a competitor — the case is straightforward.
The practical consequence for most teams is that migration is a binary swap. OpenTofu reads existing HCL and consumes the same provider registry, so the switching cost is small compared with the usual cost of changing an infrastructure tool.
Key Features and Architecture
The core model is declarative state reconciliation. You describe the resources you want in HCL, the tool builds a dependency graph, compares it against recorded state, and produces a plan of creations, updates and destructions to apply. State can live locally or in a remote backend, and the plan-then-apply cycle is the safety mechanism that makes the tool usable on production estates.
Providers are the integration surface, and this is where the fork's compatibility matters most. OpenTofu consumes the same provider ecosystem that Terraform uses, so the AWS, Azure, Google Cloud, Kubernetes and hundreds of other providers a team already depends on continue to work. An infrastructure tool is only as useful as its provider coverage, and forking without it would have been pointless.
Since the fork, OpenTofu has added capabilities of its own rather than only tracking upstream. Client-side state encryption is the clearest example: state files routinely contain secrets as a side effect of recording resource attributes, and encrypting them before they reach a backend closes a gap that previously depended on trusting the backend.
Governance is a feature in this category rather than a footnote. As a Linux Foundation project, the roadmap is decided in public by a steering committee rather than by a single vendor, which is the specific risk the fork was a response to.
Ideal Use Cases
OpenTofu fits any team whose legal position makes the Business Source Licence unacceptable. That is the clearest case and it needs no further analysis.
It fits vendors and consultancies that manage infrastructure on behalf of customers, where a licence reserving rights against competing offerings creates real exposure.
It fits organisations that want their infrastructure tool governed in the open. If a single vendor's future licensing decisions are a risk your architecture review takes seriously, a foundation project removes that particular question.
It fits teams that want state encryption without buying a managed backend to get it.
Do not switch to OpenTofu if you are a satisfied Terraform user with no licence exposure, an existing Terraform Cloud relationship and no appetite for migration work. The fork is compatible, but compatibility is not zero cost: you will re-point CI, re-validate provider versions and retrain habits, and in exchange you get governance rather than capability. That is a real benefit, but it is not an operational one, and a team with no licence concern is buying insurance it may not need.
Pricing and Licensing
OpenTofu is free under MPL-2.0, with no paid tier and no commercial edition. It is a Linux Foundation project, not a vendor product, so there is nothing to negotiate and no upgrade path being held back.
The licence is the product decision here. MPL-2.0 is an OSI-approved open-source licence with file-level copyleft: modifications to OpenTofu's own files must be shared, while your infrastructure code and anything you build alongside it are unaffected. That is materially different from a licence that permits production use while reserving the right to define what counts as a competing offering.
Your real costs are the infrastructure being managed and wherever state is kept. Several vendors sell managed state backends, policy engines and run pipelines that work with OpenTofu, and those carry their own prices — but none of them is OpenTofu, and none is required to use it.
We recommend budgeting for the state backend deliberately rather than by default. Teams migrating from a managed Terraform service sometimes discover that the tool was free and the service around it was the spend.
Strengths & Trade-offs
Pros
- OSI-approved licence with foundation governance. MPL-2.0 under the Linux Foundation, with a public steering committee rather than one vendor's roadmap.
- Provider ecosystem preserved. The same providers a Terraform estate already uses continue to work.
- Migration is close to a binary swap. Existing HCL and state are read directly.
- Client-side state encryption. Addresses secrets in state without depending on a particular backend.
- No commercial edition withholding features. Everything in the project is in the free tool.
Cons
- The reason to adopt is governance, not capability. A team with no licence exposure gains little functionally.
- Ecosystem documentation still assumes Terraform. Tutorials, Stack Overflow answers and vendor guides largely name the original, which costs newcomers translation effort.
- Two projects now diverge. Features added on either side are not automatically present on the other, and that gap grows with time rather than shrinking.