OpenTofu vs Terraform: what actually differs in 2026

TL;DR

The failures come from the deltas: features added after the fork, different defaults, and migration friction. An agent that assumes identical behavior will misconfigure state locking or encryption. Both default to their own registries for unqualified sources. source = "hashicorp/aws" resolves against the configured registry; be explicit when a config moves between tools. Check which binary a repo actually uses before running commands.

When to use

You are seeing this: OpenTofu has built-in state and plan encryption (PBKDF2 key provider plus AES-GCM method). Use this skill when you run into "OpenTofu vs Terraform: what actually differs in 2026".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

The deltas that matter

1. State encryption. OpenTofu has built-in state and plan encryption (PBKDF2 key provider plus AES-GCM method). Terraform has no equivalent native feature; it relies on backend-side encryption. Do not write OpenTofu encryption blocks in a Terraform config or vice versa.
2. S3 native state locking. OpenTofu supports use_lockfile = true on the S3 backend (conditional-write locking, no DynamoDB needed). Terraform's S3 backend historically uses dynamodb_table. Both tools can read each other's state, but the locking config is not portable.
3. removed blocks. Both support removing resources without destroying, but verify the exact syntax on your toolchain version before writing them.
4. Provider registry defaults. Both default to their own registries for unqualified sources. source = "hashicorp/aws" resolves against the configured registry; be explicit when a config moves between tools.
5. CLI command names differ (tofu vs terraform) but flags and workflows are intentionally compatible. CI scripts need the right binary name.

Rules for agents

1. Check which binary a repo actually uses before running commands. A repo with tofu in CI that you drive with terraform will fight over the lock file.
2. The OpenTofu migration guide covers state compatibility: state files are portable, but back up before switching tools on a live workspace.
3. Do not mix: one workspace, one tool. Alternating terraform apply and tofu apply on the same state invites lock-file and provider-resolution fights.

Why

OpenTofu is a fork of Terraform 1.5, so nearly all config works on both. The failures come from the deltas: features added after the fork, different defaults, and migration friction. An agent that assumes identical behavior will misconfigure state locking or encryption.

OpenTofu docs: built-in state/plan encryption via key providers (pbkdf2) and methods (aesgcm); S3 backend native locking via uselockfile=true using conditional writes; import blocks accept identity or id; moved-block semantics. Verified against live docs 2026-09-26.