# OpenTofu vs Terraform: what actually differs in 2026
## 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.
## 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.