OpenTofu

TL;DR

• What it is: An open-source infrastructure as code tool forked from Terraform 1.5.x, maintained by the Linux Foundation under Mozilla Public License 2.0
• Who it’s for: Infrastructure engineers, DevOps teams, and platform teams managing cloud resources — particularly those blocked by Terraform’s BSL license or concerned about HashiCorp’s commercial direction
• Cost savings: Terraform itself is free to use in most cases; the real cost comparison is against Terraform Cloud (from $20/user/month) vs. open-source OpenTofu alternatives (Scalr, Spacelift, env0)
• Key strength: MPL 2.0 license with no commercial restrictions, Linux Foundation governance, and native state encryption that Terraform still lacks
• Key weakness: HashiCorp-specific enterprise features (Sentinel policies, HCP Terraform cost estimation, Vault integration) require using the HashiCorp ecosystem that OpenTofu deliberately left

---

What is OpenTofu

OpenTofu is an infrastructure as code tool that lets you describe cloud infrastructure in HCL configuration files and manage its lifecycle through a plan-and-apply workflow. You write code that says “I want an AWS EC2 instance of this type in this region” and OpenTofu figures out the API calls, dependency ordering, and state tracking to make it real — or to change or destroy it later.

The project exists because HashiCorp changed Terraform’s license from MPL 2.0 to the Business Source License (BSL) in August 2023. The BSL restricts use in products that “compete” with HashiCorp, which created legal uncertainty for commercial Terraform tooling vendors and philosophical objections from the open-source community. Gruntwork, Spacelift, Harness, env0, Scalr, and others responded by forking Terraform 1.5.0 and creating OpenTofu under Linux Foundation stewardship.

“We firmly believe that Terraform should remain open-source because it is a project many companies use, and many contributors have made Terraform what it is today,” the OpenTofu founding statement reads.

By 2026, the project had reached 28,163 GitHub stars, version 1.9.x, and genuine feature parity with Terraform — plus several capabilities Terraform still lacks.

---

Why people choose it over Terraform, Pulumi, and Ansible

vs. Terraform

For most teams, the tools are interchangeable today. State files use the same format — .tfstate files have not diverged — meaning genuine drop-in replacement is possible. The HCL syntax is identical.

The meaningful differences: OpenTofu is MPL 2.0 (true open source) while Terraform is BSL 1.1. OpenTofu 1.7 introduced native client-side state encryption using AES-GCM. OpenTofu 1.8 allows variables in backend and provider configurations. OpenTofu 1.9 lets you dynamically generate provider configurations with for_each. These are features Terraform still lacks.

One honest caveat: Terraform 1.11 introduced MCP server integration and Terraform Stacks, and HashiCorp has more resources to invest in AI-driven features. OpenTofu consistently follows Terraform’s features with a lag of several months.

vs. Pulumi

Pulumi takes a fundamentally different approach: you write infrastructure code in Python, TypeScript, Go, or Java instead of HCL. This gives you real programming language constructs — loops, conditionals, functions, and the full type system. Pulumi is a better choice if your team is stronger in general programming than in HCL. OpenTofu/Terraform have the larger ecosystem of community modules and providers.

vs. Ansible

Ansible manages configuration and orchestration, not infrastructure provisioning. The tools are often used together: OpenTofu creates the cloud infrastructure, Ansible configures the OS and application layer.

---

Features: what it actually does

Core infrastructure management

• Declarative HCL configuration — describe desired state, OpenTofu figures out how to achieve it
• Execution plans — tofu plan shows exactly what will change before anything happens
• Resource graph — OpenTofu builds a dependency graph and parallelizes independent resource creation
• State management — tracks current infrastructure state in a local or remote backend

OpenTofu-specific features

• Native state encryption at rest (v1.7) — AES-GCM with PBKDF2, AWS KMS, GCP KMS, OpenBao key providers
• Early variable evaluation (v1.8) — use variables in backend and provider configurations
• Provider for_each (v1.9) — generate multiple provider instances dynamically for multi-region deployments
• -exclude flag (v1.9) — selectively exclude resources from plan and apply operations
• Provider-defined functions (v1.8) — call functions defined within providers

Compatibility

• Drop-in Terraform replacement for versions 1.5.x and below
• Runs all existing Terraform providers without modification
• Compatible with major Terraform tooling: Terragrunt, Atlantis, Checkov
• State file format identical to Terraform — no migration required

Community and governance

• Linux Foundation project with a Technical Steering Committee
• Weekly community meetings and public RFC process
• Issue ranking system allowing community to influence development priorities
• Active Slack community via CNCF Slack

