Terraform vs OpenTofu in 2026: Why More Teams Are Evaluating OpenTofu for New Infrastructure Projects

OpenTofu Has Moved Beyond Being “Just a Fork.” Native State Encryption, New CLI Features, and Open Governance Are Giving Infrastructure Teams More Reasons to Consider It.

A few years ago, switching away from Terraform felt like a risky decision.

HashiCorp had changed Terraform’s license, OpenTofu had just been announced, and most teams preferred to wait before making any changes to production infrastructure.

Fast forward to today, and the conversation looks very different.

OpenTofu is no longer viewed as an experimental fork. It’s an independent open-source project under the Linux Foundation’s stewardship through the CNCF, with growing community adoption and a roadmap that’s beginning to diverge from Terraform’s open-source CLI.

That doesn’t automatically make OpenTofu the right choice for everyone.

But if you’re starting a new Infrastructure-as-Code project , or planning your long-term platform strategy, it deserves serious consideration.

Where OpenTofu Is Pulling Ahead

The biggest difference between the two projects today isn’t syntax.

Both still use HCL.

Both support the same provider ecosystem.

Most existing Terraform configurations run on OpenTofu with little or no modification.

The difference is in new capabilities.

Some features have already landed in OpenTofu that aren’t available in Terraform’s open-source CLI.

• Native State Encryption: OpenTofu includes built-in state encryption, allowing Terraform/OpenTofu state files to be encrypted before they are stored in the backend. This adds an extra layer of security for sensitive infrastructure data.
• Provider for_each: OpenTofu supports iterating over provider configurations, making multi-region and multi-account deployments much cleaner and reducing the need for repetitive provider blocks.
• **-exclude CLI Flag:** Unlike Terraform's -target, OpenTofu also provides an -exclude option, allowing teams to apply infrastructure changes while intentionally skipping specific resources during an operation.
• OCI Module Registry Support: OpenTofu supports OCI-compatible registries for storing and distributing infrastructure modules, giving organizations additional flexibility in managing reusable modules.
• Independent Feature Development: OpenTofu is actively introducing new capabilities through its own roadmap, while maintaining compatibility with the existing HCL language, providers, and most Terraform modules. This allows teams to adopt new features without significantly changing their existing workflows.

Native State Encryption Is the Biggest Security Improvement

Photo by Towfiqu barbhuiya on Unsplash

Terraform state files often contain extremely sensitive information.

Depending on your infrastructure, they may include:

• Database connection strings
• Cloud resource identifiers
• IAM metadata
• Internal network configuration
• Sensitive outputs (unless explicitly marked or avoided)

Most organizations store state remotely in services like Amazon S3, Azure Blob Storage, or Google Cloud Storage.

Those services encrypt data at rest, which protects the storage backend itself.

But once someone has permission to download the state file, its contents are still readable.

OpenTofu addresses this by introducing native client-side state encryption, meaning the state can be encrypted before it is written to the backend.

That provides an additional layer of protection, particularly in environments with strict compliance or security requirements.

For many security-conscious teams, this has become one of OpenTofu’s most compelling features.

Multi-Region Infrastructure Becomes Cleaner

Anyone managing infrastructure across multiple AWS regions knows how repetitive provider configuration can become.

Traditional configurations often require separate provider blocks for every region.

OpenTofu introduced provider iteration (for_each), allowing provider configurations to be generated dynamically.

The result is:

• less duplicated configuration
• easier scaling to additional regions
• cleaner infrastructure code
• simpler maintenance

It’s not a feature every team needs.

But for organizations operating across many regions or multiple cloud environments, it can significantly improve maintainability.

The -exclude Flag Solves a Common Operational Problem

Terraform has long provided the -target option, which lets you apply changes to a specific resource.

Sometimes, though, the opposite is what you want.

Imagine one resource is undergoing manual maintenance or investigation, while everything else should continue deploying normally.

OpenTofu introduces an **-exclude** option that allows teams to skip selected resources during an apply operation.

It’s a relatively small feature, but one that many infrastructure engineers have requested for years because it makes controlled rollouts easier.

Migration Is Usually Simpler Than Many Teams Expect

One reason organizations hesitate to evaluate OpenTofu is the assumption that migration will require weeks of work.

For many teams, that’s simply not the case.

Since OpenTofu began as a Terraform fork, it remains highly compatible with existing configurations.

In many environments, migration is as straightforward as:

• installing the OpenTofu CLI
• running tofu init
• reviewing the execution plan
• updating CI/CD pipelines to call tofu instead of terraform

Most modules, providers, and workflows continue to function without modification.

Of course, every production environment is different, so testing in a non-production environment is still essential before making any switch.

The Licensing Difference Still Matters

Technology isn’t the only reason organizations are evaluating OpenTofu.

Licensing continues to be an important consideration.

OpenTofu is licensed under the Mozilla Public License (MPL 2.0), an OSI-approved open-source license.

Terraform, on the other hand, is distributed under the Business Source License (BSL).

For many internal engineering teams, this distinction won’t affect day-to-day development.

However, organizations building commercial platforms, SaaS products, or products that embed infrastructure tooling often prefer the clarity of an OSI-approved license.

That’s one reason OpenTofu continues to gain attention from enterprises and open-source contributors alike.

Should Every Team Switch?

Not necessarily.

Terraform remains a mature, reliable, and widely adopted Infrastructure-as-Code platform.

Many organizations have large Terraform estates that continue to work perfectly well.

If your current workflows meet your needs, there may be no urgent reason to migrate.

However, if you’re:

• starting a new infrastructure project,
• building an Internal Developer Platform,
• prioritizing open-source governance,
• or looking for capabilities like native state encryption,

then OpenTofu is absolutely worth evaluating.

Final Thoughts

The conversation around Infrastructure as Code has evolved.

It’s no longer simply about Terraform versus “the fork.”

OpenTofu has established its own roadmap, governance model, and feature set.

Whether it becomes your organization’s default choice will depend on your priorities → security, licensing, governance, operational simplicity, and long-term platform strategy.

Rather than asking “Should we replace Terraform?”, a better question today is:

“If we were starting from scratch, which tool would we choose?”

For a growing number of engineering teams, OpenTofu is becoming a strong answer to that question.

Thanks For Being Here!