OpenTofu and Terraform solve nearly the same day-to-day problem. For Belvedere's current stack, AWS, EKS, Kubernetes, Helm, and Git-based CI/CD, the normal workflow is effectively equivalent: write HCL, use providers and modules, plan changes, apply through controlled automation.
The meaningful differences are licensing, governance, managed-service alignment, and how each tool handles state and plan artifacts.
For Belvedere's greenfield infrastructure work, OpenTofu fit the constraints we cared about most: open-source licensing, tool-layer state and plan encryption, active community governance, and portability across commercial, regulated, and customer-controlled environments.
Terraform remains a mature tool with the larger ecosystem, deeper HCP Terraform integration, and Terraform Stacks for teams centered on HashiCorp's managed control plane. Our decision was narrower: Belvedere was starting fresh, and OpenTofu gave us the Terraform-style workflow without taking on Terraform's current licensing and vendor-alignment tradeoffs.
Why This Matters
Infrastructure-as-code is not just deployment scripting. It becomes the control plane for cloud accounts, Kubernetes clusters, network boundaries, IAM, secrets-adjacent configuration, and recovery.
That makes three risks worth treating as first-class:
Can we run the tool cleanly in customer-controlled or restricted environments?
Can we reduce exposure if state or plan artifacts are mishandled?
Can we keep the platform's future licensing posture simple as Belvedere evolves?
OpenTofu lined up well against those questions for our context.
Quick Comparison
Dimension | OpenTofu | Terraform | Clear Fracture Take |
|---|---|---|---|
License | MPL 2.0 | BSL 1.1 for current releases | OpenTofu keeps the licensing model simpler for platform evolution. |
HCL workflow | Terraform-style HCL | Native Terraform HCL | No meaningful day-to-day difference for our stack. |
State format | Compatible for common migration paths | Native | Starting greenfield avoids migration risk. |
Provider ecosystem | OpenTofu registry and existing provider support | Terraform Registry | AWS, Kubernetes, and Helm providers are available in both. |
State and plan encryption | Native tool-layer support | Backend-dependent encryption and sensitive-value handling | OpenTofu decouples artifact protection from backend choice. |
HCP Terraform | Not applicable | First-class | Important for teams centered on HashiCorp's managed platform. |
Terraform Stacks | Not a Terraform Stacks implementation | HCP Terraform feature | Useful in HCP-centric operating models. |
Governance | Linux Foundation / community-governed | HashiCorp, now part of IBM | OpenTofu gives us a more vendor-neutral foundation. |
The Core Reasons for Our Choice
1. Greenfield Work Changes the Tradeoff
The hardest part of moving infrastructure tooling is rarely the CLI. It is the accumulated estate: modules, state backends, CI jobs, naming conventions, training material, and operational habits.
Belvedere did not have that burden. We were choosing the IaC foundation for new platform infrastructure, so the decision could focus on long-term fit instead of migration cost.
2. The License Question Is Concrete
HashiCorp moved Terraform from MPL 2.0 to BSL 1.1 in August 2023. Normal internal Terraform usage is usually not the concern, it's more the competitive-offering restriction.
Belvedere is a platform product. Over time, infrastructure automation may be embedded in customer delivery, deployed into customer-controlled environments, or exposed through managed platform capabilities. If that ever overlaps with HashiCorp's commercial offerings, the licensing question becomes more complicated.
OpenTofu's MPL 2.0 model is simpler for that future. It keeps the IaC layer open, inspectable, and easier to package around without negotiating the edge cases of a source-available license.
3. Encryption Is About the Trust Boundary
OpenTofu's native state and plan encryption is a real differentiator with real operational responsibilities. It uses customer-managed keys, so teams still need key management, CI isolation, backend controls, and disciplined handling of sensitive values.
For a well-configured AWS backend, Terraform with S3 and KMS already gives encrypted-at-rest state. The marginal value of OpenTofu is different: encryption moves closer to the tool layer and becomes less dependent on the backend we happen to use.
That matters when infrastructure runs in customer-controlled, air-gapped, regulated, or otherwise constrained environments where we may not get to choose the backend pattern. It gives us another defense-in-depth layer for artifacts that often contain sensitive operational context.
4. Provider Parity Is Not the Blocker
The obvious question is whether the provider ecosystem is there. For our stack, it is.
AWS, Kubernetes, and Helm provider availability is not a blocker, and we have not seen major providers withhold basic OpenTofu compatibility for the common paths Belvedere uses. Terraform still has more examples, training content, and vendor documentation, but most operational guidance transfers directly.
5. Governance Matters for Foundational Tools
IBM completed its acquisition of HashiCorp in February 2025. That does not make Terraform fragile or unsuitable. It does make Terraform's future more tightly connected to a large enterprise vendor's commercial priorities, especially around HCP Terraform and managed workflows.
OpenTofu's Linux Foundation governance gives us a more neutral base for a tool we may need to run across customer environments, deployment models, and compliance boundaries. The project has also continued shipping independent releases since the fork, which matters for confidence that the ecosystem is not standing still.
Where Terraform Still Fits
Terraform remains a strong choice for teams with mature Terraform estates, heavy HCP Terraform usage, existing Terraform Stacks plans, or teams that value the largest possible hiring and training pool.
Many organizations will run both: Terraform where the estate already exists or HCP is the control plane, OpenTofu for new work where license neutrality, portability, and tool-layer encryption matter more.
That is a reasonable outcome. The tools overlap heavily, and the fork has made the ecosystem more competitive.
Risks and Mitigations
Risk | Impact | Mitigation |
|---|---|---|
Smaller OpenTofu ecosystem | Some examples and vendor docs still assume | Keep Terraform literacy in the team. Most patterns transfer directly. |
Feature divergence | Terraform-specific features may not exist in OpenTofu, and OpenTofu-specific features may not exist in Terraform. | Pin versions, test modules in CI, and document accepted IaC patterns. |
Registry assumptions | Some tooling may assume the Terraform Registry or Terraform CLI name. | Validate providers and modules before use; prefer providers with active OpenTofu compatibility. |
Encryption key handling | Native encryption adds key-management responsibility. | Store encryption material in managed secrets infrastructure and run production plan/apply from CI. |
How We Are Using It
For Belvedere, the implementation path is straightforward:
Build and pin an internal CI runner image that includes OpenTofu. Current OpenTofu Docker guidance documents copying the
tofubinary from a minimal image such asghcr.io/opentofu/opentofu:1-minimalin a multi-stage build, or installingtofuwith the standalone installation script.Use OpenTofu for new AWS, EKS, Kubernetes, and Helm infrastructure modules where there is no customer or environment requirement for Terraform.
Enable state and plan encryption for new workspaces.
Store encryption material in approved secret-management infrastructure, not in repositories.
Validate provider compatibility as part of module CI.
Document when Terraform is still the right fit, especially for customer requirements or HCP Terraform-centered workflows.
Wrap Up
For Belvedere, OpenTofu was the practical choice: Terraform-style IaC, a cleaner open-source license, native artifact encryption, and governance that fits customer-controlled and regulated deployment models.
Terraform is still valid infrastructure tooling. OpenTofu simply matched the risks we were trying to manage without adding meaningful friction to the stack we are building.
