OpenTofu: a Terraform-compatible infrastructure as code tool under MPL-2.0

What OpenTofu is for and who it fits

OpenTofu is a command line tool that builds, changes and versions infrastructure from a declarative configuration. The README describes it as an OSS tool that can manage existing and popular service providers as well as custom in-house solutions. That sentence is the whole scope: it is a general-purpose engine, not a product tied to one cloud.

The intended user is someone who already writes infrastructure as code and wants to keep doing so without changing the shape of their configuration. The README's key features list is a fair summary of what that person gets: a high-level configuration syntax that can be versioned like any other code, a planning step that produces an execution plan before anything changes, a resource graph that parallelizes independent work, and change automation that applies a changeset with minimal human interaction. Nothing in that list is specific to a particular vendor.

Where it does not fit is equally clear. There is no server component described in the README, no web interface, and no state service. The repository is a Go module, github.com/opentofu/opentofu, with the CLI entry point under cmd/. If you are shopping for a managed control plane, this is not one.

The planning step and the resource graph

Two mechanisms carry most of the design. The first is the execution plan. According to the README, OpenTofu has a planning step that generates a plan showing what it will do when you call apply, and the stated purpose is to avoid surprises when infrastructure is manipulated. The plan is therefore an artifact you read before you commit to a change, not a log written afterwards.

The second is the resource graph. OpenTofu builds a graph of all resources and parallelizes creation and modification of any non-dependent resources. Dependencies come from the configuration, so two resources that do not reference each other can be worked on at the same time, while anything downstream waits. The README frames this as both a speed property and an operator-facing one: it says operators get insight into dependencies in their infrastructure.

The two mechanisms are coupled. The plan is computed over the graph, so the ordering you see in a plan is the ordering the graph implies. That is also where a subtle failure mode lives: if a dependency is expressed only implicitly through a value that happens to be known at apply time, the graph cannot order it, and the plan will not show the ordering you expected. The README does not discuss this case.

Provider resolution is a separate data flow. The go.mod file shows the core repository depends directly on cloud SDKs including cloud.google.com/go/kms, cloud.google.com/go/storage, several github.com/Azure/azure-sdk-for-go modules, and github.com/aws/aws-sdk-go-v2. Those are the backends behind the built-in provider integrations, not something you configure.

Installing OpenTofu and running a first plan

The README does not contain installation instructions. It links to https://opentofu.org/docs/intro/install, and that page is the place to get the binary for your platform. What the repository does document is how to build the CLI yourself from source.

The Makefile defines a build target that produces a tofu binary in the current directory, with the version string taken from the git tag or, failing that, the commit hash. From a checkout of the repository:

make build

After that command finishes you should have an executable named tofu in the working directory. Its version string will read as a git describe value, for example a tag with a -dirty suffix if the tree has local modifications. The build target is also the reference for what a release binary is: the same go build invocation against ./cmd/tofu.

A container image is published as well. The Dockerfile installs git, bash and openssh on alpine:3.20 and sets the entry point to /usr/local/bin/tofu, so the image runs the CLI directly. Note the ONBUILD lines: the file prints a warning that using the OpenTofu image as a base image for your own builds is no longer supported as of OpenTofu 1.10, and then exits non-zero. The Dockerfile directs readers to https://opentofu.org/docs/intro/install/docker/ to build their own image instead.

For a first real use, the workflow the README implies is the one to follow: write configuration, run a plan, read it, then apply. The plan is the review surface, so the first session should end at the plan, not at the apply.

Where OpenTofu gets in your way

The most concrete limitation is registry access. The README states that, in an effort to comply with applicable sanctions, access from specific countries of origin is blocked, and points to the Registry Inclusion Policy in the opentofu/registry repository. This is not a bug or a misconfiguration you can work around in your own config; it is a deliberate policy applied at the registry. If your team or your CI runners sit in one of the affected regions, provider downloads will fail and no amount of local configuration changes that. The README does not list the affected countries, so the policy document is the only place to check.

