OpenTofu vs Terraform: Open Source IaC in 2026

TL;DR

In August 2023, HashiCorp changed Terraform's license from MPL (open source) to BSL 1.1 (Business Source License — not open source). OpenTofu was forked from Terraform under the Linux Foundation with the original MPL 2.0 license and has been independently maintained since. For most teams: use OpenTofu. It's a drop-in replacement, still uses HCL, reads Terraform configs without changes, and has added features Terraform hasn't shipped. Terraform makes sense only if you're already paying for Terraform Cloud/Enterprise.

Key Takeaways

• HashiCorp BSL change (Aug 2023): Terraform is no longer open source — BSL restricts competing commercial use
• OpenTofu: MPL 2.0 (truly open source), Linux Foundation project, ~25K GitHub stars, drop-in Terraform replacement
• Migration: terraform init → tofu init — for most projects, that's the entire migration
• OpenTofu ahead on features: state encryption, provider mocking in tests, removed license nag
• IBM acquired HashiCorp (2024) — Terraform's future is corporate-driven; OpenTofu's roadmap is community-driven
• Terraform still works: If you're on Terraform and not hitting BSL restrictions, no urgent reason to migrate

---

What Happened to Terraform?

Terraform was open source (MPL 2.0) from 2014 to 2023. Then:

1. August 10, 2023: HashiCorp announced Terraform, Vault, Consul, and other products would switch to the Business Source License (BSL) 1.1
2. BSL 1.1 is not open source: It restricts use by "competitive offerings" — anyone building a product that competes with HashiCorp's paid products needs a commercial license
3. September 2023: The OpenTofu community formed, forked the last MPL-licensed Terraform (1.5.x), and donated it to the Linux Foundation
4. January 2024: OpenTofu 1.6.0 released — the first stable GA release of the fork
5. April 2024: IBM acquired HashiCorp for $6.4B — Terraform is now an IBM product

This follows a familiar pattern: MongoDB, Elastic, Redis, and now HashiCorp have all switched away from open source to protect commercial revenue. In each case, the community forked the last open source version.

---

Comparison Overview

Feature	Terraform	OpenTofu
License	BSL 1.1 (not OSS)	MPL 2.0 (open source)
GitHub Stars	~43K	~25K
Latest Version	1.10.x	1.9.x
Configuration	HCL	HCL (identical)
Provider Registry	registry.terraform.io	registry.opentofu.org
Terraform Cloud	✅ (paid)	N/A (use Spacelift, Env0)
State encryption	❌	✅ (v1.7+)
Provider mocking (tests)	Limited	✅ (v1.7+)
Backed by	IBM / HashiCorp	Linux Foundation
Community governance	Corporate	Open governance

---

OpenTofu: The Open Source Fork

OpenTofu is governed by the Linux Foundation and maintained by a coalition of companies including Spacelift, env0, Gruntwork, and many others who rely on Terraform tooling.

Drop-In Replacement

OpenTofu is binary-compatible with Terraform configurations. For most projects, migration is one command:

# Install OpenTofu (Linux):
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh

# macOS:
brew install opentofu

# Run (same syntax as Terraform):
tofu init
tofu plan
tofu apply

Existing .tf files, modules, and state files work without changes.

Provider Registry

OpenTofu maintains its own provider registry at registry.opentofu.org. All major providers are available (AWS, GCP, Azure, Kubernetes, etc.):

# Works identically in both Terraform and OpenTofu:
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

OpenTofu's registry is compatible with Terraform's provider format — the same provider binaries work with both.

Features OpenTofu Added First

State encryption (v1.7+):

# Encrypt Terraform state at rest — OpenTofu only:
terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.state_passphrase
    }

    method "aead_gcm_hcl" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aead_gcm_hcl.my_method
    }
  }
}

This is a significant security improvement — Terraform state files contain secrets in plaintext.

Provider mocking in tests (v1.7+):

# Mock provider for testing without real credentials:
mock_provider "aws" {
  mock_resource "aws_s3_bucket" {
    defaults = {
      id = "mock-bucket-id"
      arn = "arn:aws:s3:::mock-bucket"
    }
  }
}

Previously, testing infrastructure code required real cloud credentials. OpenTofu's mocking enables pure unit testing.

---

Terraform: The Commercial Incumbent

Terraform (now from HashiCorp/IBM) remains the most widely used IaC tool. Its ~43K GitHub stars, massive module registry, and deep CI/CD integrations mean you'll find Terraform support everywhere.

When Terraform Still Makes Sense