---

Pricing math

OpenTofu the tool is free. The cost comparison is about the surrounding ecosystem:

Option	Monthly cost (10-engineer team)	What you get
Terraform CLI (self-managed)	$0	Just the CLI, you manage everything
HCP Terraform Plus	$200+	Sentinel policies, cost estimation, SSO
OpenTofu + Scalr	$200-500	Hierarchical governance, team management
OpenTofu + Spacelift	$300-600	GitOps, drift detection, policy as code
OpenTofu + Atlantis	$0 + infra	Self-hosted PR automation, no cost

If you are currently using Terraform CLI with a remote backend (S3, GCS), switching to OpenTofu costs nothing — it is a binary swap. If you are using HCP Terraform or Terraform Cloud, you need an alternative: Spacelift, Scalr, env0, or self-hosted Atlantis for PR-based workflows.

---

Deployment reality

Installing OpenTofu is a single binary download. On macOS via Homebrew:

brew install opentofu

On Linux:

curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | bash

If you have an existing Terraform project, the migration is usually s/terraform/tofu/g in your scripts. Provider configurations, state files, and HCL code require no changes for Terraform-compatible code.

For teams using Terraform Cloud, migration involves pointing your backend configuration at an alternative state backend (S3, GCS, Terraform-compatible HTTP backend) and choosing a workflow automation tool. This is the meaningful migration work — plan for a day or two of effort for an established codebase.

The one area that requires care: OpenTofu’s registry is separate from HashiCorp’s. Most public providers are mirrored, but verify private or obscure providers before switching.

---

Who should use OpenTofu

Best fit

• Teams using Terraform CLI who want to ensure long-term open-source availability
• Organizations with legal or procurement departments uncomfortable with BSL licensing
• Vendors or consultancies building Terraform-based products that the BSL could restrict
• Infrastructure teams that want state encryption without building a custom wrapper
• New projects starting fresh with IaC — no reason to choose Terraform over OpenTofu today

Not the right tool if

• You are deeply integrated with HCP Terraform and need Sentinel policies or cost estimation
• Your organization has a HashiCorp enterprise support contract you need to maintain
• You are evaluating IaC from scratch and want a programming-language approach (consider Pulumi)

---

Alternatives worth considering

• Terraform — The original. Larger commercial ecosystem, HCP Terraform for team features, HashiCorp enterprise support. Choose if you are already committed to the HashiCorp stack and the BSL is not a concern.
• Pulumi — Use real programming languages (Python, TypeScript, Go) instead of HCL. Better for complex conditional logic, worse for simpler declarative infrastructure.
• Crossplane — Kubernetes-native infrastructure management. Better if your team lives in Kubernetes and wants infrastructure managed through the Kubernetes API.
• Spacelift — Platform for running OpenTofu and Terraform at scale with GitOps, drift detection, and policy as code.
• Terragrunt — A thin wrapper around OpenTofu/Terraform for managing DRY configurations and complex module hierarchies. Works with both tools.

---

Bottom line

OpenTofu has completed its transition from emergency community fork to legitimate production tool. For teams using Terraform CLI, the migration is nearly frictionless and the MPL 2.0 license removes any future licensing uncertainty. The state encryption feature alone justifies the switch for security-conscious teams. The only reason to stay on Terraform is deep integration with HashiCorp’s commercial ecosystem — if that does not apply to you, OpenTofu is the clearer choice for new projects.

Sources

This review synthesizes 5 independent third-party articles along with primary sources from the project itself. Inline references throughout the review map to the numbered list below.

1. [1] spacelift.io (2024-08-08) — “OpenTofu vs Terraform: Key Differences and Comparison” — comparison (link)
2. [2] infisical.com (2025-08-08) — “Terraform vs. OpenTofu: A Comprehensive Comparison” — comparison (link)
3. [3] dev.to (2026-03-07) — “OpenTofu vs Terraform in 2026: Is the Fork Finally Worth It?” — migration (link)
4. [4] scalr.com (2026-02-15) — “Terraform Cloud Alternatives Compared: Scalr vs Spacelift vs env0 (2026)” — deployment (link)
5. [5] bitslovers.com (2026-02-15) — “Terraform vs OpenTofu 2026: Which One Should Your Team Use?” — comparison (link)
6. [6] GitHub repository — official source code, README, releases, and issue tracker (https://github.com/opentofu/opentofu)
7. [7] Official website — OpenTofu project homepage and docs (https://opentofu.org)

References [1]–[7] above were used to cross-check claims about features, pricing, deployment, and limitations in this review.