Terraform vs Pulumi vs OpenTofu: Infrastructure as Code Comparison for 2026
The Infrastructure as Code landscape fractured in 2023 when HashiCorp changed Terraform’s license from open-source to BSL. OpenTofu emerged as the community fork, and Pulumi continues to grow as the programming-language alternative to HCL. Terraform Pulumi OpenTofu comparison is now a critical decision for every infrastructure team. Therefore, this guide compares all three tools honestly — language, state management, ecosystem, and practical trade-offs.
The Licensing Split: Why Three Tools Now
HashiCorp switched Terraform from Mozilla Public License (open-source) to Business Source License in August 2023. This means competitors cannot offer managed Terraform services. The Linux Foundation forked Terraform 1.5.x as OpenTofu under MPL. For end users — companies using Terraform to manage their own infrastructure — the BSL does not restrict you. You can keep using Terraform freely. Moreover, HashiCorp (now part of IBM) continues investing heavily in Terraform development.
The practical impact: AWS, Spacelift, env0, and Scalr now offer OpenTofu as an alternative to Terraform in their platforms. If you use Terraform Cloud/Enterprise, you are locked into HashiCorp’s offering. If you want vendor choice for your IaC platform, OpenTofu gives you that freedom. If you do not care about managed platforms and self-host your IaC, both work identically.
HCL vs Programming Languages: The Core Difference
The fundamental question is: do you want a domain-specific language (HCL) or a general-purpose programming language (TypeScript, Python, Go, Java)?
# Terraform/OpenTofu: HCL — declarative, purpose-built
resource "aws_instance" "web" {
count = var.instance_count
ami = data.aws_ami.ubuntu.id
instance_type = var.instance_type
tags = merge(var.common_tags, {
Name = "web-${count.index + 1}"
Role = "web-server"
})
user_data = templatefile("scripts/init.sh", {
db_host = aws_db_instance.main.endpoint
app_env = var.environment
})
}
resource "aws_lb_target_group_attachment" "web" {
count = var.instance_count
target_group_arn = aws_lb_target_group.web.arn
target_id = aws_instance.web[count.index].id
port = 8080
}
# Modules for reusable infrastructure
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "5.5.0"
name = "production-vpc"
cidr = "10.0.0.0/16"
azs = ["us-east-1a", "us-east-1b", "us-east-1c"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
public_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
enable_nat_gateway = true
single_nat_gateway = true
}// Pulumi: TypeScript — imperative, general-purpose
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";
const config = new pulumi.Config();
const instanceCount = config.getNumber("instanceCount") || 3;
// Use loops, conditionals, functions — real programming
const instances = Array.from({ length: instanceCount }, (_, i) => {
return new aws.ec2.Instance(`web-${i + 1}`, {
ami: ubuntu.id,
instanceType: config.get("instanceType") || "t3.medium",
tags: {
...commonTags,
Name: `web-${i + 1}`,
Role: "web-server",
},
userData: buildUserData({
dbHost: database.endpoint,
appEnv: pulumi.getStack(),
}),
});
});
// Attach all instances to target group
instances.forEach((instance, i) => {
new aws.lb.TargetGroupAttachment(`web-tg-${i}`, {
targetGroupArn: targetGroup.arn,
targetId: instance.id,
port: 8080,
});
});
// Reusable function — just a TypeScript function
function buildUserData(params: { dbHost: pulumi.Output; appEnv: string }) {
return pulumi.interpolate`#!/bin/bash
echo "DB_HOST=${params.dbHost}" >> /etc/app.env
echo "APP_ENV=${params.appEnv}" >> /etc/app.env
systemctl start myapp`;
} HCL is simpler for straightforward infrastructure. You declare what you want, and Terraform/OpenTofu figures out the order. But when you need complex logic — dynamic resource creation based on API calls, conditional configurations, or generating configurations from external data — HCL’s limitations become painful. Pulumi lets you use the full power of your programming language: loops, functions, classes, unit tests, and existing libraries.
State Management: The Operational Burden
All three tools track infrastructure state — a record of what resources exist and their current configuration. State management is where operational complexity lives.
Terraform: State stored in terraform.tfstate (JSON file). For teams, you must configure a remote backend — S3 + DynamoDB for locking is the standard AWS pattern. State locking prevents concurrent modifications. The state file contains secrets in plaintext, so the S3 bucket must be encrypted with restricted access.
OpenTofu: Identical state format and backend system as Terraform. All Terraform backends work with OpenTofu. Client-side state encryption (new in OpenTofu 1.7) encrypts the state file before storing it in the backend, addressing the plaintext secrets problem that Terraform has not solved.
Pulumi: State stored in Pulumi Cloud (free for individuals, paid for teams) or self-managed backends (S3, Azure Blob, GCS). Pulumi Cloud handles locking, encryption, and access control automatically. State is encrypted at rest and in transit. Consequently, teams spend less time managing state infrastructure but depend on Pulumi’s cloud service.
STATE MANAGEMENT COMPARISON:
Terraform OpenTofu Pulumi
Default Storage: Local file Local file Pulumi Cloud
Remote Backends: S3, GCS, Azure S3, GCS, Azure S3, GCS, Azure, Pulumi Cloud
State Locking: Backend-specific Backend-specific Built into Pulumi Cloud
State Encryption: Backend-level Client-side(!) Built-in
Secret Management: External External Built-in (encrypted in state)
Migration: Manual Manual pulumi import
Drift Detection: terraform plan tofu plan pulumi previewEcosystem and Provider Support
Terraform has the largest provider ecosystem — over 3,000 providers covering every cloud service, SaaS tool, and infrastructure component imaginable. OpenTofu uses the same providers (forked before the license change), so ecosystem parity is near-complete. Pulumi supports most major providers through Terraform bridge — a compatibility layer that wraps Terraform providers as Pulumi resources. Additionally, Pulumi has native providers for AWS, Azure, GCP, and Kubernetes that offer better TypeScript types and documentation.
The Terraform module registry (registry.terraform.io) is a significant advantage. Thousands of community modules handle common patterns — VPCs, EKS clusters, RDS instances — with battle-tested configurations. OpenTofu can use these modules directly. Pulumi has a smaller module ecosystem but lets you wrap Terraform modules as Pulumi components.
Which Should You Choose?
Keep using Terraform when: Your team already knows HCL. You use Terraform Cloud/Enterprise and are satisfied. Your infrastructure is straightforward. The BSL does not affect your use case (it probably does not).
Switch to OpenTofu when: You want open-source guarantee. You use a third-party IaC platform (Spacelift, env0). You want client-side state encryption. You are starting a new project and want to avoid vendor lock-in.
Adopt Pulumi when: Your infrastructure has complex logic that fights HCL’s limitations. Your team is stronger in TypeScript/Python/Go than HCL. You want to unit test your infrastructure code with familiar testing frameworks. You are building a platform where developers self-service infrastructure through code. You want built-in secret management without external tools.
A pragmatic approach: use OpenTofu for existing HCL codebases (it is a drop-in replacement for Terraform), and evaluate Pulumi for new projects where complex logic is needed. You do not need to choose one tool — many organizations use HCL-based tools for platform infrastructure and Pulumi for application-specific infrastructure.
Related Reading:
Resources:
In conclusion, the Terraform vs Pulumi vs OpenTofu decision comes down to language preference and licensing requirements. HCL works well for straightforward infrastructure. Programming languages excel at complex, dynamic configurations. OpenTofu is the open-source-safe choice for HCL users. All three are production-ready, well-maintained, and capable of managing infrastructure at any scale.