March 12, 2026

OpenTofu vs. Terraform: What the Fork Means for Your Cloud Cost Automation

12 min read

The IaC licensing shakeup of 2023 is still reshaping how engineering and FinOps teams automate cloud costs. Here's everything you need to know and what to do about it.

In August 2023, HashiCorp did something that sent shockwaves through the infrastructure-as-code world: it quietly changed Terraform's license from the Mozilla Public License 2.0 (MPL 2.0), a well-understood, genuinely open-source license, to the Business Source License 1.1 (BSL 1.1). No major announcement. No community vote. Just a pull request.

Within weeks, over 100 companies and 10,000 individual engineers had signed the OpenTF Manifesto, demanding that a truly open fork be created and maintained. The fork arrived. It was called OpenTofu, donated to the Linux Foundation, and it has since grown into something the community didn't fully anticipate: not just a Terraform clone, but a technically superior open-source alternative that is now pulling ahead of Terraform OSS in meaningful ways.

For most DevOps teams, the instinct was to treat this as a licensing drama to monitor from a safe distance. But if you're running cloud cost automation pipelines, using IaC to govern spend, enforce tagging, gate deployments, or map resources to budgets, this fork is a decision you can no longer defer. The tools you rely on, the platforms you build on, and the compliance posture you maintain are all touched by which side of this fork you're on.

This blog cuts through the noise and gives you a clear picture: what changed, what it means for your cost toolchain, and how to make the right call for your organization.

The Fork, Fast-Forwarded: What Actually Happened

The License Change That Started It All

BSL 1.1 is not an open-source license, and that's not a technicality. The Open Source Initiative (OSI) does not recognize it as open source. The key restriction: you cannot use BSL-licensed software to build a competing product. HashiCorp's intent was clear: they were targeting managed Terraform services like Spacelift, env0, Scalr, and Atlantis-based SaaS platforms that had built businesses on top of Terraform's open-source foundation.

The problem? "Competing product" is deliberately vague. Does an internal developer platform with cost automation features compete with HCP Terraform? Legal teams at dozens of companies had to start asking that question, and the answer wasn't always cheap to get.

Then came the accelerant: IBM acquired HashiCorp for approximately $6.4 billion, closing the deal in February 2025. IBM has a well-documented history of acquiring open-source companies and gradually commercializing their products (see: Red Hat, SoftLayer). For the Terraform community, this wasn't paranoia; it was pattern recognition. The risk of Terraform's open-source roadmap being quietly narrowed over time became a board-level concern for companies with significant IaC investments.

OpenTofu: From Protest Fork to Production Standard

The OpenTF Manifesto wasn't just noise. It was backed by companies with real engineering muscle: Gruntwork, Spacelift, env0, Harness, Scalr, and Digger among them. The fork was donated to the Linux Foundation, which requires fully open-source toolchains for all CNCF projects, ensuring neutral governance with no single commercial entity controlling the roadmap.

What followed was a release cadence that surprised even the fork's supporters:

Version

Release

Headline Features

v1.6

January 2024

Full feature parity with Terraform 1.6

v1.7

May 2024

Native state encryption, for_each on provider blocks

v1.8

August 2024

Provider-defined functions, templatestring built-in

v1.9

December 2024

Variable/local refs in provider blocks, improved test framework

v1.10

Early 2025

Enhanced provider iteration, expanded state management APIs

By mid-2024, OpenTofu wasn't catching up to Terraform; it had overtaken Terraform OSS in feature richness. The fork had become the product.

Feature Divergence: Where They Stand Today

The narrative of "OpenTofu = Terraform with a different name" expired with the v1.7 release. The two tools have genuinely diverged, and the divergence matters, especially for cost automation use cases.

Capability

OpenTofu

Terraform OSS

HCP Terraform (paid)

Native state encryption

✅ v1.7+

for_each on provider blocks

✅ v1.7+

Provider-defined functions

✅ v1.8+

Partial

Partial

Variable refs in provider blocks

✅ v1.9+

Loopable removed blocks

✅ v1.9+

Multi-component Stacks

Managed drift detection scheduling

Open provider registry

✅ (MPL 2.0)

✅ (BSL 1.1)

✅ (BSL 1.1)

The pattern here is important: OpenTofu's advantages are in the open-source tier. Terraform's remaining advantages are almost exclusively locked behind HCP Terraform, HashiCorp's paid cloud platform. For teams running self-hosted or CI/CD-driven IaC workflows, OpenTofu is the stronger technical choice today, full stop.

What This Means for Cloud Cost Automation

This is where the fork stops being a DevOps story and becomes a FinOps story, especially given that 84% of organizations cite managing cloud spend as their top challenge, per Flexera's 2025 State of the Cloud Report.

IaC Is Your Cost Control Plane

Infrastructure-as-code isn't just how you provision resources; it's how you control what gets provisioned, by whom, at what cost, and with what metadata attached. Every Terraform apply or Tofu apply is a cost event. The plan/apply lifecycle is your last line of cloud cost control, your opportunity to catch:

  • Oversized instance types before they run for 720 hours

  • Resources missing mandatory cost allocation tags

  • Unintended multi-region deployments that double your data transfer bill

  • Dev environments accidentally spun up in production account budgets