The second constraint is the base image decision. The Dockerfile's ONBUILD instruction makes the published image explicitly unusable as a FROM base for derived images: it prints the warning and exits 1. Any internal golden image built on top of it will fail at build time, and the project's position is that you build your own image instead. That is a real migration cost for teams that standardized on wrapping the upstream image.

Third, the README does not document rollback. There is a plan step and an apply step, and change automation is described as applying complex changesets with minimal human interaction, but nothing in the README describes reverting an applied change as a first-class operation. Anyone whose workflow assumes an undo button should treat that as unverified and design around it, for example by keeping state backups and configuration history.

Finally, the top-level layout is large. cmd/, internal/, rfc/, scripts/, testing/, tools/, version/ and website/ sit alongside the Go module. That is the shape of a project with a substantial test and release pipeline, and contributing to the engine is not a small undertaking.

OpenTofu compared with Pulumi

The natural comparison for a team choosing an infrastructure tool is Pulumi, because it attacks the same problem from the opposite direction. OpenTofu is declarative configuration in a purpose-built syntax, described in the README as a high-level configuration syntax that produces a blueprint of your datacenter which can be versioned and reused. The unit you write is a configuration file, and the engine owns the plan and the graph.

Pulumi's approach is to let you write infrastructure in a general-purpose programming language. That difference matters in both directions. If your team already has strong Go, TypeScript or Python skills and wants loops, functions and type checking from the host language, OpenTofu's configuration language is a separate thing to learn. If your team wants the infrastructure definition to be readable by people who are not programmers, and wants the plan output to be the review artifact, the configuration-language route is easier to audit.

The other difference is packaging. OpenTofu is a single Go module with a CLI entry point under cmd/tofu and a Dockerfile that runs the binary directly. There is no runtime dependency on a language toolchain at execution time. That is a meaningful operational difference when the machine applying changes is a locked-down CI runner.

Both tools manage the same clouds. The go.mod file shows first-party dependencies on AWS, Azure, Google Cloud and Alibaba SDKs, so the built-in provider set is broad regardless of which engine you pick.

Maintenance, releases and what the licence means for you

The repository is not archived, and the last push was on 2026-09-10. Recent releases listed for the project are v1.13.0-beta1 on 2026-08-27, v1.12.6 on 2026-08-19, and v1.11.14 on 2026-08-19. Those dates show three maintained lines at once: a beta for the next minor, and patch releases on two earlier minors. The pattern to plan around is that a beta exists while stable patch releases continue, so pinning to a stable minor and moving deliberately is the lower-risk path.

Nightly builds exist for testing changes on main. The README is explicit that they are experimental, not intended for production use, and that each build is removed after 30 days. For automation, https://nightlies.opentofu.org/nightlies/latest.json is kept up to date with the latest build information. The 30-day removal window means a nightly pinned by URL will eventually 404, so any pipeline consuming nightlies needs to refresh that pointer.

The licence is the Mozilla Public License v2.0, and the Dockerfile carries both the OpenTofu MPL-2.0 notice and a HashiCorp copyright line for 2023. MPL-2.0 is file-level copyleft: modifications to files already under the licence stay under it, while separate files you add can carry other terms. That distinction matters if you fork the engine or patch internal packages. This is a description of the licence text, not legal advice; if you are redistributing a modified binary, have your own counsel read the licence and the copyright headers in the files you touch.

Upgrade cost is dominated by provider compatibility rather than the CLI. The go.mod pins a large set of cloud SDK versions, and the module targets go 1.27.1 with two godebug settings, tlsmlkem=0 and winsymlink=0, the latter referencing a specific pull request. Those are maintainer-level details, but they indicate that building from source requires a matching Go toolchain.

Editorial conclusion

Adopt OpenTofu if you already have Terraform configuration and want the same plan and apply workflow under MPL-2.0, with a Go-based CLI you can build from source with make build. Do not adopt it if you need a hosted UI or a cloud control plane, because the repository contains no such component and the README does not describe one. Before committing, verify that your existing providers resolve through the OpenTofu registry, since the README states that registry access is blocked from specific countries of origin under the Registry Inclusion Policy.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. opentofu/opentofu on GitHub
3. Project website
4. README
5. Releases