
In August 2023, HashiCorp changed Terraform’s licence from MPL (open source) to BSL (Business Source Licence). That one decision split the IaC ecosystem in two.
OpenTofu was created as the community’s response — a true open-source fork of Terraform 1.6, now governed by the Linux Foundation. Two and a half years later, the fork has matured. OpenTofu ships features Terraform does not have. Enterprises like Boeing, Capital One, and AMD run it in production. And IBM’s $6.4 billion acquisition of HashiCorp in December 2024 has made the long-term direction of Terraform even less predictable.
This post covers the real differences — licensing, features, migration, and which one to use based on your actual situation.
The History — Why This Fork Happened
Terraform was open source from 2014 to 2023 under the Mozilla Public Licence (MPL). Anyone could use it, fork it, build tools on top of it, and offer it as a service.
In August 2023, HashiCorp switched to the Business Source Licence (BSL). The BSL still allows most internal and production use for free. But it restricts companies from offering Terraform as a competing hosted or managed service without a commercial agreement. This is aimed at companies like Spacelift, env0, and Atlantis that built SaaS products on top of Terraform.
The response from the community was immediate. A group of companies — including Gruntwork, Spacelift, Harness, env0, and Scalr — formed the OpenTofu project and submitted it to the Linux Foundation. OpenTofu 1.6 launched in January 2024 as a direct fork of the last open-source Terraform version.
In December 2024, IBM acquired HashiCorp for $6.4 billion. This added another layer of uncertainty — IBM now controls Terraform’s roadmap and commercial direction.
Licensing — The Core Difference
Terraform — Business Source Licence (BSL)
The BSL allows:
- Internal use in your organisation — free
- Running Terraform to manage your own infrastructure — free
- Using HCP Terraform (the managed platform) — paid above free tier
The BSL restricts:
- Building and selling a managed Terraform service to others
- Offering Terraform as a SaaS product that competes with HCP Terraform
For most DevOps engineers managing internal infrastructure, the BSL does not affect daily work. It becomes relevant if your organisation is a managed service provider or if your legal team flags BSL compliance risk.
Note: HCP Terraform ended its free tier in March 2026. Remote state, remote execution, and team features now require a paid plan.
OpenTofu — Mozilla Public Licence 2.0 (MPL)
MPL is the same licence Terraform used before 2023. It is OSI-approved, permissive, and has zero commercial restrictions. You can use OpenTofu for anything — internal infrastructure, SaaS products, managed services — without a commercial agreement.
OpenTofu is governed by the Linux Foundation with a steering committee from multiple companies. No single vendor controls the roadmap.
Features — Where They Differ in 2026
Both tools started from the same codebase. Two and a half years of independent development has created real differences.
State Encryption — OpenTofu Only
This is the biggest feature difference. OpenTofu 1.7 shipped native state encryption — a feature the community had requested from Terraform for years and never received.
State files contain sensitive data — resource IDs, IP addresses, database credentials. Without encryption, they are stored as plaintext.
# OpenTofu — native state encryption
terraform {
encryption {
key_provider "pbkdf2" "my_key" {
passphrase = var.encryption_passphrase
}
method "aes_gcm" "my_method" {
keys = key_provider.pbkdf2.my_key
}
state {
method = method.aes_gcm.my_method
}
}
}
Terraform has no equivalent. You can encrypt state at rest using backend-level encryption (S3 server-side encryption, Azure Storage encryption), but the state content itself is never encrypted by Terraform. OpenTofu encrypts the state file content directly.
For teams in regulated industries — finance, healthcare, government — this is often a compliance requirement.
Provider for_each — OpenTofu Only
OpenTofu added for_each support for provider blocks. This lets you define multiple instances of a provider dynamically — useful for multi-account or multi-region deployments.
# OpenTofu — provider for_each
locals {
regions = ["us-east-1", "eu-west-1", "ap-southeast-1"]
}
provider "aws" {
for_each = toset(local.regions)
alias = each.key
region = each.key
}
In Terraform, you have to define each provider instance manually — no dynamic iteration. For teams managing infrastructure across multiple regions or accounts, this is a significant quality-of-life improvement.
Provider-Defined Functions — OpenTofu 1.8
OpenTofu 1.8 added provider-defined functions. Providers can now expose reusable utility functions directly in HCL.
# OpenTofu — provider-defined function
output "account_id" {
value = provider::aws::arn_parse(aws_s3_bucket.example.arn).account_id
}
This reduces the need for complex workarounds using locals and replace() functions to parse resource attributes.
Enhanced Testing — OpenTofu
OpenTofu enhanced the test framework with better mocking in version 1.7+.
# OpenTofu — mock provider in tests
mock_provider "aws" {
mock_resource "aws_s3_bucket" {
defaults = {
arn = "arn:aws:s3:::mock-bucket"
}
}
}
run "creates_bucket_with_correct_name" {
command = plan
variables {
bucket_name = "test-bucket"
}
assert {
condition = aws_s3_bucket.example.bucket == "test-bucket"
error_message = "Bucket name mismatch"
}
}
AI-Assisted Features — Terraform Only
Terraform has invested in AI features through HCP Terraform — natural language infrastructure generation, AI-assisted plan review, and intelligent error suggestions. These are HCP Terraform features, not available in the open-source CLI.
OpenTofu has no equivalent AI features in 2026.
Feature Comparison Table
| Feature | Terraform | OpenTofu |
|---|---|---|
| Licence | BSL | MPL 2.0 (open source) |
| Governance | IBM/HashiCorp | Linux Foundation |
| HCL syntax | Same | Same |
| Provider ecosystem | 10,000+ providers | Same registry + 2,000+ mirrored |
| State encryption | No | Yes (native, OpenTofu 1.7+) |
| Provider for_each | No | Yes (OpenTofu 1.7+) |
| Provider-defined functions | No | Yes (OpenTofu 1.8+) |
| Enhanced test mocking | No | Yes (OpenTofu 1.7+) |
| AI-assisted features | Yes (HCP Terraform) | No |
| Remote state (managed) | HCP Terraform (paid) | Spacelift, env0, Scalr, Atlantis |
| Community governance | Vendor-controlled | Community/LF steering committee |
| Adoption | 33–62% IaC market | ~12%, 27% evaluating |
| Enterprise users | Broad | Boeing, Capital One, AMD |
CLI — Almost Identical
If you know Terraform, you know OpenTofu. The CLI commands are the same — just replace terraform with tofu.
# Terraform
terraform init
terraform plan
terraform apply
terraform destroy
# OpenTofu — identical workflow
tofu init
tofu plan
tofu apply
tofu destroy
The HCL configuration files, module structure, and state file format are compatible. Your existing Terraform code runs on OpenTofu without changes in almost all cases.
Migrating from Terraform to OpenTofu
Migration is technically simple. The strategic decision is harder.
Step 1 — Install OpenTofu:
# macOS
brew install opentofu
# Linux (Ubuntu/Debian)
sudo snap install opentofu --classic
# Manual install
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh
Step 2 — Run tofu instead of terraform:
tofu init
tofu plan
tofu apply
Your existing .tfstate files work as-is. OpenTofu reads Terraform state files without conversion.
Step 3 — Update CI/CD pipelines:
For GitHub Actions, replace hashicorp/setup-terraform with opentofu/setup-opentofu:
- name: Setup OpenTofu
uses: opentofu/setup-opentofu@v1
with:
tofu_version: "1.8.0"
- name: OpenTofu Init
run: tofu init
- name: OpenTofu Plan
run: tofu plan
One critical warning — migration is one-way:
Once you run tofu apply and use OpenTofu-specific features (especially state encryption), the state file may be updated with metadata that Terraform cannot read. If you enable state encryption in OpenTofu, reverting to Terraform requires manually decrypting the state file first.
Take a backup of your state file before migrating:
terraform state pull > terraform-backup.tfstate
Adoption in 2026 — The Numbers
- Terraform: 33–62% IaC market share (depending on how measured)
- OpenTofu: ~12% adoption, 27% of teams planning to evaluate or expand use
- CNCF survey 2025: OpenTofu joined as a CNCF sandbox project, adding governance credibility
Enterprise adoption is concentrated in regulated industries where open-source licence compliance and state encryption are requirements:
- Boeing — uses OpenTofu for declarative infrastructure management where 10+ year open-source binary support is a regulatory requirement
- Capital One — migrated to avoid BSL licence uncertainty on internal cloud platforms
- AMD — uses OpenTofu for large-scale operations requiring source code modification for custom hardware provisioning
The “wait and see” period is over. OpenTofu is production-ready and moving fast.
The Dual-Engine Strategy
Many mature teams do not choose one or the other. They run both.
Terraform for: Legacy environments built on HCP Terraform with Sentinel policies, RBAC, and audit logging already in place. Migrating these is expensive and risky.
OpenTofu for: New greenfield projects where open-source licensing and state encryption matter. No legacy dependency to manage.
This is not a compromise — it is the pragmatic approach for large organisations that cannot migrate everything overnight.
Remote State Management
Terraform’s free tier on HCP Terraform ended in March 2026. If you use HCP Terraform for remote state, you now need a paid plan.
OpenTofu alternatives for remote state:
- Spacelift — full TACOS platform with OpenTofu support
- env0 — managed execution with cost management and RBAC
- Scalr — multi-tenant Terraform/OpenTofu platform
- Atlantis — self-hosted, free, PR-based workflow automation
For remote state storage only (not managed execution), OpenTofu works with the same backends as Terraform:
# S3 backend — works with both Terraform and OpenTofu
terraform {
backend "s3" {
bucket = "my-tfstate-bucket"
key = "production/terraform.tfstate"
region = "us-east-1"
}
}
Which One Should You Use?
Use OpenTofu if:
- You are starting a new project with no existing Terraform investment — OpenTofu is the no-regrets default
- You are in a regulated industry requiring state encryption (finance, healthcare, government)
- Your legal team flags BSL compliance risk
- You are a managed service provider or SaaS company building on top of IaC
- You want vendor-neutral governance — no single company controls the roadmap
- You want to avoid HCP Terraform licensing costs after the free tier ended
Use Terraform if:
- You are heavily invested in HCP Terraform — Sentinel policies, remote execution, team RBAC are in production
- You need HashiCorp’s commercial support with SLAs
- Your organisation has standardised on the HashiCorp stack (Vault, Consul, Nomad) and tight integration matters
- You want AI-assisted plan review and natural language infrastructure generation
Use both (dual-engine) if:
- You have legacy Terraform environments on HCP with Sentinel that are expensive to migrate
- You want to start new projects on OpenTofu without disrupting production
The honest recommendation for 2026:
If you are starting fresh — use OpenTofu. Same syntax, same providers, state encryption, and no licensing ambiguity. The migration cost from OpenTofu to Terraform later is trivial. The migration cost from Terraform to OpenTofu after enabling HCP features is not.
If you are already on Terraform and it is working — there is no emergency. Evaluate OpenTofu when you next hit a renewal cycle, compliance requirement, or capacity expansion.
OpenTofu Resources
- Official docs: opentofu.org
- Registry: registry.opentofu.org
- GitHub: github.com/opentofu/opentofu
- Migration guide: opentofu.org/docs/intro/migration