OpenTofu 1.12 vs Terraform: The Open Source IaC Alternative Comes of Age

OpenTofu is no longer simply the Terraform fork created after HashiCorp changed its licensing model. With OpenTofu 1.12, the Linux Foundation project retains an experience that will feel very familiar to infrastructure teams using Terraform, while introducing capabilities of its own, including dynamic prevent_destroy, destroy = false, state and plan encryption, and improvements to provider management. For developers, system administrators, DevOps and Platform Engineering teams, OpenTofu has become an alternative worth evaluating in real-world environments.

OpenTofu 1.12: the key points in 30 seconds

• OpenTofu emerged in 2023 as a fork of the last Terraform codebase available under MPL 2.0 and is now hosted by the Linux Foundation.
• It maintains strong compatibility with HCL, providers, modules and Terraform workflows, keeping the learning curve relatively low.
• OpenTofu 1.12 introduces dynamic prevent_destroy and destroy = false.
• The project also provides native encryption capabilities for state and plan files.
• Fidelity Investments has documented its adoption in a platform managing more than 4 million cloud resources.

For someone who has spent years working with Terraform, the first experience with OpenTofu can almost feel uneventful. Install the tool, enter a familiar project and the workflow looks remarkably similar:

tofu init
tofu plan
tofu apply

Files still use the .tf extension, configuration is written using HashiCorp Configuration Language (HCL), and concepts such as resources, data sources, variables, outputs, providers, modules and state remain central to the workflow.

That familiarity is probably one of the main reasons OpenTofu has become a serious Terraform competitor. It does not ask administrators to learn an entirely new approach to Infrastructure as Code (IaC). Instead, it builds on a model that thousands of infrastructure teams already understand.

From Terraform to OpenTofu: why the project exists

The story began in August 2023, when HashiCorp announced that future versions of Terraform and several of its other products would move away from the Mozilla Public License 2.0 (MPL 2.0) and adopt the Business Source License (BSL) 1.1.

The change did not suddenly make Terraform a paid product for every user. Terraform could still be used free of charge in many scenarios, including internal corporate use.

The main difference involved certain commercial activities. The BSL introduced restrictions affecting organizations using HashiCorp products to develop commercial offerings that competed with HashiCorp’s own services.

Part of the community responded by creating OpenTF from the last Terraform codebase available under MPL 2.0. The project subsequently joined the Linux Foundation and was renamed OpenTofu.

There is also a common misconception worth clearing up: the licensing change was not a consequence of IBM acquiring HashiCorp. HashiCorp changed the license in August 2023; IBM announced its agreement to acquire HashiCorp in April 2024 and completed the transaction later.

Three years later, the discussion is no longer exclusively about licensing. OpenTofu has started introducing technical capabilities of its own.

What OpenTofu 1.12 brings to system administrators

One of the most practical additions in OpenTofu 1.12 is the ability to use dynamic values with prevent_destroy.

This lifecycle protection is designed to prevent an infrastructure operation from accidentally deleting a particularly sensitive resource.

A typical example could be a production database:

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

resource "example_database" "production" {
  lifecycle {
    prevent_destroy = var.protect_database
  }
}Code language: JavaScript (javascript)

This means that the same module can change its protection policy depending on the environment.

An organization could configure:

protect_database = trueCode language: JavaScript (javascript)

in production, while using:

protect_database = falseCode language: JavaScript (javascript)

in a temporary development or testing environment.

It may seem like a relatively small improvement, but it makes reusable modules easier to build because teams do not have to duplicate configurations simply to change lifecycle policies.

Another noteworthy addition is destroy = false.

It addresses a situation that frequently appears during migrations and infrastructure reorganizations: a team wants to stop managing a resource through IaC without actually deleting the underlying infrastructure.

OpenTofu 1.12 allows that intention to be expressed directly:

removed {
  from = example_server.legacy

  lifecycle {
    destroy = false
  }
}Code language: JavaScript (javascript)

The resource can therefore be removed from the state managed by OpenTofu while the actual infrastructure remains operational.

This can be useful when removing a virtual machine, volume, database or another object from an IaC project without destroying it.

It naturally requires some operational discipline. From that point onwards, OpenTofu no longer manages the resource. If it later needs to return to IaC management, teams must review the import process carefully to avoid accidentally creating a duplicate.

State Encryption: protecting one of IaC’s most sensitive files

One particularly interesting technical difference for system administrators is native state and plan encryption, which OpenTofu introduced in previous releases.

Anyone who has worked with Terraform knows that state files need to be handled carefully.

An infrastructure state file can contain:

• infrastructure identifiers;
• resource names and addresses;
• internal configuration details;
• provider metadata;
• potentially sensitive values.

That is why casually storing terraform.tfstate in a Git repository has never been a good operational practice.

Remote backends can provide access controls and encryption, but OpenTofu went a step further by adding its own State and Plan Encryption mechanism.

Its configuration supports different key-management approaches and allows data to be encrypted before it is stored.

This does not remove the need to protect credentials properly or control access to the backend. It adds another security layer, but one with an obvious operational consideration: if the keys required to decrypt the state are lost, recovering the managed infrastructure can become a serious problem.

Terraform and OpenTofu are very similar, but no longer identical

Their high level of compatibility can make choosing between the two look like little more than replacing one executable with another.

That can still be true for many straightforward projects, but every new release increases the possibility of divergence.

