Infrastructure as Code in 2026: Terraform, Pulumi, or OpenTofu?

Terraform was for years synonymous with Infrastructure as Code. Then the licence changed to BSL, OpenTofu was born from it, and Pulumi meanwhile quietly convinced developers that HCL is not the only path. In 2026, you have three mature tools — and no universal answer. Here is a practical guide to help you choose.

State of the Field in 2026¶

Infrastructure as Code is not a new concept. What is new is the market situation. After IBM’s acquisition of HashiCorp in 2024 and Terraform’s transition to Business Source License (BSL 1.1), the ecosystem split. Today we have three main players, each with a different philosophy, licence, and community.

Terraform¶

The original from HashiCorp (IBM). BSL 1.1 licence. HCL language. Largest provider ecosystem. Terraform Cloud as managed solution.

OpenTofu¶

Community fork of Terraform under CNCF. MPL 2.0 licence. Compatible with HCL. Native state encryption. Fully open source.

Pulumi¶

IaC in programming languages (TypeScript, Python, Go, C#). Full testing, IDE support, AI-powered governance. Pulumi Cloud.

Before we dive into details — important context: for most internal teams, the Terraform licence change had practically no impact. BSL 1.1 prohibits creating competing hosted services to Terraform Cloud, but internal use remains free. The problem is strategic: do you want to build on a tool where the vendor can change the rules again?

Comparison: What Matters in Practice¶

Language and Developer Experience¶

Terraform and OpenTofu use HCL (HashiCorp Configuration Language) — a declarative language designed specifically for describing infrastructure. It is readable, unambiguous, and intentionally limited. You do not have loops with side effects, you do not have exception handling, you do not have inheritance. For simple and moderately complex infrastructure, this is an advantage — fewer ways to shoot yourself in the foot.

Pulumi takes the opposite approach: you write infrastructure in TypeScript, Python, Go, C#, or Java. You have access to the full ecosystem of the language — packages, types, abstractions, unit tests, IDE with autocomplete. For developers who write application code, this is natural. For an ops team that has never touched TypeScript, it is a barrier.

`# Terraform / OpenTofu — HCL

resource “aws_s3_bucket” “data” {

bucket = “company-data-${var.environment}”

tags = {

Environment = var.environment

ManagedBy = "tofu"

}

}`

`// Pulumi — TypeScript

const bucket = new aws.s3.Bucket(“data”, {

bucket: `company-data-${stack}`,

tags: {

Environment: stack,

ManagedBy: "pulumi",

},

});

// Unit test — standard Jest

test(“bucket name contains environment”, () => {

expect(bucket.bucket).toContain(“production”);

});`

The key difference: with Pulumi you can write unit tests on infrastructure in the same framework as application code. With Terraform/OpenTofu you need external tools like Terratest (Go) or tftest. Testability is an area where Pulumi clearly leads.

State Management¶

All three tools need state — a record of what is actually deployed. Terraform stores state in a file that you can put on S3, Azure Blob, or Terraform Cloud. OpenTofu does the same but adds a killer feature: native state encryption at rest. The state file often contains sensitive data (connection strings, API keys) and with Terraform it is in plaintext. OpenTofu solves this since version 1.7 — AES-GCM encryption directly in core, without external tools.

Pulumi offers its own Pulumi Cloud as a managed state backend with versioning, audit log, and RBAC. You can also use a self-hosted backend (S3, Azure Blob, GCS). Pulumi also supports native secrets encryption in state — similar to OpenTofu but with a longer history and wider support (AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault).

Provider Ecosystem¶

Terraform has the broadest provider ecosystem — over 4,000 in the Terraform Registry. Any cloud, SaaS, or on-premises system — it is almost certain that a provider exists. OpenTofu is fully compatible with Terraform providers, so it uses the same registry and the same providers without modifications. This is OpenTofu’s biggest advantage: zero migration costs from Terraform.

Pulumi has its own native providers for the major clouds (AWS, Azure, GCP, Kubernetes) and additionally bridged providers that automatically wrap Terraform providers. In practice, this means Pulumi covers almost the same scope as Terraform, but bridged providers may have a slight lag behind upstream versions.

Comparison Table¶

	Terraform	OpenTofu	Pulumi
Licence	BSL 1.1 (source-available)	MPL 2.0 (open source)	Apache 2.0 (engine), commercial Cloud
Governance	HashiCorp / IBM	CNCF / Linux Foundation	Pulumi Corp.
Language	HCL	HCL	TypeScript, Python, Go, C#, Java, YAML
State encryption	No (requires external solution)	Yes, native (AES-GCM)	Yes, native (multi-provider KMS)
Testability	Terratest, tftest	Terratest, tftest	Native unit/integration tests
Providers	4,000+ (Terraform Registry)	Fully compatible with TF registry	Native + bridged TF providers
Managed platform	Terraform Cloud / Enterprise	Spacelift, env0, Scalr	Pulumi Cloud
Policy as Code	Sentinel (proprietary)	OPA / Rego	CrossGuard (Python/TypeScript) + AI remediation
Import existing infra	terraform import	tofu import	pulumi import + bulk import
Learning curve	Low–medium	Low–medium (same as TF)	Depends on language (low for devs, higher for ops)

Terraform in 2026: Stable, but Questions Linger¶

Terraform remains the most widely used IaC tool. Most enterprise organizations have it in production, have built modules, CI/CD pipelines, and internal knowledge bases. That is enormous inertia and a legitimate reason to stay.

When to Stay with Terraform¶

• Existing investment: You have hundreds of modules, a trained team, working pipelines. Migration has costs.
• Terraform Cloud/Enterprise: If you use the managed platform from HashiCorp and are satisfied with the price and features.
• Sentinel policies: You have written Sentinel policies and do not want to rewrite them.
• Enterprise support: You need commercial SLA and support from a vendor with IBM behind it.

Risks¶

• Licence: BSL 1.1 may limit your options if you are building a platform on top of Terraform for third parties.
• Vendor lock-in: IBM/HashiCorp controls the roadmap. The community has no influence on feature prioritization.
• Innovation pace: New features like state encryption arrive more slowly than with OpenTofu/Pulumi.

OpenTofu: Freedom Without Compromise¶

OpenTofu emerged in August 2023 as a reaction to Terraform’s licence change. Today it is under CNCF, has its own release cycle, and has started adding features that Terraform does not have. The key advantage: it is a drop-in replacement. You rename the binary, change a few configuration lines, and keep going. Your modules, providers, and state files work without changes.

What OpenTofu Adds¶

• State encryption: Native encryption of state and plan files. AES-GCM, support for AWS KMS, GCP KMS, Azure Key Vault, OpenBao.
• Native S3 state locking: Since version 1.10 — a DynamoDB table for locking is not needed, S3 conditional writes suffice.
• Registry independence: Its own registry with fallback to the Terraform Registry. No dependency on HashiCorp infrastructure.
• Community-driven roadmap: RFC process, public voting, transparent governance under CNCF.

`# OpenTofu — state encryption configuration

terraform {

encryption {

key_provider "aws_kms" "main" {

  kms_key_id = "arn:aws:kms:eu-central-1:123:key/abc-def"

  region = "eu-central-1"

}



method "aes_gcm" "default" {

  keys = key_provider.aws_kms.main

}



state {

  method = method.aes_gcm.default

}

}

}`

When to Choose OpenTofu¶

• Migrating from Terraform: You want an open source alternative without rewriting code. Migration is trivial.
• Regulated environment: State encryption is a requirement. OpenTofu has it natively, Terraform does not.
• Strategic independence: You do not want to depend on a single vendor’s roadmap.
• HCL team: Your team knows HCL and does not want to learn a new language.

Pulumi: IaC for Developers¶

Pulumi is a fundamentally different approach. Instead of a DSL, you use a real programming language. That means: conditions, loops, functions, classes, interfaces, generics — everything you know from application development. And most importantly: testability. You can write unit tests on infrastructure in the same framework as business logic.

What Pulumi Offers in 2026¶

• Pulumi Neo: AI-assisted infrastructure management — code generation, error diagnostics, automatic fixes.
• Next-Gen Policies: CrossGuard with AI-powered remediation. Policy violations are not only detected but automatically suggest a fix.
• Kubernetes Operator 2.0: GA version of the operator for GitOps workflow with Pulumi and Kubernetes.
• Pulumi Insights: AI-powered search and analytics across your entire infrastructure — “Find all S3 buckets without encryption.”
• Component Resources: Reusable abstractions — create a “CompanyVPC” component with best practices and share it across teams.

`// Pulumi — reusable component in TypeScript

export class CompanyVpc extends pulumi.ComponentResource {

public readonly vpc: aws.ec2.Vpc;

public readonly privateSubnets: aws.ec2.Subnet[];

constructor(name: string, args: CompanyVpcArgs, opts?: pulumi.ComponentResourceOptions) {

super("company:network:Vpc", name, {}, opts);



this.vpc = new aws.ec2.Vpc(\`\${name}-vpc\`, {

  cidrBlock: args.cidr,

  enableDnsHostnames: true,

  tags: { ...args.tags, ManagedBy: "pulumi" },

}, { parent: this });



// Automatically 3 private subnets in AZs

this.privateSubnets = args.azs.map((az, i) =>

  new aws.ec2.Subnet(\`\${name}-priv-\${i}\`, {

    vpcId: this.vpc.id,

    cidrBlock: \`10.0.\${i + 1}.0/24\`,

    availabilityZone: az,

  }, { parent: this })

);

}

}`

When to Choose Pulumi¶

• Developer team: Your infra team consists primarily of software engineers who want to write TypeScript/Python/Go.
• Complex logic: You need conditions, loops, and abstractions that are painful in HCL (dynamic blocks, for_each hacks).
• Testability: Unit tests on infrastructure are a must-have for you, not a nice-to-have.
• Kubernetes-heavy: Pulumi has the deepest Kubernetes integration — Helm, CRDs, operators, GitOps.
• Greenfield project: You are starting from scratch and have no existing Terraform investment.

Real-World Scenarios: What to Use When¶

Scenario 1: Enterprise with 200+ Terraform Modules¶

Recommendation: Stay with Terraform, or gradually migrate to OpenTofu. Rewriting 200 modules into Pulumi makes no business sense. OpenTofu is a painless transition — change the binary, test in staging, and go. Migration takes hours, not weeks.

Scenario 2: Startup with 5 Developers, Full-Stack TypeScript¶

Recommendation: Pulumi. The team already knows TypeScript, IDE support is familiar, write unit tests on infrastructure from day one. No need to learn HCL — one tech stack for everything. Pulumi Cloud free tier is enough to start.

Scenario 3: Bank with Compliance Requirements for State Encryption¶

Recommendation: OpenTofu or Pulumi. Terraform does not have native state encryption — you must handle encryption at the backend level (S3 server-side encryption), which may not meet audit requirements for end-to-end encryption. OpenTofu and Pulumi encrypt state natively, before sending it to the backend.

Scenario 4: Multi-Cloud Platform Team Building an Internal Developer Platform¶

Recommendation: Pulumi. When you are building abstractions over infrastructure (self-service portal, internal modules, golden paths), a programming language gives you significantly more flexibility than HCL. Component Resources in Pulumi are designed precisely for this use case — reusable, versioned, testable infrastructure blocks.

Scenario 5: DevOps Team That Does Not Want Vendor Lock-In¶

Recommendation: OpenTofu. CNCF governance, MPL 2.0 licence, community-driven roadmap. No vendor can change the rules on you. Additionally, compatibility with the Terraform ecosystem means you have access to the same providers and modules.

Migration: How to Do It in Practice¶

From Terraform to OpenTofu¶

The easiest migration in IaC history. Literally:

1. Install OpenTofu (brew install opentofu)
2. Run tofu init in an existing Terraform project
3. Run tofu plan — you should see “No changes”
4. Update CI/CD pipeline (replace terraform with tofu)
5. Optionally: enable state encryption

Note: If you use Terraform Cloud as a remote backend, you will need an alternative (Spacelift, env0, Scalr, or a self-hosted S3 backend). OpenTofu does not support the Terraform Cloud backend.

From Terraform to Pulumi¶

More complex, but Pulumi has tools that help:

• pulumi convert --from terraform — converts HCL to Pulumi code in the chosen language. The result needs manual adjustments, but it is a good start.
• pulumi import — imports existing cloud resources into Pulumi state without downtime.
• Gradual migration: Pulumi can read Terraform state via the terraform.state data source — you can migrate module by module.

What to Watch in the Coming Months¶

• OpenTofu 1.11+: Provider-defined functions and improved module testing are expected. CNCF incubation status will give the project additional credibility.
• Pulumi AI integration: Pulumi Neo and Insights are evolving rapidly. AI-powered governance (automatic detection and remediation of policy violations) could be a game changer for enterprise adoption.
• Terraform under IBM: How will IBM influence the roadmap? No dramatic changes so far, but the long-term direction is uncertain. Watch whether BSL terms remain the same.
• CDKTF deprecation: HashiCorp announced the end of CDK for Terraform. If you are using it, it is time to move — either to pure HCL or to Pulumi.

Conclusion: No Bad Choice, Just Different Trade-Offs¶

All three tools are production-ready and actively developed in 2026. The differences are not in quality — they are in philosophy, licence, and developer experience.

Terraform is the safe choice for conservative organizations with existing investment. OpenTofu is the logical successor for anyone who wants open source certainty without rewriting code. Pulumi is the future for developer teams that want infrastructure as real software — with tests, abstractions, and IDE support.

Our recommendation? Start new projects with OpenTofu or Pulumi. Migrate existing Terraform projects to OpenTofu if open source matters to you. And if your team consists of software engineers — give Pulumi a chance. You might discover that HCL was never the right fit.