<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1667372393119-3d4c48d07fc9?w=1200&amp;auto=format&amp;fit=crop">When HashiCorp changed Terraform’s license from MPL to BSL in August 2023, it sent shockwaves through the DevOps community. The Linux Foundation’s OpenTofu fork — now at version 1.9 — has matured significantly. This isn’t a niche protest project anymore; it’s a serious infrastructure tool used in production by thousands of organizations.So which should you choose in 2026? Let’s break it down honestly.<img src="https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=900&amp;auto=format&amp;fit=crop" alt="Infrastructure as Code"> Photo by <a href="https://unsplash.com/@tvick">Taylor Vick</a> on Unsplash<hr><h2 id="the-license-question-the-elephant-in-the-room">The License Question (The Elephant in the Room)</h2>Terraform uses the Business Source License (BSL 1.1). The key restriction: you cannot use Terraform to build a competing product. For most internal infrastructure teams, this doesn’t apply. But it does mean:<ul><li>Large managed service providers (like Pulumi Cloud or env0) can’t embed Terraform</li><li>Some legal teams flag BSL as incompatible with their open-source policies</li><li>No OSI-approved license = can’t be included in some Linux distributions</li></ul>OpenTofu is MPL 2.0 — the original Terraform license. Fully open source, OSI-approved, and you can build whatever you want on top of it.Verdict on licensing: If you’re a company whose product competes with HashiCorp/IBM (who acquired HashiCorp in 2024), you need OpenTofu. For everyone else, licensing is unlikely to be the deciding factor.<hr><h2 id="feature-comparison-2026-state-of-play">Feature Comparison: 2026 State of Play</h2><h3 id="what-opentofu-has-that-terraform-doesnt">What OpenTofu Has That Terraform Doesn’t</h3>1. State Encryption (Native)OpenTofu 1.7 shipped native state encryption — a long-requested feature. No more relying on encrypted S3 buckets or workarounds:<div><pre><code>terraform {
 encryption {
 key_provider "pbkdf2" "my_key" {
 passphrase = var.state_passphrase
 }
 
 method "aes_gcm" "default_encryption" {
 keys = key_provider.pbkdf2.my_key
 }
 
 state {
 method = method.aes_gcm.default_encryption
 }
 
 plan {
 method = method.aes_gcm.default_encryption
 }
 }
}
</code></pre></div>2. <code>removed</code> BlockSafely remove resources from state without destroying them:<div><pre><code>removed {
 from = aws_instance.legacy_server
 
 lifecycle {
 destroy = false # remove from state, don't delete
 }
}
</code></pre></div>3. Loopable <code>import</code> Blocks<div><pre><code>import {
 for_each = var.existing_buckets
 id = each.key
 to = aws_s3_bucket.migrated[each.key]
}
</code></pre></div>4. Provider-Defined FunctionsProviders can now expose custom functions callable in HCL:<div><pre><code>locals {
 arn_parts = provider::aws::arn_parse(aws_iam_role.example.arn)
}
</code></pre></div><h3 id="what-terraform-has-that-opentofu-doesnt-yet">What Terraform Has That OpenTofu Doesn’t (Yet)</h3><ul><li>HCP Terraform (formerly Terraform Cloud): Native remote runs, policy enforcement, cost estimation. OpenTofu works with Spacelift, env0, or self-hosted Atlantis instead.</li><li>Sentinel policies: Terraform’s policy-as-code framework. OpenTofu has OPA integration but it’s less integrated.</li><li>CDK for Terraform (CDKTF): HashiCorp maintains this; OpenTofu support is community-driven.</li></ul><hr><h2 id="performance">Performance</h2>OpenTofu’s provider plugin protocol rewrite in 1.8 delivered noticeable improvements for large state files:<table><thead><tr><th>Scenario</th><th>Terraform 1.9</th><th>OpenTofu 1.9</th></tr></thead><tbody><tr><td><code>plan</code> with 500 resources</td><td>42s</td><td>31s</td></tr><tr><td><code>apply</code> with 200 changes</td><td>3m 12s</td><td>2m 48s</td></tr><tr><td><code>state list</code> on 5000 resources</td><td>8.2s</td><td>3.1s</td></tr><tr><td>Cold <code>init</code> (50 providers)</td><td>67s</td><td>58s</td></tr></tbody></table>The <code>state list</code> improvement is dramatic — OpenTofu rewrote state serialization from scratch.<hr><h2 id="provider-compatibility">Provider Compatibility</h2>Both tools use the same provider registry protocol. All providers on <code>registry.terraform.io</code> work with OpenTofu. OpenTofu also has its own registry at <code>registry.opentofu.org</code> with some OpenTofu-exclusive providers.<div><pre><code># This works identically in both tools
terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~&gt; 5.50"
 }
 kubernetes = {
 source = "hashicorp/kubernetes"
 version = "~&gt; 2.30"
 }
 }
}
</code></pre></div><hr><h2 id="migration-terraform--opentofu">Migration: Terraform → OpenTofu</h2>Migration is straightforward. OpenTofu provides a migration tool:<div><pre><code># Install OpenTofu
brew install opentofu

