OpenTofu 1.12 confronts Terraform: what’s changing and which to choose for IaC

OpenTofu was created less than three years ago in response to Terraform’s license change, but it is becoming increasingly difficult to describe it simply as an open fork. The release of OpenTofu 1.12 confirms that the project maintains high compatibility with Terraform while developing its own features such as destroy = false, dynamic prevent_destroy, and encryption of state and plan files. As a result, teams working with Infrastructure as Code (IaC) now have two paths with different technical, commercial, and governance considerations.

A quick overview of OpenTofu 1.12 versus Terraform in 20 seconds

• OpenTofu was launched in 2023 after HashiCorp changed Terraform’s license from MPL 2.0 to Business Source License (BSL).
• It is managed by the Linux Foundation and retains the MPL 2.0 license.
• OpenTofu 1.12 introduces prevent_destroy dynamically and destroy = false.
• It also features native encryption for states and plans.
• Its compatibility with Terraform significantly reduces the effort required to test a migration.

For an administrator accustomed to Terraform, the first thing that might surprise them when installing OpenTofu is actually how little it surprises.

The .tf files, HashiCorp Configuration Language (HCL), modules, providers, and much of the workflow remain familiar. Where previously you’d run terraform init, terraform plan, or terraform apply, OpenTofu uses tofu init, tofu plan, and tofu apply.

This is not accidental. The project positions itself as a direct replacement for Terraform and currently boasts an ecosystem of more than 3,900 providers and 23,600 modules. However, compatibility does not mean both projects will evolve identically over time.

Why was OpenTofu created?

To understand the comparison, it’s necessary to go back to August 2023.

Until then, Terraform was distributed under the open Mozilla Public License 2.0 (MPL 2.0). HashiCorp decided to change the license for its future versions of several products, including Terraform, to the Business Source License 1.1.

Terraform continued to be freely usable in many scenarios. HashiCorp specifies that internal organizational use is permitted, including using Terraform within CI/CD pipelines to manage internal infrastructure.

The change mainly impacts certain commercial uses.

The license restricts using the software to offer third-party hosted or integrated products that compete with HashiCorp’s paid versions. Therefore, describing the change simply as “Terraform became paid” would be inaccurate. The issue was about the conditions under which third parties could build certain businesses using its code.

It’s also important to differentiate this from HashiCorp’s subsequent acquisition by IBM. The license change was announced in August 2023, while IBM announced its acquisition agreement in April 2024.

A section of the community responded by creating OpenTF, a fork based on the latest Terraform code licensed under MPL.

In September 2023, the project moved to the Linux Foundation and adopted the name OpenTofu. Its first stable production release, OpenTofu 1.6, arrived in January 2024.

Since then, the two projects have followed separate paths.

Terraform remains within HashiCorp’s commercial ecosystem, now owned by IBM, while OpenTofu is governed by a community under the Linux Foundation and continues to be distributed under MPL 2.0.

OpenTofu 1.12 now includes its own features

Compatibility remains one of its biggest advantages, but OpenTofu is no longer merely reproducing Terraform’s legacy capabilities.

Version 1.12.0, released on May 14, 2026, brings several noteworthy improvements for system administrators, DevOps teams, and platform owners.

One of these is the prevent_destroy feature, which is now dynamic.

Until now, this protection required a static decision within the configuration. OpenTofu 1.12 allows variables and other values available within the module to control this behavior.

For example, you can create a single module for databases that prevents resource destruction in production by default but allows it in development environments.

variable "prevent_destroy_database" {
  type    = bool
  default = true
}