• Terraform Cloud/Enterprise users: If you're paying for Terraform Cloud (remote state, collaboration, Sentinel policies), staying on Terraform makes sense — OpenTofu doesn't have an equivalent managed offering yet (though Spacelift and env0 fill this gap)
• Existing workflows: If everything is working and BSL doesn't affect your use case, there's no urgent reason to migrate
• Enterprise contracts: Companies with existing HashiCorp enterprise agreements should evaluate before switching

BSL Restrictions in Practice

The BSL 1.1 restriction covers building "a competitive service with the same functionality." For most users:

• Using Terraform to manage your own infrastructure: Fine under BSL, no restrictions
• Building a managed Terraform service: Requires a commercial license
• Internal tooling built on Terraform: Generally fine

The risk is more about future restrictions and the precedent — BSL is version 1.1, and future versions could change terms.

---

Migration Guide: Terraform → OpenTofu

For most projects, migration is straightforward:

Step 1: Install OpenTofu

# Linux:
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh

# macOS:
brew install opentofu

# Verify:
tofu version

Step 2: Run the Migration Script

OpenTofu provides an official migration tool:

# In your Terraform project directory:
tofu init

OpenTofu reads your existing .terraform.lock.hcl and terraform.tfstate without any conversion.

Step 3: Update Any Terraform Registry References

If your code references registry.terraform.io explicitly (unusual), update to registry.opentofu.org:

# Before (explicit registry — most code doesn't have this):
source = "registry.terraform.io/hashicorp/aws"

# After (OpenTofu default):
source = "hashicorp/aws"
# (OpenTofu resolves this from registry.opentofu.org automatically)

Step 4: Update CI/CD

Replace terraform with tofu in your workflows:

# GitHub Actions — Before:
- name: Terraform Init
  run: terraform init

# After:
- name: OpenTofu Init
  uses: opentofu/setup-opentofu@v1
  - run: tofu init
  - run: tofu plan
  - run: tofu apply -auto-approve

What Stays the Same

Everything:

• .tf file syntax (HCL — identical)
• Provider configurations
• Module sources
• State file format
• terraform.tfvars / *.auto.tfvars
• Backend configurations (S3, GCS, Azure Blob, etc.)

---

State Backend Examples (Both Work Identically)

# S3 backend — works for both Terraform and OpenTofu:
terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"

    # DynamoDB for state locking:
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

---

HCL Example: AWS Infrastructure

Identical syntax in both tools:

# main.tf
variable "environment" {
  type    = string
  default = "production"
}

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = {
    Name        = "${var.environment}-vpc"
    Environment = var.environment
    ManagedBy   = "opentofu"
  }
}

resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "${var.environment}-public-${count.index + 1}"
  }
}

output "vpc_id" {
  value = aws_vpc.main.id
}

---

Decision Guide

Use OpenTofu if:
  → New project starting from scratch
  → You care about open source licensing
  → You want state encryption (v1.7+ feature)
  → You need provider mocking for testing
  → You're self-hosting everything (no Terraform Cloud dependency)
  → Your company has FOSS policies

Stay on Terraform if:
  → You're an active Terraform Cloud/Enterprise customer
  → Your organization has existing HashiCorp support contracts
  → Your BSL compliance lawyers say it's fine for your use case
  → You're migrating to Pulumi anyway (different ecosystem entirely)

Consider Pulumi if:
  → You prefer TypeScript/Python/Go over HCL
  → You want programmatic loops, conditionals, and abstractions
  → You're building complex IaC that benefits from a real programming language

---

Alternatives to Both

Tool	Language	License	Best For
OpenTofu	HCL	MPL 2.0	Terraform compatibility, open source
Pulumi	TS/Python/Go/C#	Apache 2.0	Programmatic IaC, teams that prefer code
Ansible	YAML	GPL 3.0	Configuration management, idempotent playbooks
CDK (AWS)	TS/Python	Apache 2.0	AWS-native, generates CloudFormation
Crossplane	YAML/Go	Apache 2.0	Kubernetes-native, GitOps workflows

---

Why the License Change Matters More Than It Seems

When HashiCorp changed Terraform's license to BSL 1.1 in August 2023, the initial reaction from many practitioners was "this doesn't affect me — I'm just using it to manage my own infrastructure." That reading is technically correct for most use cases today. But it misses the longer-term picture.

License stability is a foundational property of a tool you build operational processes around. If a tool's license can change once, it can change again. The BSL itself has version numbers — what BSL 1.1 permits, BSL 2.0 or 3.0 might restrict. Companies that built deep Terraform expertise and internal tooling now face a dependency on a product whose future terms are set by a corporate owner (IBM via HashiCorp) motivated to monetize that dependency.

