Terraform vs OpenTofu

For a new project, I would not start by asking whether the team should type terraform plan or tofu plan.

Both tools follow the same basic workflow. You write configuration, create a plan, review it, and apply it.

The bigger question is where those runs happen, where state is stored, who can make changes, and how the team recovers when something goes wrong.

Terraform and OpenTofu share a familiar workflow:

That makes it easy to move between them in many projects. It does not mean the surrounding tools and services work exactly the same way.

Before choosing one, answer a few practical questions:

For most teams, I would make the decision in this order.

If your organization already uses HCP Terraform successfully and wants managed runs and centralized controls, Terraform may be the easier choice.

If you want to run the workflow yourself, OpenTofu may be a better fit.

Terraform and OpenTofu do not create cloud resources directly. Providers do that work.

The tool reads your configuration, compares it with the current state of your infrastructure, creates a plan, and asks providers to make the required changes.

A provider connects the tool to a service such as AWS, Azure, Google Cloud, Kubernetes, GitHub, or another API. Provider versions and provider behavior are separate from the main Terraform or OpenTofu program. Terraform provider documentation OpenTofu provider documentation

The basic flow looks like this:

Your configuration describes the result you want.

Variables let you reuse the same configuration across environments, regions, accounts, or customers.

Modules package common patterns. A module might create a standard network, database, Kubernetes setup, or application service.

Providers turn those resource definitions into API requests. If you declare an AWS security group, the AWS provider makes the AWS API calls. If you declare a GitHub team, the GitHub provider calls GitHub.

State keeps track of the relationship between your configuration and the real resources it created. For example, it helps the tool know that aws_vpc.main refers to a particular VPC in a particular account.

State is important and should be treated carefully.

If it is lost, the next plan may think existing infrastructure needs to be created again. If it is exposed, it may contain sensitive values. If two runs update it at the same time, recovery can become difficult.

For that reason, store state in a shared remote location with access controls, backups, and locking where available. Do not treat it as a file that can be edited casually by hand. Terraform state documentation OpenTofu state documentation

The normal commands are:

Terraform documents these commands separately because each has different responsibilities and failure modes. Terraform CLI commands Terraform plan documentation Terraform apply documentation

OpenTofu follows the same general workflow. OpenTofu provisioning workflow OpenTofu plan documentation OpenTofu apply documentation

Most Terraform configurations, modules, providers, and workflows work with OpenTofu, especially when they use features shared by both tools.

That makes OpenTofu easy to test. A team can often try it without rewriting its entire configuration.

Still, the tools are not permanently interchangeable. Differences can appear in:

OpenTofu documents its compatibility goals, but providers and modules are maintained separately. A provider that works with both tools today still needs to be tested after an upgrade. OpenTofu v1.x compatibility promises

Terraform’s biggest difference is usually the surrounding HashiCorp platform, not the local terraform plan command.

With HCP Terraform, a team can get remote runs, shared state, version control integration, access controls, and approval workflows from one service. That can reduce the amount of CI and state management the team needs to build itself. HCP Terraform remote operations documentation

That does not make HCP Terraform the right answer for everyone. You still need to check whether it can reach private systems, how credentials are provided, how emergency changes work, and whether its workflow fits your team.

OpenTofu is a separate project with its own roadmap. It is a natural choice for teams that want to run the tool, state storage, and CI themselves. OpenTofu 1.10.0 release notes

If portability matters, stay with features shared by both tools unless an OpenTofu-specific feature solves a clear problem. Tool-specific features can be useful, but they may make a later move more complicated.

Choose Terraform when:

Choose OpenTofu when:

For a new project, I would choose OpenTofu.

The main reason is not that the commands are better. They are mostly the same. My concern is the direction and ownership of Terraform now that HashiCorp, the company behind it, is part of IBM. I would rather start a new project with the independent OpenTofu project than build around a tool whose future is tied to a large enterprise software company.

That may not matter to every team. If your organization already depends on HCP Terraform, the switch may not be worth it. But when starting from scratch, I prefer keeping the core tool separate from a vendor platform and choosing OpenTofu as the default.

Before standardizing, run a small pilot that resembles the real project. Use:

Then check:

If you may switch tools later, stay within the shared feature set where possible. Pin versions, back up state, and test both tools in a disposable environment before changing production.

OpenTofu documents a migration path from Terraform, while noting that OpenTofu-specific features may make it harder for Terraform to read the same state later. OpenTofu migration guide OpenTofu guidance for multiple configurations

The best tool is not the one with the strongest branding argument.

It is the one your team can run, secure, recover, and upgrade without unnecessary surprises. For a new project, my choice would be OpenTofu because it offers the familiar Terraform workflow without making IBM’s ownership of HashiCorp part of the foundation of the project.

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.
Y’all are the best.