Terraform made “infrastructure as code” mainstream: you describe servers, networks, DNS records, and cloud resources in configuration files, and the tool works out how to make reality match. OpenTofu is its open source fork. This guide covers why the fork happened, how the two differ, and how to move a project between them. If you are new to the idea, start with our Terraform basics guide, which applies to both.

OpenTofu just released version 1.13, with changes aimed at clearer plans.

Why there are two

Terraform was released under the Mozilla Public License 2.0, a weak-copyleft open source license. In August 2023, HashiCorp switched new versions to the Business Source License (BSL) 1.1. The BSL makes source code available but restricts using it to build a product that competes with HashiCorp’s commercial offerings. It is source-available, not open source.

In response, a coalition of companies and community members forked the last MPL-licensed version (1.5.x) as OpenTofu, which was accepted into the Linux Foundation. It remains MPL 2.0. HashiCorp itself has since been acquired by IBM.

For a person or company using Terraform to manage their own infrastructure, the BSL does not prohibit anything. The license matters most to vendors building infrastructure tooling, and to organisations with policies requiring open source licenses.

Compatibility today

The fork kept everything users touch compatible:

• HCL configuration language, so .tf files are the same
• Providers, which are separate programs; the same AWS, Azure, Google Cloud, Kubernetes, Cloudflare, and other providers serve both
• Modules, from OpenTofu’s registry, which mirrors the public module ecosystem
• State format, so OpenTofu can manage existing Terraform state

The commands map one to one:

Terraform	OpenTofu
terraform init	tofu init
terraform plan	tofu plan
terraform apply	tofu apply
terraform state list	tofu state list
.terraform.lock.hcl	Same file, same format

Since the fork, each project has added features the other does not have. Configurations using only features from Terraform 1.5 or earlier run on both. Configurations that use newer Terraform-only features need checking.

What OpenTofu has added

Client-side state encryption (1.7). State files often contain secrets: database passwords, keys, and resource attributes. OpenTofu can encrypt state and plan files with keys from a passphrase, AWS KMS, GCP KMS, or OpenBao/Vault-compatible services, so a leaked bucket of state files is not a leaked set of secrets. This is the feature most often cited as a reason to switch.

Early variable evaluation (1.8). Variables and locals can be used in places Terraform requires literals, such as backend configuration and module sources, which removes a lot of wrapper scripting.

for_each on provider configurations (1.9), useful for deploying the same resources to many regions or accounts.

Clearer plans (1.13). New convert and assume… functions reduce how many values appear as (known after apply), plus experimental built-in linting.

What Terraform has

Terraform continues to add its own features, and HCP Terraform (formerly Terraform Cloud) provides hosted runs, state, policy enforcement, and team workflows, with commercial support behind it. Some newer language features exist only in Terraform. If your team relies on HCP Terraform or a specific post-fork Terraform feature, staying put is reasonable.

Migrating a project to OpenTofu

1. Back up the state. For local state, copy terraform.tfstate. For remote state, download a copy:

terraform state pull > state-backup.json

2. Install OpenTofu. It is packaged for most distributions, or use the official install script or packages from opentofu.org:

tofu version

3. Initialise. In the project directory:

tofu init

This downloads providers from the OpenTofu registry and uses your existing backend configuration and state.

4. Plan and check for no changes.

tofu plan

A clean migration shows no changes. If the plan wants to modify or replace resources, stop and investigate before applying; it usually means a provider version difference.

5. Apply only when the plan is clean, and update CI to call tofu instead of terraform.

Switching back is possible as long as you have not used OpenTofu-only features. Once state encryption is enabled, Terraform cannot read the state.

Which should you choose?

Situation	Suggestion
Personal projects and homelabs	Either. OpenTofu if you prefer open source licensing
Organisation requiring OSI-approved licenses	OpenTofu
Secrets in state are a concern	OpenTofu, for state encryption
Standardised on HCP Terraform	Terraform
Need a post-fork Terraform-only feature	Terraform

Whichever you pick, the skills transfer completely. For configuring the machines once they exist, Ansible is the usual companion, and cloud-init handles first boot.

Frequently Asked Questions

Why does OpenTofu exist?

In August 2023 HashiCorp changed Terraform’s license from the open source Mozilla Public License to the Business Source License, which restricts competing commercial use. A group of companies and community members forked the last MPL version as OpenTofu, which is now developed under the Linux Foundation and remains MPL 2.0 licensed.

Can OpenTofu use my existing Terraform code?

In most cases yes. OpenTofu was forked from Terraform 1.5 and kept the HCL language, providers, modules, and state format compatible. Configurations written for Terraform 1.5 and many written for later versions run unchanged, though features added to Terraform after the fork are not guaranteed to exist in OpenTofu.

Does OpenTofu work with the same providers?

Yes. OpenTofu uses its own registry, which mirrors the providers and modules from the Terraform ecosystem, so the AWS, Azure, Google, Kubernetes, and other common providers work. Providers are separate programs, so the same provider binaries serve both tools.

What does OpenTofu have that Terraform does not?

The best-known addition is client-side state encryption, which encrypts state and plan files with keys you control. OpenTofu has also added early variable evaluation in backend and module blocks, for_each on provider configurations, and in 1.13 functions that reduce unknown values during planning.

Is it safe to switch an existing project to OpenTofu?

Usually, after a backup. Copy the state file, run tofu init to download providers from the OpenTofu registry, then run tofu plan and confirm it shows no changes before applying anything. Switching back is possible as long as you have not used OpenTofu-only features such as state encryption.

Should I use Terraform or OpenTofu for a new project?

For personal and most internal use, both work. OpenTofu suits anyone who wants an open source license and community governance, or its extra features. Terraform suits teams standardised on HCP Terraform and HashiCorp support, or that need features added to Terraform after the fork.