OpenTofu is an open-source infrastructure as code tool that reads declarative configuration files, compares them with the real state of cloud and on-premises resources, and creates, changes or destroys those resources until reality matches the code. It began in 2023 as a community fork of Terraform after HashiCorp moved Terraform from the Mozilla Public License to the Business Source License, and it is governed under the Linux Foundation with an MPL 2.0 license.
In infrastructure as code within the cloud domain, OpenTofu occupies the provisioning layer: it builds networks, virtual machines, databases, DNS records and identity policies. It keeps the HCL configuration language, the provider plugin model and the state file format that Terraform users already know, so most existing projects migrate with little or no change.
How OpenTofu turns configuration into infrastructure
OpenTofu works through a plan and apply cycle. The engine parses the configuration, builds a dependency graph of resources, reads the recorded state and asks each provider for the current attributes of existing objects. It then calculates the difference and executes the required API calls in parallel wherever the graph allows.
Three components carry this process. Providers are separate plugins that translate resource definitions into calls to a specific API, such as a public cloud, Kubernetes or a DNS service. The state file maps every declared resource to its real identifier. Modules package reusable groups of resources with input variables and outputs.
The following table summarizes the main commands of the workflow and what each one changes.
| Command | What it does | Changes infrastructure |
|---|---|---|
tofu init | Downloads providers and modules, configures the backend | No |
tofu plan | Shows the proposed creates, updates and deletes | No |
tofu apply | Executes the plan after confirmation | Yes |
tofu destroy | Removes every resource managed by the configuration | Yes |
tofu import | Brings an existing resource under management | No, only state |
tofu state | Inspects, moves or removes entries in the state file | No, only state |
Features that distinguish OpenTofu
Beyond compatibility, OpenTofu has added capabilities that its community requested for years. The most cited is client-side state encryption, introduced in version 1.7, which encrypts the state and plan files with keys from a passphrase, a cloud key management service or another key provider before they reach the backend. This matters because state files often contain secrets such as database passwords and private keys in plain text.
The table lists several notable features and the problems they address.
| Feature | Introduced | Problem it solves |
|---|---|---|
| State encryption | Version 1.7 | Secrets readable in remote state storage |
| Provider-defined functions | Version 1.7 | Custom logic without external scripts |
| Early variable evaluation | Version 1.8 | Variables not allowed in backend and module source blocks |
| Provider for_each | Version 1.9 | Repeating provider blocks for many regions or accounts |
| Exclude flag | Version 1.9 | Applying everything except selected resources |
OpenTofu also runs its own public registry for providers and modules. It mirrors the large majority of community providers, so the familiar source addresses keep working, and the project accepts signed provider releases through its own key verification process.
OpenTofu compared with Terraform and Ansible
OpenTofu and Terraform share a codebase up to Terraform 1.5.x, so their core semantics are identical at the fork point and have diverged gradually since. Ansible is a different kind of tool: it is primarily a configuration management and automation system that runs ordered tasks over SSH, while OpenTofu reconciles a declared end state through APIs.
| Aspect | OpenTofu | Terraform | Ansible |
|---|---|---|---|
| License | MPL 2.0, open source | BSL 1.1, source available | GPL 3.0, open source |
| Governance | Linux Foundation, community | Single vendor | Community with vendor sponsor |
| Model | Declarative, state based | Declarative, state based | Mostly procedural playbooks |
| Main job | Provisioning resources | Provisioning resources | Configuring hosts and apps |
| State file | Yes, optional encryption | Yes, no native encryption | No persistent state |
| Binary name | tofu | terraform | ansible-playbook |
In practice, teams often combine the tools: OpenTofu creates the servers and networks, and Ansible configures the software inside them. Choosing between OpenTofu and Terraform is mostly a question of licensing, governance and feature roadmap, not of language or syntax.
Migrating to and operating OpenTofu
Migration from Terraform is usually a binary swap: back up the state, replace the terraform command with tofu, run tofu init and confirm that tofu plan reports no changes. The supported path depends on the Terraform version, because state formats and features written by newer Terraform releases may not be readable by OpenTofu.
| Starting point | Recommended action | Reason |
|---|---|---|
| Terraform 1.5 or earlier | Switch directly to a current OpenTofu release | Shared code base, compatible state |
| Terraform 1.6 to 1.8 | Follow the version-specific migration guide | Minor feature differences |
| Terraform 1.9 or later | Remove newer-only features first, then test | Possible state incompatibility |
| Heavy use of vendor cloud platform | Evaluate a third-party runner | Vendor services stay Terraform only |
For daily operation, store state in a remote backend with locking, such as an object storage bucket with a lock table, pin provider versions in the dependency lock file, and run plans in a CI pipeline so every change is reviewed before apply.
Limitations and common mistakes
OpenTofu inherits the structural weaknesses of state-based tools. A lost or corrupted state file breaks the link between code and resources, and manual changes in a cloud console create configuration drift that the next plan will try to reverse.
- Mixing binaries on one state: running Terraform and OpenTofu alternately against the same state can produce unreadable state after either tool upgrades it.
- Losing the encryption key: encrypted state without its key is unrecoverable, so key rotation and backup need a documented procedure.
- Unpinned providers: floating versions let a provider release change behavior between plan and apply.
- Monolithic root modules: one large configuration slows plans and widens the blast radius of every mistake.
- Skipping plan review: an apply without reading the plan is the most common cause of accidental resource deletion.
In simple terms
OpenTofu is a tool that builds computer infrastructure from a written description. Instead of clicking through a cloud website to create servers, networks and databases, an engineer writes down what should exist, and OpenTofu makes it so.
Think of it as an architect’s blueprint combined with a construction crew. The blueprint says what the building should look like, the crew compares it with what is already standing, and it only builds, repairs or removes what is different. OpenTofu is free and community owned, created so that this kind of tool stays open for everyone.
A practical example
A mid-sized software company manages about 40 cloud accounts with Terraform 1.5 and wants to avoid licensing uncertainty. The platform team backs up every state file, installs OpenTofu in its CI runners, replaces the command name in the pipeline scripts and runs tofu plan against each environment. All plans report zero changes, which confirms that the switch is safe.
The team then enables state encryption with keys held in the cloud key management service, because audit findings had shown database passwords stored in plain text in the state bucket. It also uses provider for_each to replace dozens of copied provider blocks for regional deployments. The result is the same infrastructure under an open license, with encrypted state and a noticeably shorter configuration.