Terraform vs OpenTofu: Key Differences Explained

Introduction

In August 2023, HashiCorp announced a significant change: Terraform would move from the Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1). This decision sent shockwaves through the infrastructure as code community and led to the creation of OpenTofu, a community-driven fork of Terraform maintained under the Linux Foundation.

Whether you’re starting a new project or considering a migration, understanding the differences between these two tools is essential. This article provides a detailed, objective comparison to help you make an informed decision.

The Licensing Split

Terraform (BSL 1.1)

HashiCorp’s BSL license allows free use of Terraform for most purposes but restricts use in products that compete with HashiCorp’s commercial offerings. Specifically:

• Permitted: Using Terraform to manage your own infrastructure, internal tooling, consulting services
• Restricted: Embedding Terraform in a competing commercial product (e.g., building a Terraform-as-a-Service platform)
• Conversion: After 4 years, each version converts to MPL 2.0

OpenTofu (MPL 2.0)

OpenTofu maintains the original open-source license:

• Permitted: Any use, including competitive commercial products
• Governance: Linux Foundation, community-driven
• Commitment: Pledged to remain open-source indefinitely

For most individual users and organizations using Terraform as a tool (not building products around it), the license change has no practical impact. The distinction matters primarily for companies building managed Terraform services or embedding it in their products.

Feature Comparison

Core Compatibility

OpenTofu was forked from Terraform 1.5.x, and both tools maintain a high degree of compatibility:

Features Unique to OpenTofu

OpenTofu has introduced features not available in Terraform:

1. Client-Side State Encryption

# OpenTofu-only feature
terraform {
  encryption {
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.default
    }

    state {
      method   = method.aes_gcm.default
      enforced = true
    }

    plan {
      method   = method.aes_gcm.default
      enforced = true
    }
  }
}

This encrypts state and plan files before they’re stored, adding an extra layer of security beyond backend encryption.

2. Early Variable/Local Evaluation

OpenTofu allows using variables and locals in backend and module source configurations:

# Works in OpenTofu, not in Terraform
variable "environment" {
  default = "production"
}

terraform {
  backend "s3" {
    bucket = "state-${var.environment}"
    key    = "terraform.tfstate"
  }
}

3. for_each with Unknown Values

OpenTofu handles for_each with values that aren’t known until apply time more gracefully than Terraform.

Features Unique to Terraform

Terraform also continues to innovate:

1. Stacks (Preview)

Terraform Stacks provide a higher-level abstraction for managing multiple Terraform configurations:

# Terraform Stacks configuration
component "networking" {
  source  = "./modules/networking"
  inputs = {
    region = var.region
  }
}

component "compute" {
  source  = "./modules/compute"
  inputs = {
    vpc_id = component.networking.vpc_id
  }
}

2. Terraform Cloud / HCP Terraform Integration

Terraform has deep integration with HashiCorp’s cloud platform, offering:

• Remote execution and state management
• Policy as Code with Sentinel
• Private module registry
• Cost estimation
• Drift detection

3. removed Block

Terraform 1.7+ introduced the removed block for safely removing resources from state without destroying them:

removed {
  from = aws_instance.old_server

  lifecycle {
    destroy = false
  }
}

Provider Compatibility

Both Terraform and OpenTofu use the same provider protocol and can use the same providers. The vast majority of providers work identically with both tools. OpenTofu maintains its own provider registry at registry.opentofu.org, but it mirrors most providers from the HashiCorp registry.

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

Migration Between Tools

Terraform to OpenTofu

Migration is straightforward for most projects:

# 1. Install OpenTofu
brew install opentofu

# 2. Replace terraform commands with tofu
tofu init
tofu plan
tofu apply

# 3. State files are compatible — no migration needed

Key considerations:

• State file format is compatible (as of early 2025)
• .terraform.lock.hcl files are compatible
• Most configurations work without any changes
• Some advanced features may have subtle differences

OpenTofu to Terraform

Moving back is equally simple, though you’ll lose access to OpenTofu-specific features like state encryption:

terraform init -upgrade
terraform plan

Community and Ecosystem

Terraform

• Maintainer: HashiCorp (now part of IBM)
• Community: Massive, established user base
• Learning resources: Extensive documentation, courses, certifications
• Enterprise: Terraform Cloud / HCP Terraform for teams
• Support: Commercial support available

OpenTofu

• Maintainer: Linux Foundation
• Community: Growing rapidly, strong grassroots support
• Learning resources: Growing documentation, community guides
• Enterprise: Multiple commercial offerings from ecosystem companies
• Support: Community-driven, with commercial support from participating companies

Which Should You Choose?

Choose Terraform if:

• You’re already using Terraform Cloud or HCP Terraform
• You want commercial support from HashiCorp
• You need Sentinel policies or advanced enterprise features
• You prefer the stability of an established, well-funded product
• The BSL license doesn’t affect your use case

Choose OpenTofu if:

• Open-source licensing is important to your organization
• You want client-side state encryption
• You need dynamic backend configuration with variables
• You’re building a product that might compete with HashiCorp
• You prefer community governance over corporate control

Either Works if:

• You’re using Terraform as a tool to manage your own infrastructure
• You don’t need features unique to either tool
• You’re starting a new project and want to stay flexible

Best Practices for Both

Regardless of which tool you choose:

1. Pin your tool version in CI/CD pipelines
2. Use remote state with locking
3. Write modular code that’s portable between tools
4. Avoid tool-specific features unless you have a strong reason
5. Document your choice so team members understand the rationale

Conclusion

Terraform and OpenTofu are more similar than different. Both are excellent infrastructure as code tools that share the same foundation, configuration language, and provider ecosystem. The primary differences lie in licensing philosophy, governance model, and a handful of unique features.

For most users, the choice comes down to organizational preferences around open-source licensing and commercial support. The good news is that migration between the tools is relatively painless, so you’re not locked into either decision permanently. Focus on writing clean, modular infrastructure code, and you’ll be well-served by whichever tool you choose.