Area	OpenTofu	Terraform
Infrastructure as Code	Yes	Yes
HCL	Yes	Yes
.tf files	Yes	Yes
Providers	Broad compatibility	Original ecosystem
Terraform modules	Broad compatibility	Yes
CLI	tofu	terraform
License	MPL 2.0	BSL 1.1
Governance	Linux Foundation	HashiCorp / IBM
Built-in State Encryption	Yes	Protection also depends on backend/platform
Dynamic prevent_destroy	Yes, in 1.12	Independent development path
destroy = false	Yes, in 1.12	Independent development path
Native SaaS platform	No direct equivalent	HCP Terraform

Terraform still has important advantages. Its ecosystem has been used in production for years, while HashiCorp offers HCP Terraform, enterprise support and integration with other products across its platform.

OpenTofu takes a different approach: keeping the core under the open source MPL 2.0 license with independent governance under the Linux Foundation.

They are not two completely unrelated products targeting different audiences. They are two branches with a shared history that are gradually evolving in different directions.

Testing a migration from Terraform

For many administrators, the practical question is much simpler: what happens if OpenTofu is executed against infrastructure already managed with Terraform?

For compatible projects, an initial evaluation in a testing environment can start with:

tofu init
tofu plan

Running tofu apply directly against production without carefully reviewing the plan would obviously be a poor migration strategy.

Before considering a migration, teams should check at least:

• the current Terraform version;
• provider versions;
• modules in use;
• the backend storing the state;
• state locking;
• scripts invoking terraform;
• CI/CD pipelines;
• HCP Terraform integrations;
• tools processing JSON output;
• Terraform-specific functionality used by existing modules.

Creating backups of the state before any migration is also strongly recommended.

A CI/CD environment, for example, may contain dozens of direct references such as:

terraform init
terraform validate
terraform plan
terraform apply

Those references will need to be reviewed even when the underlying HCL configuration is fully compatible.

OpenTofu can also manage Proxmox, OpenStack, AWS and Kubernetes

These tools are not limited to the major hyperscalers.

Through providers, they can manage many different types of infrastructure.

A system administrator could use IaC across an environment combining:

OpenTofu
   │
   ├── Proxmox VE
   ├── OpenStack
   ├── Kubernetes
   ├── AWS
   ├── Azure
   ├── Google Cloud
   ├── Cloudflare
   └── other providers

This makes OpenTofu particularly interesting for organizations operating hybrid infrastructure.

A company could, for example, use OpenTofu to provision virtual machines in OpenStack, configure DNS resources, deploy Kubernetes infrastructure and then hand application deployment over to another automation layer.

The underlying idea remains the same one that made Terraform popular: infrastructure stops being configured exclusively through dashboards and manual commands and becomes reproducible, version-controlled code.

OpenTofu is already managing infrastructures with millions of resources

The project is also beginning to provide references that go well beyond small labs and personal environments.

OpenTofu has published the case of Fidelity Investments, whose infrastructure platform operates at considerable scale:

Element	Reported scale
Applications	More than 2,000
State files	More than 50,000
Cloud resources	More than 4 million
Daily state updates	Up to 4,000

Fidelity’s experience matters because one of the biggest questions surrounding any fork is whether it can move beyond personal projects and small deployments into large organizations.

Managing millions of resources requires compatibility, automation, provider support, performance, upgrades and long-term maintenance to work at a very different scale.

It does not prove that OpenTofu is automatically better than Terraform, but it does show that there are now enterprise deployments large enough for OpenTofu to be considered a production option rather than merely an experimental alternative.

What should developers and system administrators choose?

For a new project, the decision is now less about syntax than it was three years ago.

Organizations that need tight integration with HashiCorp’s commercial ecosystem, use HCP Terraform extensively or already have infrastructure standardized around its tooling may have little reason to migrate simply because another option exists.

Terraform remains a mature and widely deployed platform.

OpenTofu becomes more attractive when an organization wants open source IaC under MPL 2.0, Linux Foundation governance and less dependence on the commercial decisions of a single vendor.

For administrators starting from scratch, testing both is relatively straightforward precisely because they share so many concepts.

And for teams already running Terraform, perhaps the most useful experiment is not to immediately plan a migration, but to take a copy of a real project, run OpenTofu and inspect the result of tofu plan.

Three years ago, OpenTofu had to prove that it could survive as a fork. The situation is different now. It still carries much of Terraform’s DNA, but features such as State Encryption, destroy = false and dynamic prevent_destroy show that the project has started building its own interpretation of how Infrastructure as Code should evolve.

Terraform therefore has something it barely had for many years: a technically familiar competitor, compatible with a large part of its ecosystem and different enough for infrastructure teams to seriously consider which model better fits their systems.

Frequently asked questions

Is OpenTofu compatible with Terraform?

OpenTofu maintains a high degree of compatibility with HCL, modules, providers and many existing Terraform projects. However, the two projects now evolve independently, so any migration should be tested before being applied to production.

Can OpenTofu be used with Proxmox VE or OpenStack?

Yes, provided that a compatible provider exists for the resources being managed. OpenTofu is not limited to AWS, Azure or Google Cloud and can also be used with private and hybrid infrastructure.

What is the difference between terraform apply and tofu apply?

Conceptually, both perform the same operation: applying the changes required to bring infrastructure in line with its declarative configuration. However, each command belongs to a different tool, and their capabilities can diverge depending on the versions being used.

Is it worth migrating from Terraform to OpenTofu?

It depends on the environment. Organizations that value MPL 2.0 licensing, Linux Foundation governance or specific OpenTofu features have good reasons to evaluate it. Companies deeply integrated with HCP Terraform will need to assess more components before making a move.