If you have been working in platform engineering or DevOps over the past couple of years, you have almost certainly come across OpenTofu. It has grown quickly from a community-led fork into a fully production-ready infrastructure tool used by organisations of all sizes.
But if you are still trying to get a clear picture of what it actually is, how it came to exist, and whether it is the right fit for your team, this guide gives you that. No jargon overload, no hype — just a straightforward explanation of what OpenTofu is and what it means for your infrastructure workflows.
What You Will Find in This Guide
• What OpenTofu is and where it came from
• Why the community created it in the first place
• How OpenTofu compares to Terraform
• What is new in OpenTofu 1.12.0
• How to install it and get started
• State management in OpenTofu
• Where OpenTofu is headed
• How env zero supports OpenTofu teams
What Is OpenTofu?
OpenTofu is an open source infrastructure as code tool that lets you define, provision, and manage cloud infrastructure using configuration files. If you have used Terraform before, OpenTofu will feel immediately familiar — the configuration language is the same, the commands work the same way, and your existing Terraform configurations will run on OpenTofu without modification in the vast majority of cases.
What makes OpenTofu different is not how it works, but who controls it. OpenTofu is governed by the Linux Foundation and developed by a community of engineers from multiple organisations. No single company owns it or can change its license. That is a meaningful distinction, and it is precisely why it was created.
Why OpenTofu Was Created
To understand OpenTofu, you need a bit of context about what happened in August 2023.
HashiCorp, the company behind Terraform, announced that it was changing Terraform’s license from the Mozilla Public License 2.0 — a well-established open source license — to the Business Source License 1.1 (BSL). The BSL is not an open source license. It allows you to use and read the code, but it restricts commercial use in ways that many companies found legally ambiguous and practically risky.
The reaction from the infrastructure community was swift and unusually unified. Within days, a coalition of companies — including Gruntwork, Spacelift, Harness, env zero, and Scalr — published what became known as the OpenTofu Manifesto. It asked HashiCorp to reverse the decision and keep Terraform open source. The manifesto gathered over 33,000 GitHub stars and support from more than 100 companies and hundreds of individual engineers within weeks.
When HashiCorp did not reverse its decision, the community did what open source communities do: they forked the last MPL-licensed version of Terraform and started a new project. That project was accepted by the Linux Foundation in September 2023 and renamed OpenTofu.
A Quick Timeline
Aug 2023 HashiCorp announces Terraform license change from MPL 2.0 to BSL 1.1
Aug 2023 OpenTofu Manifesto published — 33,000+ GitHub stars, 100+ companies pledge support
Sep 2023 Linux Foundation accepts the project; OpenTF is renamed OpenTofu
Jan 2024 OpenTofu 1.6.0 — first stable production-ready release
Apr 2024 OpenTofu 1.7 — native state file encryption introduced
Dec 2025 OpenTofu 1.11 — ephemeral values ship; secrets never touch the state file
May 2026 OpenTofu 1.12.0 released with dynamic prevent_destroy and provider improvements
OpenTofu vs Terraform: Key Differences
For most day-to-day work, OpenTofu and Terraform are functionally identical. You write HCL configuration files, run tofu init, tofu plan, and tofu apply, and your infrastructure gets provisioned. The mental model is the same, the provider ecosystem is largely shared, and your existing modules will work.
But there are meaningful differences worth knowing about, especially if you are making a decision about which tool to standardise on.
| Area |
OpenTofu |
Terraform (HCP) |
| License |
Mozilla Public License 2.0 — fully open source |
Business Source License 1.1 — not open source |
| Governance |
Linux Foundation — community-governed, no single owner |
HashiCorp / IBM — single-vendor controlled |
| State Encryption |
Built-in native encryption since v1.7 |
Not available natively |
| Ephemeral Values |
Supported since v1.11 — secrets stay in memory |
Not available |
| Provider Ecosystem |
OpenTofu Registry + compatible with Terraform providers |
Terraform Registry |
| Configuration Syntax |
HCL — same as Terraform |
HCL |
| Migration Effort |
Usually zero — swap binary, run tofu init |
N/A |
| Free Tier |
Fully open source, no managed tier required |
Free tier ended March 2026 |
The practical upshot: if your team is already using Terraform and is not on HCP Terraform’s managed platform, migrating to OpenTofu is a low-risk move. If you are evaluating tools for a new project, OpenTofu offers the same foundation with a more open governance model and a few features that Terraform has not shipped.
What Is New in OpenTofu 1.12.0
OpenTofu 1.12.0 was released on 14 May 2026. It is not a dramatic, everything-changes release — by design. The team intentionally focused this cycle on resolving long-standing friction points that experienced users had been working around for a while. The result is a set of improvements that make everyday workflows noticeably cleaner.
Dynamic prevent_destroy
Until 1.12.0, if you wanted to protect a production resource from accidental deletion, you had to hard-code that protection into your configuration. The problem with hard-coded protection is that it applies everywhere the same module is used — including your development environment, where developers actually need to be able to tear things down freely.
The workaround was usually some version of duplicating the module or accepting that dev environments would have production-level protections they did not need. Neither was satisfying.
In 1.12.0, prevent_destroy can now reference a variable. You set it to true for production and false for dev. One module, the right behaviour in every environment.
variable "protect_resources" { type = bool default = true } resource "aws_db_instance" "main" { lifecycle { prevent_destroy = var.protect_resources } }
Improved Provider Checksum Handling
Teams using shared plugin caches or internal provider mirrors frequently hit a frustrating problem: tofu init would fail because the lock file was missing checksums for platforms that were not the one being used locally. The fix was a manual tofu providers lock run — an extra step that caught people off guard and slowed down onboarding.
In 1.12.0, tofu init automatically generates a full set of checksums for all platforms. The manual step is no longer needed in most cases.
Parallel JSON and Human-Readable Output
Previously, when running OpenTofu commands, you had to choose between human-readable terminal output and machine-readable JSON output. You could not have both at the same time, which made it harder to build tooling on top of OpenTofu without losing the normal UI entirely.
The new -json-into=FILENAME option writes JSON output to a file while keeping the normal terminal output visible. Platform teams building deployment tooling on top of OpenTofu will find this particularly useful.
How to Install OpenTofu
Getting OpenTofu running is straightforward. The project provides packages for all major platforms.
On Linux
This is the standard method for installing OpenTofu using the official convenience script.
It downloads and installs the binary, then verifies that the CLI is correctly available in your system path.
# Using the official install script
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh
# Verify installation
tofu --version
The install script automatically fetches the latest stable OpenTofu release and places the tofu binary in your environment.
Running tofu --version confirms successful installation and ensures your system is ready for infrastructure provisioning workflows.
On macOS
This is the simplest way to install OpenTofu on macOS using Homebrew.
It ensures the CLI is installed and ready for infrastructure provisioning workflows.
# Using Homebrew
brew install opentofu
# Verify installation
tofu --version
After installation, the tofu --version command confirms that OpenTofu is correctly installed and accessible from your PATH.
This validates your environment is ready for running init, plan, and apply operations.
On Windows
This guide shows how to install OpenTofu on Windows using popular package managers like Chocolatey and Winget.
Both methods provide a quick and reliable setup for CLI usage.
Using Chocolatey
Or using Winget
winget install OpenTofu.OpenTofu
After installation, verify your setup using tofu --version.
These package managers automatically handle installation paths, making
Using tenv for Version Management
If your team works across multiple OpenTofu versions, or you need to switch between OpenTofu and Terraform on the same machine, tenv is worth looking at. It is a version manager written in Go that handles Terraform, OpenTofu, Terragrunt, and Atmos in one place.
Running Your First Plan
Once OpenTofu is installed, your existing Terraform configurations work without modification. Navigate to any directory with a .tf configuration and run:
tofu init tofu plan
That is it. You do not need to rewrite your configurations, change your module references, or update your provider blocks. The tofu binary replaces the terraform binary and reads the same files.
State Management in OpenTofu
OpenTofu manages infrastructure state the same way Terraform does: it keeps a state file that records everything it has created, and it compares that state against your configuration every time you run a plan.
For teams working alone, local state is fine. For teams working together, remote state is not optional — it is how you prevent two people from applying changes at the same time and ending up with a corrupted state file.
OpenTofu works with the same remote backend options as Terraform: S3 with DynamoDB locking for AWS teams, Azure Blob Storage for Azure, GCS for Google Cloud, and managed platforms like env zero for teams that want state handled automatically without configuring backend infrastructure themselves.
State File Encryption
One area where OpenTofu has moved ahead of Terraform is native state file encryption, introduced in version 1.7. Terraform state files have historically stored sensitive values — passwords, connection strings, API keys — in plain text. Teams have worked around this using Vault or carefully managed backend access controls, but neither is a complete solution.
OpenTofu’s built-in encryption means the state file itself can be encrypted at rest, independently of where it is stored. This is a meaningful security improvement for teams handling regulated data or working in environments with strict compliance requirements.
Where OpenTofu Is Headed
The OpenTofu project operates on a transparent, community-driven roadmap with public issue tracking and RFC processes. There is no single company deciding what gets built next.
Based on what the community has been discussing and working on, a few themes stand out for the near term:
• Continued quality-of-life improvements. The 1.12.0 cycle was deliberately focused on finishing things that were almost right. Expect more of that approach — resolving real friction rather than chasing headline features.
• Better tooling integration. The new -json-into flag in 1.12.0 is part of a broader effort to make OpenTofu easier to build tooling on top of, rather than just around.
• Provider ecosystem growth. The OpenTofu Registry continues to grow. The project aims to maintain full compatibility with the existing Terraform provider ecosystem while building its own community of contributors.
• Security and compliance features. State encryption was the first step. Ephemeral values in 1.11 was another. Expect more focus on making sensitive data harder to expose accidentally.
env zero and OpenTofu
env zero was one of the founding companies behind OpenTofu and has maintained core team members in the project since its inception. That relationship goes beyond marketing — it means env zero’s platform is built with OpenTofu support as a first-class concern, not an afterthought.
In practice, that means you can connect OpenTofu repositories to env zero exactly as you would Terraform repositories. Remote state is managed automatically, plans run on every pull request, approvals can be configured per environment, drift detection runs continuously, and cost estimation works before any apply is run.
For teams that are using both Terraform and OpenTofu — a common situation during migrations or in organisations that have different standards across teams — env zero supports both from the same platform without any configuration gymnastics.
Summary
OpenTofu exists because the infrastructure community decided that the tool they had built their work around for a decade deserved to stay open source. It is not a side project or an experiment — it is a production-ready, Linux Foundation-governed infrastructure tool with an active development community and a growing set of capabilities.
For teams already using Terraform, OpenTofu is worth evaluating seriously. The migration effort is usually minimal, the configuration language is identical, and you gain a tool that is not subject to unilateral license changes by a commercial vendor. Features like native state encryption and ephemeral values are already ahead of what the commercial version offers.
For teams starting fresh, OpenTofu is a solid default choice: mature, well-supported, truly open source, and backed by a community that has demonstrated it will keep moving forward regardless of what happens to any individual company.
.webp)
