<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1451187580459-43490279c0fa?w=1200&amp;q=80"><h2 id="terraform-vs-opentofu-in-2026-the-fork-that-matured">Terraform vs OpenTofu in 2026: The Fork That Matured</h2>When HashiCorp relicensed Terraform from MPL-2.0 to BSL 1.1 in August 2023, it triggered the largest fork in DevOps history. OpenTofu launched under the Linux Foundation with backing from Spacelift, Gruntwork, and dozens of other companies. Nearly three years later, we can actually evaluate how this shook out.The short version: the fork succeeded. OpenTofu is a legitimate production choice in 2026, not just a protest vote. But the decision is more nuanced than “pick the open source one.”<img src="https://images.unsplash.com/photo-1607743386760-88ac62b89b8a?w=900&amp;q=80" alt="Infrastructure code on screen"> Photo by <a href="https://unsplash.com/@markusspiske">Markus Spiske</a> on Unsplash<hr><h2 id="where-things-stand-version-parity">Where Things Stand: Version Parity</h2>OpenTofu 1.8–1.9 achieved feature parity with Terraform 1.9 and has since pulled ahead in several areas. The two are syntactically compatible for the vast majority of configurations — same HCL, same provider protocol (mostly), same state format.<table><thead><tr><th>Feature</th><th>Terraform</th><th>OpenTofu</th></tr></thead><tbody><tr><td>Provider ecosystem</td><td>~4,000 providers</td><td>~4,000 providers (same registry)</td></tr><tr><td>State file format</td><td>Compatible</td><td>Compatible</td></tr><tr><td>Variable encryption</td><td>❌</td><td>✅ (1.7+)</td></tr><tr><td><code>.tofu</code> file extension</td><td>N/A</td><td>✅</td></tr><tr><td><code>provider_meta</code> for testing</td><td>Limited</td><td>Enhanced</td></tr><tr><td>Looping / iteration</td><td>Standard</td><td>Extended in 1.9</td></tr><tr><td>License</td><td>BSL 1.1</td><td>MPL 2.0</td></tr><tr><td>Commercial support</td><td>HashiCorp/IBM</td><td>Multiple vendors</td></tr></tbody></table><hr><h2 id="the-bsl-11-question">The BSL 1.1 Question</h2>BSL 1.1 is not open source. The key restriction:<blockquote>“The Software may not be used to provide a Hosted or Embedded Software Service to Third Parties.”</blockquote>What this means in practice:<ul><li>You running Terraform in your CI/CD: ✅ Fine</li><li>HashiCorp/IBM competitors offering Terraform-as-a-service: ❌ Restricted</li><li>Spacelift, Env0, Scalr offering managed Terraform execution: ❌ Technically restricted</li></ul>If you’re an enterprise with in-house infrastructure teams, the BSL likely doesn’t touch you. If you’re building a platform product that executes Terraform on behalf of customers, you need a lawyer and/or OpenTofu.<hr><h2 id="what-opentofu-added-that-terraform-didnt">What OpenTofu Added That Terraform Didn’t</h2><h3 id="state-and-plan-file-encryption-17">State and Plan File Encryption (1.7)</h3>The headline feature. Full encryption of state files and plan files using provider-agnostic key management:<div><pre><code>terraform {
 encryption {
 key_provider "pbkdf2" "my_passphrase" {
 passphrase = var.state_encryption_key
 }
 
 method "aes_gcm" "default" {
 keys = key_provider.pbkdf2.my_passphrase
 }
 
 state {
 method = method.aes_gcm.default
 enforced = true # Refuse to read unencrypted state
 }
 
 plan {
 method = method.aes_gcm.default
 }
 }
}
</code></pre></div>Supports PBKDF2 (passphrase), AWS KMS, GCP KMS, and OpenBao (open-source Vault fork). This closes a real compliance gap — Terraform state often contains secrets, and encrypting it at rest was always a workaround requiring external tools.<h3 id="looping-and-function-enhancements-1819">Looping and Function Enhancements (1.8–1.9)</h3>Provider functions can now be called in more contexts, and the iteration syntax has been extended:<div><pre><code># OpenTofu 1.9: functions in provider configuration
provider "aws" {
 region = provider::aws::arn_parse(var.resource_arn).region
}