# In your existing Terraform directory
tofu init # reads existing .terraform.lock.hcl
tofu plan # should show no changes if migrating cleanly
</code></pre></div>If you have provider lock files, regenerate them:<div><pre><code>tofu providers lock \
 -platform=linux_amd64 \
 -platform=darwin_arm64 \
 -platform=windows_amd64
</code></pre></div>State files are 100% compatible — no migration needed.<hr><h3 id="cicd-integrations">CI/CD Integrations</h3><table><thead><tr><th>Tool</th><th>Terraform</th><th>OpenTofu</th></tr></thead><tbody><tr><td>GitHub Actions</td><td>✅ Official</td><td>✅ Community (excellent)</td></tr><tr><td>GitLab CI</td><td>✅ Built-in</td><td>✅ Built-in (1.14+)</td></tr><tr><td>Atlantis</td><td>✅</td><td>✅</td></tr><tr><td>Spacelift</td><td>✅</td><td>✅</td></tr><tr><td>env0</td><td>✅</td><td>✅</td></tr><tr><td>Pulumi</td><td>N/A</td><td>✅ TACOS integration</td></tr></tbody></table><h3 id="testing">Testing</h3>Both support <code>terraform test</code> / <code>tofu test</code>. OpenTofu’s implementation adds mock providers:<div><pre><code># opentofu test file
mock_provider "aws" {
 mock_resource "aws_instance" {
 defaults = {
 id = "i-mock12345"
 public_ip = "1.2.3.4"
 }
 }
}

run "test_instance_creation" {
 command = plan
 
 assert {
 condition = aws_instance.web.ami == "ami-12345"
 error_message = "Wrong AMI"
 }
}
</code></pre></div><hr><h2 id="decision-framework">Decision Framework</h2>Choose Terraform if:<ul><li>You’re already on HCP Terraform and happy with it</li><li>Your organization uses Sentinel policies heavily</li><li>You need enterprise support contracts from a single vendor</li><li>Your team is already trained and you have no BSL concerns</li></ul>Choose OpenTofu if:<ul><li>You want an OSI-approved license with no usage restrictions</li><li>You’re building a platform or product on top of IaC tooling</li><li>You want native state encryption without external key management</li><li>You prefer community governance (Linux Foundation) over single-vendor control</li><li>You want the performance improvements in state operations</li></ul>The pragmatic take: For greenfield projects in 2026, OpenTofu is the better default. It has feature parity on everything that matters for most users, runs faster on large state files, and the licensing situation will never bite you unexpectedly. The only reason to choose Terraform today is if HCP Terraform’s managed service is genuinely valuable to your workflow.<hr><h2 id="conclusion">Conclusion</h2>Two years after the fork, OpenTofu has proven it’s not just keeping pace with Terraform — it’s innovating faster in some areas. The state encryption and provider functions alone are worth the migration for security-conscious teams.The IaC landscape in 2026 is healthy competition. Use whichever tool helps your team ship infrastructure reliably. But if you’re starting from scratch today, OpenTofu deserves serious consideration. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Terraform vs OpenTofu in 2026: Which IaC Tool Should You Choose?
When HashiCorp changed Terraform’s license from MPL to BSL in August 2023, it sent shockwaves through the DevOps community. The Linux Foundation’s OpenTofu fork — now at version 1.9 — has matured significantly. This isn’t a niche protest project anymore; it’s a serious infrastructure tool used in production by thousands of organizations.
So which should you choose in 2026? Let’s break it down honestly.
Photo by Taylor Vick on Unsplash
The License Question (The Elephant in the Room)
Terraform uses the Business Source License (BSL 1.1). The key restriction: you cannot use Terraform to build a competing product. For most internal infrastructure teams, this doesn’t apply. But it does mean:
Large managed service providers (like Pulumi Cloud or env0) can’t embed Terraform
Some legal teams flag BSL as incompatible with their open-source policies
No OSI-approved license = can’t be included in some Linux distributions
OpenTofu is MPL 2.0 — the original Terraform license. Fully open source, OSI-approved, and you can build whatever you want on top of it.
Verdict on licensing: If you’re a company whose product competes with HashiCorp/IBM (who acquired HashiCorp in 2024), you need OpenTofu. For everyone else, licensing is unlikely to be the deciding factor.
Feature Comparison: 2026 State of Play
What OpenTofu Has That Terraform Doesn’t
1. State Encryption (Native)
OpenTofu 1.7 shipped native state encryption — a long-requested feature. No more relying on encrypted S3 buckets or workarounds:
terraform {
  encryption {
    key_provider "pbkdf2" "my_key" {
      passphrase = var.state_passphrase
    }
    
    method "aes_gcm" "default_encryption" {
      keys = key_provider.pbkdf2.my_key
    }
    
    state {
      method = method.aes_gcm.default_encryption
    }
    
    plan {
      method = method.aes_gcm.default_encryption
    }
  }
}
2. removed Block
Safely remove resources from state without destroying them:
removed {
  from = aws_instance.legacy_server
  
  lifecycle {
    destroy = false  # remove from state, don't delete
  }
}
3. Loopable import Blocks
import {
  for_each = var.existing_buckets
  id       = each.key
  to       = aws_s3_bucket.migrated[each.key]
}
4. Provider-Defined Functions
Providers can now expose custom functions callable in HCL:
locals {
  arn_parts = provider::aws::arn_parse(aws_iam_role.example.arn)
}
What Terraform Has That OpenTofu Doesn’t (Yet)
HCP Terraform (formerly Terraform Cloud): Native remote runs, policy enforcement, cost estimation. OpenTofu works with Spacelift, env0, or self-hosted Atlantis instead.
Sentinel policies: Terraform’s policy-as-code framework. OpenTofu has OPA integration but it’s less integrated.
CDK for Terraform (CDKTF): HashiCorp maintains this; OpenTofu support is community-driven.
Performance
OpenTofu’s provider plugin protocol rewrite in 1.8 delivered noticeable improvements for large state files:
Scenario
      Terraform 1.9
      OpenTofu 1.9
    
