OpenTofu: the MPL-2.0 fork of Terraform and what its release cadence tells you
OpenTofu lets you declaratively manage your cloud infrastructure.
At a glance
- What is it?
- OpenTofu is a Go infrastructure-as-code tool under MPL-2.0, distributed through parallel minor release lines. The interesting question for an adopter is not whether it plans and applies infrastructure, but how its versioning, licensing and registry policy affect a migration.
- Who is it for?
- Adopt OpenTofu if you need an infrastructure-as-code engine whose licence is MPL-2.0 and whose release lines you can pin deliberately: v1.11.14 and v1.12.6 are patch releases on two maintained branches, so you must decide which line you track before you migrate.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenTofu replaces, and for whom
OpenTofu describes itself as an OSS tool for building, changing and versioning infrastructure, able to manage existing and popular service providers as well as custom in-house solutions. That sentence defines the audience: teams that already treat infrastructure as versioned text and want the engine to be open source. The README frames the value in four claims. Infrastructure is described in a high-level configuration syntax so a datacenter blueprint can be versioned and re-used. A planning step produces an execution plan showing what apply will do. A resource graph is built across all resources, and non-dependent resources are created and modified in parallel. Change automation then applies complex changesets with minimal human interaction. The word to notice is parallel. The graph is not decoration; it is the mechanism that decides ordering and concurrency, and it is also why a plan can be reviewed before anything is touched. If your current process is a sequence of console clicks or a shell script with hardcoded ordering, the plan output is the part that changes your working day. If you already run a declarative tool, the plan is familiar and the decision shifts to licensing, release cadence and registry access.
Plan, graph, apply: the data flow the README describes
The mechanism as documented runs in three stages. Configuration is parsed into a desired state. OpenTofu builds a graph of all resources, which encodes which resources depend on which. It then generates an execution plan, described as showing what OpenTofu will do when you call apply, so that you avoid surprises when it manipulates infrastructure. Apply walks that graph, parallelising any resources that are not dependent on each other. Two consequences follow from this ordering. First, the plan is a derived artefact, not a stored one: it is produced from configuration plus whatever state the tool holds, so reviewing a plan is the review gate, and the README treats that gate as the reason the tool is safe. Second, parallelism is bounded by the graph, not by a global setting. A resource with no edges to another can be created at the same time, which is why a large independent fleet converges faster than a chain of dependencies. The README does not describe the state backend, provider protocol or lock file format, so anything you read elsewhere about those internals is outside this material and should be checked against the docs before you rely on it.
Installing and running it: what the material actually gives you
The README points to the install documentation at opentofu.org/docs/intro/install rather than listing package commands, so the only concrete acquisition path stated here is the nightly channel. Nightly builds for the latest changes on main live at https://nightlies.opentofu.org/nightlies, and https://nightlies.opentofu.org/nightlies/latest.json is kept up to date with the latest build information for tooling that wants to automate the fetch. The README is explicit that these are experimental and not intended for production use, and that each build is removed after 30 days. That last clause matters more than it looks: any script pinned to a specific nightly URL will break within a month, so if you automate against nightlies you must resolve latest.json each time rather than hardcode a build. For stable use, the releases named in the repository are v1.13.0-beta1, v1.12.6 and v1.11.14. The beta is a pre-release; the other two are patch releases. Beyond the install page, no configuration keys, environment variables or CLI flags appear in the supplied README, so I cannot state the exact command surface from this material. Treat the install page and the docs as the source for those, and do not assume a flag exists because a similar tool has it.
Three release lines at once is the real operational cost
The release list is the most informative thing in the repository. On the same day, 19 August 2026, the project published v1.12.6 and v1.11.14. A beta for v1.13.0-beta1 followed on 27 August 2026, and the default branch saw its last push on 10 September 2026. That pattern means at least two stable minor lines are maintained in parallel, each receiving patch releases, while the next minor is in beta. For an adopter this is a choice you have to make explicitly and then live with. Tracking the newest minor gets you fixes and any new behaviour first, but it also means the next minor bump arrives while you are still stabilising the current one. Staying on the older line buys predictability at the cost of backporting your own fixes if you hit something the maintainers have already solved on the newer branch. The material does not state a support window or an end-of-life policy for any line, so before you commit you should confirm how long v1.11 and v1.12 will keep receiving patches. Upgrading is not a single event here; it is a recurring decision about which branch your state and modules are validated against.
MPL-2.0, the registry policy, and where the tool stops being neutral
OpenTofu is licensed under the Mozilla Public License v2.0. MPL-2.0 is a file-level copyleft licence: modifications to covered files must be made available under the same licence, while larger works that combine those files with other code can be distributed under different terms. That is a meaningful difference from a permissive licence if you patch the engine itself and redistribute it, and it is a different question from what your own configuration files are licensed under, which the licence does not govern. This is not legal advice; if you vendor or modify OpenTofu, have your own counsel read the licence text. There is a second, less obvious constraint. The README states that in an effort to comply with applicable sanctions, access is blocked from specific countries of origin, and it links the Registry Inclusion Policy in the opentofu/registry repository. That policy sits between you and module or provider downloads. A team whose CI runners or developers originate from a blocked country can find that the engine installs fine and then fails to fetch what the configuration references. This is a policy decision, not a bug, and it is the sort of thing that surfaces late, during a migration, rather than during evaluation.
When OpenTofu is the wrong tool
The clearest failure mode is the nightly channel. The README calls those builds experimental, not intended for production, and says each is removed after 30 days. Any workflow that depends on a nightly is therefore on a clock, and the removal is silent from the consumer's point of view until a fetch fails. The second case is registry reachability. If your organisation operates from a country the Registry Inclusion Policy blocks, the tool's own documentation says access is blocked, and no amount of local configuration changes that. The third case is subtler: if your infrastructure is small and mostly hand-managed, the plan and graph machinery is overhead you pay for on every change, and the parallel apply described in the README buys you little when there are only a handful of independent resources. The README also does not describe import of existing resources, state migration, or provider compatibility in the supplied text, so if your decision hinges on moving an existing estate without recreating it, that is a gap to close from the docs before you commit. None of these make the project bad. They define the boundary of where it fits.
The alternative, and how the approach differs
The obvious alternative is Terraform, the tool OpenTofu was forked from, and the difference is not the plan-and-apply model, which both share. The difference is governance and licensing. Terraform is developed by HashiCorp under the Business Source License, which restricts use in competing products; OpenTofu is developed in the open under MPL-2.0, with a public contribution guide, GitHub Discussions, a Technical Steering Committee that meets every other Tuesday at 4pm UTC, and community meetings on Wednesdays at 12:30 UTC. That structure means the roadmap is set in public meetings rather than by a single vendor, which is either the reason you choose it or the reason you do not: public governance is slower and more negotiated than a vendor roadmap, and the parallel release lines visible in the release list are part of that cost. If your constraint is licence compatibility with a commercial product you ship, MPL-2.0 is the deciding factor and the fork is the answer. If your constraint is a vendor support contract with a named escalation path, that is a different purchase and OpenTofu's README does not offer one.
What to verify before you migrate
Three things are worth checking against the docs rather than assuming. First, which minor line you will track and for how long: v1.12.6 and v1.11.14 both exist, and the material gives no support window, so ask before you pick. Second, whether your configuration applies cleanly on that line, because the release list shows the project is willing to ship a beta for the next minor while patching two older ones, and that is a cadence you will be living with. Third, whether your runners can reach the registry at all, given the country-level blocking described in the README and the Registry Inclusion Policy it links. If you only want a stable engine and your registry access is unencumbered, the practical setup is to pin a released version, keep your state and modules in version control alongside the configuration, and treat plan output as the review artefact the README says it is. The nightly channel at https://nightlies.opentofu.org/nightlies exists for testing main, and the 30-day removal window is the reason to keep it out of anything you depend on.
Editorial conclusion
Adopt OpenTofu if you need an infrastructure-as-code engine whose licence is MPL-2.0 and whose release lines you can pin deliberately: v1.11.14 and v1.12.6 are patch releases on two maintained branches, so you must decide which line you track before you migrate. Do not adopt it if your organisation depends on registry access from a country the Registry Inclusion Policy blocks, or if you need a nightly build in production, since those are experimental and each is removed after 30 days. Verify first that your existing configuration applies cleanly on the minor line you intend to keep, and read the Registry Inclusion Policy before you assume module and provider downloads will resolve.
Community notes