When you treat IaC as a cost control plane, your state file becomes a living cost inventory — a real-time map of every cloud resource, which team owns it, which environment it belongs to, and what it costs. This is the foundation that platforms like Amnic build cost observability on top of. The fork affects this foundation.

How the Fork Affects Your Cost Toolchain

The tools that power cloud cost automation have had to pick sides, or at a minimum, declare compatibility. Here's where the ecosystem stands:

  • Infracost: Officially supports both Terraform and OpenTofu. Cost estimates in pull requests, CI/CD delta reporting, and threshold-based blocking work identically across both. No migration work needed.

  • Atlantis: Open source, fully OpenTofu compatible out of the box. One of the original beneficiaries of OpenTofu's formation; no BSL concerns.

  • Terragrunt (Gruntwork): Went OpenTofu-first as of late 2024. Gruntwork was one of the lead signatories of the OpenTF Manifesto; their commitment to OpenTofu is structural, not tactical.

  • Spacelift/env0/Scalr: All three were founding OpenTofu backers. Full OpenTofu support, actively reducing Terraform BSL dependency in their own platforms.

  • Checkov/KICS/tfsec: Security and compliance scanning tools; all updated for OpenTofu HCL compatibility. Policy-as-code enforcement (a critical cost governance layer) works across both, and all remain part of the broader DevOps toolchain ecosystem.

  • HCP Terraform: Terraform-only. Stacks, managed drift detection, and Sentinel policy enforcement remain locked to HashiCorp's platform.

The practical implication: if your cost automation stack runs on Infracost, Atlantis, and Terragrunt, you're already running on tools that have moved to OpenTofu-first. Staying on Terraform OSS increasingly means swimming against your own toolchain's current.

The Hidden Cost of BSL Ambiguity

Here's an underappreciated FinOps angle: license ambiguity has a real dollar cost.

Engineering and legal teams at companies building internal platforms on top of Terraform have had to answer questions like:

  • Does our internal developer portal, which lets teams provision infra and see their costs, constitute a "competing product" under BSL?

  • Does our cost automation layer, which wraps Terraform with guardrails and showback dashboards, violate the license?

Getting those questions answered costs time, legal fees, and often results in conservative restrictions that slow down platform engineering work. According to a 2024 survey by the CNCF, over 35% of organizations using Terraform reported reviewing their usage for BSL compliance following the license change, a non-trivial operational distraction.

OpenTofu's MPL 2.0 license eliminates this category of risk entirely. Build whatever you want on top of it. No legal review required.

OpenTofu Features with Direct FinOps Impact

Three OpenTofu-specific features deserve a spotlight for cost automation practitioners:

1. Native State Encryption (v1.7) State files can contain resource names, tags, environment labels, and sometimes output values that include account IDs or billing metadata. In regulated industries (HIPAA, SOC 2, PCI-DSS), storing this data unencrypted in remote backends is a compliance gap. OpenTofu's AES-GCM encryption with PBKDF2 key derivation is built in, no third-party workaround required. For FinOps teams managing cost data in state, this is a compliance win that previously required significant engineering effort.

2. for_each on Provider Blocks (v1.7) This is a bigger deal for cost automation than it might appear. Multi-account AWS architectures, where each team or product has its own account for cost isolation, previously required awkward workarounds to apply consistent cost governance policies across accounts. With for_each on provider blocks, you can iterate across 50 AWS accounts with clean, DRY code. Tag enforcement, budget policies, and resource naming conventions become dramatically easier to apply at scale.

3. Variable References in Provider Blocks (v1.9) This enables dynamic, environment-aware infrastructure configuration without duplicating provider blocks. Fewer duplicated configurations mean fewer configuration drifts, and configuration drift is a leading cause of unplanned cloud spend.

A Cost-Gated CI/CD Pipeline with OpenTofu

Here's what a practical, cost-aware deployment pipeline looks like with OpenTofu at the center:

  1. Developer opens a Pull Request

        ↓

  1. Tofu plan runs automatically in CI

        ↓

  1. Infracost calculates cost delta (e.g., "+$340/month")

        ↓

  1. If delta exceeds threshold → PR blocked + cost breakdown posted as comment

        ↓

  1. OPA policy checks tag compliance (team, env, cost-center tags required)

        ↓

  1. FinOps team approves if above threshold

        ↓

  1. tofu apply on merge → state updated → Amnic ingests new resource data

This pipeline is entirely buildable with open-source tooling under MPL 2.0 or Apache 2.0 licenses. No BSL exposure. No HCP Terraform dependency.

Should You Migrate? A Practical Decision Guide

Stay on Terraform If…

  • You're actively using HCP Terraform Stacks for multi-component orchestration; there's no OpenTofu equivalent yet

  • You have an active HashiCorp enterprise support contract, evaluate at renewal, not mid-term

  • Your team has zero BSL exposure (purely internal use, no platform products, no managed service ambitions)

  • You rely on Sentinel for policy enforcement and aren't ready to migrate to OPA