OpenTofu resolves this uncertainty. The Linux Foundation's governance model means no single company can change the license. The MPL 2.0 license is stable, well-understood, and permissive for the commercial use cases most teams need. For new projects starting today, there is no rational reason to choose Terraform over OpenTofu — the migration cost is near zero, the feature set is equivalent or better, and the license risk is eliminated.

The pattern here is familiar to anyone who watched the MongoDB → DocumentDB, Elastic → OpenSearch, and Redis → Valkey transitions. In each case, teams that had invested heavily in the original tool faced an unpleasant choice between accepting increasingly restrictive terms or paying migration costs they had not budgeted for. Starting with the open source fork proactively avoids that choice.

Integration with Self-Hosted Infrastructure

OpenTofu's strengths are particularly apparent when managing self-hosted infrastructure. Teams deploying tools on platforms like Coolify, CapRover, or Dokku often want to automate that infrastructure provisioning rather than managing it manually. OpenTofu's provider ecosystem covers every major VPS provider (Hetzner, DigitalOcean, Vultr, Linode) and allows you to codify your server provisioning alongside your application deployment configuration.

A typical pattern for a self-hosted stack: OpenTofu provisions the VPS instances, configures firewall rules, and sets up DNS records. A tool like Coolify then handles application deployment on those servers. This separation of concerns keeps infrastructure provisioning and application deployment cleanly separated while both being fully automated and version-controlled.

OpenTofu's state encryption feature (available since v1.7) is particularly relevant for self-hosted setups. When your state file contains database passwords, API keys, and other secrets — which it often does — encrypting state at rest before storing it in an S3-compatible backend (like MinIO or SeaweedFS) adds a meaningful security layer with minimal operational cost.

Practical Adoption: What to Expect

For teams currently on Terraform who want to migrate, the practical experience is: run the migration on a test copy of your configuration, verify the plan output looks correct, and then switch the real environment. The entire process for a typical project takes an afternoon.

The trickier migrations are projects using Terraform Cloud or Enterprise for remote state, Sentinel policies, and team collaboration features. OpenTofu does not have a direct equivalent managed service, but third-party options fill the gap. Spacelift and env0 both support OpenTofu natively and provide the same remote state, policy-as-code, and collaboration features that Terraform Cloud offers. For teams that need full IaC workflow management, evaluate these platforms before deciding that Terraform Cloud's absence from OpenTofu's ecosystem is a blocker.

Provider support is occasionally a concern for teams using niche Terraform providers. The vast majority of community providers work identically with OpenTofu, but a small number reference the Terraform registry explicitly in ways that require minor configuration changes. Check OpenTofu's provider compatibility documentation and test your specific providers in a non-production environment.

State file management and collaboration. Terraform and OpenTofu use state files to track the current state of your infrastructure. For solo developers, storing state in a local file is sufficient. For teams, state must be stored remotely so multiple engineers can run plans and applies without overwriting each other's state. OpenTofu supports all the same remote state backends as Terraform: S3-compatible storage (MinIO works here for self-hosted teams), Azure Blob Storage, Google Cloud Storage, and HTTP backends. Teams moving from Terraform Cloud to a self-hosted state backend should configure S3 with state locking as the remote backend — the migration requires only a tofu init -migrate-state command.

For self-hosted infrastructure management at scale, the startup open source stack guide covers how OpenTofu fits into a broader infrastructure automation approach for teams building on open source foundations.

Once you have OpenTofu managing your VPS infrastructure and a platform like Coolify managing application deployments, the combination gives you end-to-end infrastructure-as-code for a complete self-hosted stack. Changes to server sizes, firewall rules, and DNS records are made through OpenTofu configuration reviewed in pull requests. Application deployments and configuration changes are handled by Coolify's webhook integrations. Both are version-controlled, auditable, and reproducible — which is the core value proposition of IaC applied to self-hosted infrastructure.

Methodology

• License information: HashiCorp BSL announcement (August 2023), OpenTofu charter (Linux Foundation, September 2023)
• GitHub stars: Verified March 2026 (opentofu/opentofu ~25K, hashicorp/terraform ~43K)
• Feature comparison: OpenTofu 1.7+ release notes, Terraform changelog
• IBM acquisition: HashiCorp press release (April 2024)

---

See all open source alternatives to HashiCorp products at OSSAlt.com/alternatives/terraform.