# Enhanced for_each with complex expressions
resource "aws_iam_role_policy_attachment" "attachments" {
 for_each = {
 for combo in setproduct(var.roles, var.policies) :
 "${combo[0]}-${combo[1]}" =&gt; {
 role = combo[0]
 policy = combo[1]
 }
 }
 
 role = each.value.role
 policy_arn = each.value.policy
}
</code></pre></div><h3 id="improved-test-framework">Improved Test Framework</h3>OpenTofu’s test framework (<code>tofu test</code>) has received more investment than Terraform’s equivalent:<div><pre><code># tests/main.tftest.hcl
run "validates_bucket_naming" {
 variables {
 bucket_prefix = "test"
 environment = "staging"
 }
 
 assert {
 condition = length(aws_s3_bucket.main.id) &lt;= 63
 error_message = "Bucket name exceeds S3 64-char limit"
 }
 
 assert {
 condition = can(regex("^[a-z0-9-]+$", aws_s3_bucket.main.id))
 error_message = "Bucket name contains invalid characters"
 }
}
</code></pre></div>Mock providers for testing without real cloud credentials are more mature in OpenTofu 1.8+.<hr><h2 id="where-terraform-still-leads">Where Terraform Still Leads</h2><h3 id="terraform-cloud--hcp-terraform">Terraform Cloud / HCP Terraform</h3>HashiCorp’s managed platform is genuinely well-integrated. If you want hosted state management, policy-as-code (Sentinel), audit logs, and SSO without building anything yourself, HCP Terraform (formerly Terraform Cloud) is still the smoothest experience.OpenTofu equivalents: Spacelift, Env0, Scalr (all support OpenTofu), but they’re third-party tools that require separate vendor relationships.<h3 id="enterprise-support-and-slas">Enterprise Support and SLAs</h3>IBM/HashiCorp offers formal enterprise support contracts. OpenTofu support comes from ecosystem vendors (none of which are as large as IBM). For regulated industries requiring vendor SLAs, this matters.<h3 id="cdk-for-terraform-cdktf">CDK for Terraform (CDKTF)</h3>HashiCorp’s TypeScript/Python/Go SDK for defining Terraform configurations in code. OpenTofu compatibility is partial — CDKTF generates HCL that OpenTofu can consume, but the integration isn’t maintained directly by the OpenTofu project.<hr><h2 id="migration-terraform-to-opentofu">Migration: Terraform to OpenTofu</h2>For most configurations, migration is one command:<div><pre><code># Install OpenTofu
brew install opentofu

# In your terraform directory
tofu init # Downloads providers, reads .terraform.lock.hcl
tofu plan # Should show no changes if configuration is compatible
tofu apply # Same state file, same providers
</code></pre></div>Edge cases to watch:<ol><li>Provider version locks — OpenTofu uses the same <code>registry.terraform.io</code> provider registry, but your <code>.terraform.lock.hcl</code> references terraform-specific registry URLs. Run <code>tofu init -upgrade</code> to re-lock.</li><li>Terraform Cloud backend — Migrate to a different state backend (S3 + DynamoDB, Azure Blob, GCS) before switching</li><li>Sentinel policies — Replace with OPA or custom validation scripts</li></ol><div><pre><code># Check compatibility before migrating
tofu validate # Catches syntax issues
tofu plan -out=plan.bin
tofu show -json plan.bin | jq '.resource_changes | length' # Should be 0
</code></pre></div><hr><h2 id="real-world-usage-patterns-in-2026">Real-World Usage Patterns in 2026</h2>From observing the community and production setups:Staying on Terraform:<ul><li>Enterprises heavily invested in HCP Terraform with Sentinel policies</li><li>Teams with formal HashiCorp support contracts</li><li>Organizations where “BSL is fine for our use case” holds true</li></ul>Migrated to OpenTofu:<ul><li>Platform engineering teams building internal developer platforms</li><li>ISVs and SaaS companies affected by BSL restrictions</li><li>Open source projects and NGOs</li><li>Teams who just prefer MPL-2.0 on principle</li></ul>Using both:<ul><li>Some organizations run Terraform for existing infrastructure, OpenTofu for new modules/projects</li></ul><hr><h2 id="the-ecosystem-question">The Ecosystem Question</h2>The most common concern about OpenTofu: “Will providers work?”Answer: Yes, for everything in the Terraform Registry.OpenTofu 1.8 introduced its own registry (<code>registry.opentofu.org</code>) that mirrors Terraform’s registry. Any provider published to <code>registry.terraform.io</code> is also available at <code>registry.opentofu.org</code>. The protocol versions are compatible.<div><pre><code># Works in both Terraform and OpenTofu
terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~&gt; 5.0"
 }
 }
}
</code></pre></div>The one gap: providers that use Terraform-proprietary extensions beyond the plugin SDK. Rare, but exists.<hr><h2 id="decision-framework">Decision Framework</h2>Choose Terraform if:<ul><li>You’re using HCP Terraform/Terraform Cloud and value the integrated experience</li><li>You have an active HashiCorp enterprise support contract</li><li>Your use case is clearly within BSL allowances</li><li>You depend on CDKTF heavily</li></ul>Choose OpenTofu if:<ul><li>Your use case could be interpreted as “hosted service” under BSL</li><li>State encryption at rest is a compliance requirement</li><li>You prefer MPL-2.0 for philosophical or legal reasons</li><li>You’re building a product that runs IaC for customers</li></ul>Either works well for:<ul><li>Standard cloud infrastructure management</li><li>Teams that self-manage state backends</li><li>Module development</li><li>CI/CD integration</li></ul><hr><h2 id="conclusion">Conclusion</h2>The Terraform/OpenTofu fork story in 2026 is a success story for open source governance. The Linux Foundation fork moved quickly, maintained compatibility, and added genuine features. Neither choice is wrong.The days of “OpenTofu is just a protest” are over. It’s a production-grade tool with an active development community and multiple companies investing in its success.Evaluate based on your actual needs — licensing concerns, feature requirements, tooling investment — not tribal loyalty.<hr>What’s your team using? If you’ve migrated, what was the hardest part? Curious to hear real-world migration stories. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Terraform vs OpenTofu in 2026: The Fork That Matured
When HashiCorp relicensed Terraform from MPL-2.0 to BSL 1.1 in August 2023, it triggered the largest fork in DevOps history. OpenTofu launched under the Linux Foundation with backing from Spacelift, Gruntwork, and dozens of other companies. Nearly three years later, we can actually evaluate how this shook out.
The short version: the fork succeeded. OpenTofu is a legitimate production choice in 2026, not just a protest vote. But the decision is more nuanced than “pick the open source one.”
Photo by Markus Spiske on Unsplash
Where Things Stand: Version Parity
OpenTofu 1.8–1.9 achieved feature parity with Terraform 1.9 and has since pulled ahead in several areas. The two are syntactically compatible for the vast majority of configurations — same HCL, same provider protocol (mostly), same state format.
Feature
 Terraform
 OpenTofu
 