Move to OpenTofu If…

  • Your cost automation stack relies on FinOps tools like Infracost, Atlantis, or Terragrunt, all OpenTofu-native

  • You need state encryption for compliance (HIPAA, SOC 2, PCI-DSS)

  • You're building an internal developer platform with cloud cost management capabilities, and BSL gray zone risk is real

  • You're starting a greenfield project with no legacy Terraform investment

  • You want multi-account cost governance patterns that for_each on provider blocks unlocks

Migration Reality Check

The good news: for most teams, this migration is nowhere near as painful as it sounds.

Migration Task

Complexity

Notes

State files

✅ Zero changes

Identical format, no conversion needed

Providers & modules

✅ Minimal

~95%+ work with zero edits

Registry URLs

✅ Simple

Update to registry.opentofu.org; auto-updates on tofu init

Binary rename

✅ Trivial

terraform → tofu in scripts and CI configs

Sentinel → OPA

⚠️ Moderate

OPA is more flexible but requires rewriting policies

HCP Terraform Stacks

❌ Blocker

No OpenTofu equivalent; must stay or redesign

Most teams report completing a non-production migration in under a day. Full production cutover typically takes 1-2 sprints, with the majority of time spent on testing, not actual migration work.

Quick Decision Matrix

Your Situation

Recommendation

Greenfield project + cost automation

OpenTofu

Infracost + Atlantis + Terragrunt stack

Migrate to OpenTofu

Need state encryption for compliance

OpenTofu

Building an internal FinOps platform

OpenTofu (BSL risk)

Active HCP Terraform Stacks user

Stay + monitor

Active HashiCorp enterprise contract

Evaluate at renewal

Bottom Line

The Terraform/OpenTofu fork was born out of a licensing dispute, but it has matured into something more significant: a genuine architectural fork in how the IaC ecosystem evolves. OpenTofu isn't a protest anymore; it's the technically stronger open-source option for teams who aren't locked into HCP Terraform's paid features.

For FinOps and platform engineering teams, the implications are concrete:

  • The tools you rely on for cost automation, Infracost, Atlantis, and Terragrunt, have moved to OpenTofu-first

  • OpenTofu's state encryption, multi-provider iteration, and dynamic provider configuration unlock cost governance patterns that Terraform OSS simply can't match

  • BSL ambiguity is a real operational and legal cost that OpenTofu's MPL 2.0 license eliminates

  • IBM's ownership of HashiCorp makes Terraform's long-term open-source trajectory genuinely uncertain

The question isn't really "OpenTofu or Terraform?" anymore. It's "when do you want to make this decision, on your own terms, or when a license change or feature wall forces your hand?"

Audit your IaC toolchain today. Test OpenTofu in a non-production environment this sprint. And make sure your cloud cost observability layer, whether that's Amnic or another platform, is reading the right state files from the right source of truth.

FAQs

Q1. Is OpenTofu production-ready, or is it still catching up to Terraform?

OpenTofu crossed the production-ready threshold with v1.6 in January 2024, achieving full feature parity with Terraform at the time. By v1.7, it had surpassed Terraform OSS with features HashiCorp hadn't shipped. As of early 2025, OpenTofu is ahead of Terraform OSS in several areas. Companies including Gruntwork, Spacelift, Cloudflare, and hundreds of others run it in production at scale.

Q2. Will my existing Terraform modules and providers work with OpenTofu?

In the vast majority of cases, yes, with zero changes. The HCL syntax, state format, and provider protocol are all compatible. The main exceptions are modules that reference HashiCorp-specific services like HCP Terraform or Sentinel policies, which require substitutes (OPA is the standard replacement for Sentinel).

Q3. How does the Terraform/OpenTofu fork affect cost visibility platforms like Amnic?

Cost observability platforms that read Terraform state or integrate with your IaC pipeline work with both. OpenTofu's state format is identical to Terraform's, so resource tagging, cost attribution, and spend mapping continue to work without modification. If anything, OpenTofu's native state encryption makes it easier to comply with data governance requirements around the cost metadata stored in state files.

Q4. What happens to Terraform long-term under IBM's ownership?

This is the central long-term risk. IBM has a documented pattern of commercializing acquired open-source projects over time. There's a credible scenario where more Terraform features, currently free, migrate behind the HCP Terraform paywall in the coming years. OpenTofu's Linux Foundation governance is explicitly designed to prevent this: no single company can unilaterally change the license or restrict access.

Q5. Is there a performance difference between OpenTofu and Terraform?

No meaningful difference for typical workloads. Both tools share the same foundational architecture, provider protocol, and execution model. Plan and apply performance is comparable. OpenTofu's newer features (like for_each on provider blocks) may actually reduce execution overhead in multi-account setups by eliminating redundant provider initializations.

Recommended Articles

Read Our Breaking Bill Edition