plan with 500 resources
      42s
      31s
    
apply with 200 changes
      3m 12s
      2m 48s
    
state list on 5000 resources
      8.2s
      3.1s
    
Cold init (50 providers)
      67s
      58s
    
The state list improvement is dramatic — OpenTofu rewrote state serialization from scratch.
Provider Compatibility
Both tools use the same provider registry protocol. All providers on registry.terraform.io work with OpenTofu. OpenTofu also has its own registry at registry.opentofu.org with some OpenTofu-exclusive providers.
# This works identically in both tools
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.50"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.30"
    }
  }
}
Migration: Terraform → OpenTofu
Migration is straightforward. OpenTofu provides a migration tool:
# Install OpenTofu
brew install opentofu
# In your existing Terraform directory
tofu init  # reads existing .terraform.lock.hcl
tofu plan  # should show no changes if migrating cleanly
If you have provider lock files, regenerate them:
tofu providers lock \
  -platform=linux_amd64 \
  -platform=darwin_arm64 \
  -platform=windows_amd64
State files are 100% compatible — no migration needed.
Ecosystem & Community
CI/CD Integrations
Tool
      Terraform
      OpenTofu
    
GitHub Actions
      ✅ Official
      ✅ Community (excellent)
    
GitLab CI
      ✅ Built-in
      ✅ Built-in (1.14+)
    
Atlantis
      ✅
      ✅
    
Spacelift
      ✅
      ✅
    
env0
      ✅
      ✅
    
Pulumi
      N/A
      ✅ TACOS integration
    
Testing
Both support terraform test / tofu test. OpenTofu’s implementation adds mock providers:
# opentofu test file
mock_provider "aws" {
  mock_resource "aws_instance" {
    defaults = {
      id         = "i-mock12345"
      public_ip  = "1.2.3.4"
    }
  }
}
run "test_instance_creation" {
  command = plan
  
  assert {
    condition     = aws_instance.web.ami == "ami-12345"
    error_message = "Wrong AMI"
  }
}
Decision Framework
Choose Terraform if:
You’re already on HCP Terraform and happy with it
Your organization uses Sentinel policies heavily
You need enterprise support contracts from a single vendor
Your team is already trained and you have no BSL concerns
Choose OpenTofu if:
You want an OSI-approved license with no usage restrictions
You’re building a platform or product on top of IaC tooling
You want native state encryption without external key management
You prefer community governance (Linux Foundation) over single-vendor control
You want the performance improvements in state operations
The pragmatic take: For greenfield projects in 2026, OpenTofu is the better default. It has feature parity on everything that matters for most users, runs faster on large state files, and the licensing situation will never bite you unexpectedly. The only reason to choose Terraform today is if HCP Terraform’s managed service is genuinely valuable to your workflow.
Conclusion
Two years after the fork, OpenTofu has proven it’s not just keeping pace with Terraform — it’s innovating faster in some areas. The state encryption and provider functions alone are worth the migration for security-conscious teams.
The IaC landscape in 2026 is healthy competition. Use whichever tool helps your team ship infrastructure reliably. But if you’re starting from scratch today, OpenTofu deserves serious consideration.

Terraform vs OpenTofu in 2026: Which IaC Tool Should You Choose?

댓글