Provider ecosystem
 ~4,000 providers
 ~4,000 providers (same registry)
 
State file format
 Compatible
 Compatible
 
Variable encryption
 ❌
 ✅ (1.7+)
 
.tofu file extension
 N/A
 ✅
 
provider_meta for testing
 Limited
 Enhanced
 
Looping / iteration
 Standard
 Extended in 1.9
 
License
 BSL 1.1
 MPL 2.0
 
Commercial support
 HashiCorp/IBM
 Multiple vendors
 
The BSL 1.1 Question
BSL 1.1 is not open source. The key restriction:
“The Software may not be used to provide a Hosted or Embedded Software Service to Third Parties.”
What this means in practice:
You running Terraform in your CI/CD: ✅ Fine
HashiCorp/IBM competitors offering Terraform-as-a-service: ❌ Restricted
Spacelift, Env0, Scalr offering managed Terraform execution: ❌ Technically restricted
If you’re an enterprise with in-house infrastructure teams, the BSL likely doesn’t touch you. If you’re building a platform product that executes Terraform on behalf of customers, you need a lawyer and/or OpenTofu.
What OpenTofu Added That Terraform Didn’t
State and Plan File Encryption (1.7)
The headline feature. Full encryption of state files and plan files using provider-agnostic key management:
terraform {
 encryption {
 key_provider "pbkdf2" "my_passphrase" {
 passphrase = var.state_encryption_key
 }
 
 method "aes_gcm" "default" {
 keys = key_provider.pbkdf2.my_passphrase
 }
 
 state {
 method = method.aes_gcm.default
 enforced = true # Refuse to read unencrypted state
 }
 
 plan {
 method = method.aes_gcm.default
 }
 }
}
Supports PBKDF2 (passphrase), AWS KMS, GCP KMS, and OpenBao (open-source Vault fork). This closes a real compliance gap — Terraform state often contains secrets, and encrypting it at rest was always a workaround requiring external tools.
Looping and Function Enhancements (1.8–1.9)
Provider functions can now be called in more contexts, and the iteration syntax has been extended:
# OpenTofu 1.9: functions in provider configuration
provider "aws" {
 region = provider::aws::arn_parse(var.resource_arn).region
}
# Enhanced for_each with complex expressions
resource "aws_iam_role_policy_attachment" "attachments" {
 for_each = {
 for combo in setproduct(var.roles, var.policies) :
 "${combo[0]}-${combo[1]}" => {
 role = combo[0]
 policy = combo[1]
 }
 }
 
 role = each.value.role
 policy_arn = each.value.policy
}
Improved Test Framework
OpenTofu’s test framework (tofu test) has received more investment than Terraform’s equivalent:
# tests/main.tftest.hcl
run "validates_bucket_naming" {
 variables {
 bucket_prefix = "test"
 environment = "staging"
 }
 
 assert {
 condition = length(aws_s3_bucket.main.id) <= 63
 error_message = "Bucket name exceeds S3 64-char limit"
 }
 
 assert {
 condition = can(regex("^[a-z0-9-]+$", aws_s3_bucket.main.id))
 error_message = "Bucket name contains invalid characters"
 }
}
Mock providers for testing without real cloud credentials are more mature in OpenTofu 1.8+.
Where Terraform Still Leads
Terraform Cloud / HCP Terraform
HashiCorp’s managed platform is genuinely well-integrated. If you want hosted state management, policy-as-code (Sentinel), audit logs, and SSO without building anything yourself, HCP Terraform (formerly Terraform Cloud) is still the smoothest experience.
OpenTofu equivalents: Spacelift, Env0, Scalr (all support OpenTofu), but they’re third-party tools that require separate vendor relationships.
Enterprise Support and SLAs
IBM/HashiCorp offers formal enterprise support contracts. OpenTofu support comes from ecosystem vendors (none of which are as large as IBM). For regulated industries requiring vendor SLAs, this matters.
CDK for Terraform (CDKTF)
HashiCorp’s TypeScript/Python/Go SDK for defining Terraform configurations in code. OpenTofu compatibility is partial — CDKTF generates HCL that OpenTofu can consume, but the integration isn’t maintained directly by the OpenTofu project.
Migration: Terraform to OpenTofu
For most configurations, migration is one command:
# Install OpenTofu
brew install opentofu
# In your terraform directory
tofu init # Downloads providers, reads .terraform.lock.hcl
tofu plan # Should show no changes if configuration is compatible
tofu apply # Same state file, same providers
Edge cases to watch:
Provider version locks — OpenTofu uses the same registry.terraform.io provider registry, but your .terraform.lock.hcl references terraform-specific registry URLs. Run tofu init -upgrade to re-lock.
Terraform Cloud backend — Migrate to a different state backend (S3 + DynamoDB, Azure Blob, GCS) before switching
Sentinel policies — Replace with OPA or custom validation scripts
# Check compatibility before migrating
tofu validate # Catches syntax issues
tofu plan -out=plan.bin
tofu show -json plan.bin | jq '.resource_changes | length' # Should be 0
Real-World Usage Patterns in 2026
From observing the community and production setups:
Staying on Terraform:
Enterprises heavily invested in HCP Terraform with Sentinel policies
Teams with formal HashiCorp support contracts
Organizations where “BSL is fine for our use case” holds true
Migrated to OpenTofu:
Platform engineering teams building internal developer platforms
ISVs and SaaS companies affected by BSL restrictions
Open source projects and NGOs
Teams who just prefer MPL-2.0 on principle
Using both:
Some organizations run Terraform for existing infrastructure, OpenTofu for new modules/projects
The Ecosystem Question
The most common concern about OpenTofu: “Will providers work?”
Answer: Yes, for everything in the Terraform Registry.
OpenTofu 1.8 introduced its own registry (registry.opentofu.org) that mirrors Terraform’s registry. Any provider published to registry.terraform.io is also available at registry.opentofu.org. The protocol versions are compatible.
# Works in both Terraform and OpenTofu
terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0"
 }
 }
}
The one gap: providers that use Terraform-proprietary extensions beyond the plugin SDK. Rare, but exists.
Decision Framework
Choose Terraform if:
You’re using HCP Terraform/Terraform Cloud and value the integrated experience
You have an active HashiCorp enterprise support contract
Your use case is clearly within BSL allowances
You depend on CDKTF heavily
Choose OpenTofu if:
Your use case could be interpreted as “hosted service” under BSL
State encryption at rest is a compliance requirement
You prefer MPL-2.0 for philosophical or legal reasons
You’re building a product that runs IaC for customers
Either works well for:
Standard cloud infrastructure management
Teams that self-manage state backends
Module development
CI/CD integration
Conclusion
The Terraform/OpenTofu fork story in 2026 is a success story for open source governance. The Linux Foundation fork moved quickly, maintained compatibility, and added genuine features. Neither choice is wrong.
The days of “OpenTofu is just a protest” are over. It’s a production-grade tool with an active development community and multiple companies investing in its success.
Evaluate based on your actual needs — licensing concerns, feature requirements, tooling investment — not tribal loyalty.
What’s your team using? If you’ve migrated, what was the hardest part? Curious to hear real-world migration stories.

Terraform vs OpenTofu in 2026: The Fork That Matured

댓글