resource "example_database" "database" {
  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

This makes the module adaptable to different environments without maintaining separate variants.

Another particularly practical new feature is:

destroy = false

This option modifies what happens when OpenTofu stops managing a resource.

Typically, removing a resource from the configuration results in the tool planning its deletion along with associated infrastructure. With destroy = false, OpenTofu can remove the resource from its state without destroying the actual resource.

This is a significant difference.

The virtual machine, database, volume, or cloud resource remains, but OpenTofu no longer manages it.

This can be useful during migrations, infrastructure reorganizations, or situations where certain resources need to exit IaC management without being deleted.

It also requires caution: once the resource is forgotten, OpenTofu no longer knows about it. If it is re-declared with the same address later, OpenTofu might try to recreate it, meaning an import may be necessary.

OpenTofu 1.12 also improves provider checksum management, supports outputting both human-readable and JSON formats simultaneously with -json-into, and parallelizes certain provider installation requests during tofu init to speed up the process.

Encryption of state files: a particularly interesting difference

One of the most significant native features was introduced earlier in OpenTofu 1.7: State and Plan Encryption.

The state file is one of the most sensitive components in any infrastructure managed via Terraform or OpenTofu.

It may contain IP addresses, resource IDs, configurations, and depending on the providers used and infrastructure design, sensitive data.

OpenTofu allows encryption of state and plan files at rest, whether stored locally or in a compatible backend.

It also supports encryption with terraform_remote_state.

This functionality does not replace the need for proper access policies, secret management, and backend security. Moreover, losing encryption keys could render the state unrecoverable.

However, built-in encryption directly in the tool adds a valuable layer, especially for organizations with strict security requirements.

OpenTofu vs. Terraform: Key differences in 2026

Although they share origins, the comparison already indicates two distinct philosophies.

This table should not be interpreted as meaning OpenTofu is automatically superior.

Terraform maintains a large installed base, extensive documentation, accumulated expertise, enterprise integrations, and a commercial platform developed over years by HashiCorp.

Furthermore, IBM completed its acquisition of HashiCorp in 2025, placing Terraform within a major tech group with strong enterprise presence.

OpenTofu competes from a different position: compatibility, open licensing, and independent governance from a single vendor.

Fidelity’s migration shows it’s no longer just for labs

Perhaps one of the clearest indicators of OpenTofu’s maturity comes from Fidelity Investments.

The company shared its experience in an interview published by OpenTofu.

Their infrastructure scale offers some perspective:

Fidelity explained that Terraform’s license change prompted internal discussions about alternatives and that the open governance model of OpenTofu aligned with their strategy.

But an essential condition was technical compatibility.

Migrating an organization with millions of resources would be much more complex if it required rewriting entire infrastructure. Fidelity pointed out that considering OpenTofu as a direct technical replacement made studying its adoption feasible.

This does not mean every organization should migrate, but it challenges the perception that OpenTofu is merely an experimental open-source alternative for enthusiasts.

Is OpenTofu truly compatible with Terraform?

Practically, compatibility remains high, especially for traditional configurations.

A current project can be a good candidate to try:

tofu init
tofu plan

before making any changes.

However, “drop-in replacement” should not be taken as a guarantee of perpetual compatibility.

Both projects from the fork now add features independently. The longer and more feature-rich an infrastructure becomes, the greater the divergence.

Therefore, enterprise migration requires reviewing at least:

• The Terraform version in use;
• Providers and their versions;
• Internal and external modules;
• State backend;
• CI/CD automation;
• Terraform Cloud/HCP Terraform;
• Specific features employed;
• External tools relying directly on CLI or outputs.

For projects mainly using Terraform CLI, HCL, standard providers, and common backends, evaluating OpenTofu can be straightforward.

Organizations deeply integrated with HCP Terraform and other HashiCorp products will have additional factors to consider.

So, Terraform or OpenTofu?

There is no one-size-fits-all answer.

Terraform still makes sense for organizations that are already standardized on HashiCorp, especially when using HCP Terraform and valuing an integrated enterprise platform, commercial support, and an ecosystem built over years.

OpenTofu is particularly appealing when the priority is to keep Infrastructure as Code under an open-source license, reduce dependency on a single vendor, or access its own features like State Encryption.

A common third scenario is organizations that don’t need to decide immediately.

They can maintain Terraform for existing infrastructure and start testing OpenTofu on new projects or labs. Its high compatibility allows for trial runs without committing to a broad migration upfront.

This approach is probably one of OpenTofu’s greatest achievements.

In 2023, the question was whether a community could maintain a viable fork of Terraform. By 2026, the question becomes what tool best fits each Infrastructure as Code strategy.

Terraform remains a major standard in IaC and now benefits from IBM’s enterprise backing. OpenTofu has built on that familiar experience to create a community-governed alternative under the Linux Foundation, which is beginning to develop its own capabilities.

The competition is no longer simply about one replacing the other. The existence of two projects with different governance models and evolution paths offers administrators, DevOps teams, and platform managers something that has been scarce in this field for years: a real choice.

Frequently Asked Questions

What is OpenTofu?

OpenTofu is an open-source Infrastructure as Code tool originally based on a fork of Terraform. Managed by the Linux Foundation, it uses the MPL 2.0 license and maintains high compatibility with Terraform’s configurations and ecosystem providers.

Can OpenTofu use Terraform files?

In many cases, yes. OpenTofu maintains compatibility with HCL, modules, and much of the provider ecosystem. However, testing is recommended before deploying in production, especially when specific integrations with HashiCorp products are involved.

Is Terraform still free?

Yes, for many use cases. HashiCorp explicitly permits internal use under its Business Source License. Restrictions mainly affect certain commercial products that offer hosted or integrated Terraform services competing with HashiCorp’s paid offerings.

What new features does OpenTofu 1.12 include?

Major updates include prevent_destroy as a dynamic feature, destroy = false, improvements in checksum management, provider installation, and the ability to generate output in both human-readable and JSON formats simultaneously with -json-into. Native encryption for state and plan files has been available since earlier versions.