If you told me two years ago that IBM would own Terraform and a fork would be running Fidelity’s entire cloud infrastructure, I’d have politely asked what you were smoking. Yet here we are.

The Infrastructure as Code landscape has been put through a seismic shift since HashiCorp’s licence change in August 2023. What was once a simple question of “just use Terraform” is now rather contentious. An honest look at where things stand has been well overdue on my part.

The Elephant in the Room: HashiCorp’s Licence Change

Let’s rewind for a moment. In August 2023, HashiCorp switched Terraform from the Mozilla Public License (MPL) v2.0 to the Business Source License (BUSL) v1.1. The community response was… not great.

The key change? You can still use Terraform internally for whatever you want, free of charge. But if you’re offering Terraform as part of a customer facing service that competes with Terraform Cloud or Enterprise, you now need a commercial agreement with HashiCorp.

Sounds reasonable right? But in practice, sent shockwaves through the ecosystem. Companies that had built products and services around Terraform were suddenly in a grey area. The trust was broken.

IBM Enters the Chat

In February 2025, IBM completed its $6.4 billion acquisition of HashiCorp. The deal had been announced back in April 2024 and took nearly a year to clear regulatory hurdles from both the FTC and the UK’s CMA.

Regulators examined whether there was anti-competitive overlap between Terraform and Red Hat’s Ansible. The conclusion? They’re complementary, not competing. Fair call - Ansible handles config management, while Terraform handles infrastructure provisioning. Different tools, different jobs.

IBM has since been integrating HashiCorp’s products (Terraform, Vault, Consul) into the Red Hat ecosystem, with support infrastructure migration to IBM’s portal scheduled for completion in March 2026.

There’s been speculation about whether IBM might reverse the BSL decision given Red Hat’s open source heritage but as of writing this, no such announcement has been made. I wouldn’t hold my breath on that personally.

The Contenders

Terraform — The Incumbent

Current Version: v1.14.6 (February 2026)

Love it or hate it, Terraform is still the most widely deployed IaC tool on the planet. And with IBM’s resources behind it, the feature cadence has been relentless.

Some noteworthy recent additions:

• Ephemeral Values (v1.10): Sensitive data like passwords can now be handled without being persisted to state. This was a huge issue - so it was about bloody time!
• Write-Only Arguments (v1.11): Ephemeral values can now be used in managed resource arguments without being stored in state. Massive for security!
• Terraform Stacks CLI (v1.13): Stack operations through the CLI, stronger validation, and improved testing with external variables in .tftest.hcl files.

Here’s the thing about Terraform. The HCL language, the massive provider ecosystem, the sheer volume of community knowledge, Stack Overflow answers, and blog posts. That’s a moat that’s incredibly hard to cross. When something breaks at 2am, you want the tool with the most answers available.

# Terraform - the syntax we all know
resource "aws_s3_bucket" "blog" {
  bucket = "hexamatic.com.au"

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

resource "aws_s3_bucket_website_configuration" "blog" {
  bucket = aws_s3_bucket.blog.id

  index_document {
    suffix = "index.html"
  }

  error_document {
    key = "404.html"
  }
}

Where Terraform Falls Short

• State file security: Sensitive data is stored in plaintext in the state file by default. You’re relying entirely on your backend’s encryption.
• BSL licence: If you’re building a platform product, this might be a deal breaker. Less community, means less eyes and hands.
• Testing: Native testing with .tftest.hcl is improving but still feels limited when compared to what Pulumi offers.
• HCL limitations: It’s declarative, which is great until you need complex logic. Then you’re fighting for_each, dynamic blocks, and ternary operators that make your eyes water.
• Declining community contributions: Since the BSL switch, community pull requests have dropped to roughly 9% of total contributions, down from 21% prior. Development is now overwhelmingly driven by HashiCorp engineers rather than the broader community.

OpenTofu — The Fork That Delivered

Current Version: v1.11.5 (February 2026)

When the Linux Foundation announced the OpenTofu fork in September 2023, I’ll be honest, I was sceptical. We’ve all seen open source forks fizzle out. This one didn’t.

OpenTofu has crossed 10 million GitHub downloads, has over 27,000 stars, and boasts 140+ corporate backers. The contributor base has nearly tripled to over 160 contributors, with v1.9 alone seeing 49 contributors submit over 200 pull requests. According to Spacelift’s data, roughly half of deployments on their platform now use OpenTofu, and a growing number of greenfield projects are choosing it over Terraform. More importantly, companies like Fidelity Investments aren’t just experimenting with it. They’ve migrated over 2000 applications, managing 50k+ state files and 4 million+ cloud resources. That’s no toy.

What OpenTofu Does That Terraform Doesn’t

Here’s where it gets interesting. OpenTofu isn’t just a licence compliant copy of Terraform. It’s shipping features Terraform doesn’t have:

Native State Encryption

This is the big one. Since v1.7.0, OpenTofu can encrypt your state files natively using AES-GCM with support for AWS KMS, GCP KMS, PBKDF2, and OpenBao key providers. No more relying solely on your backend to handle encryption.

# OpenTofu state encryption - built in, not bolted on
terraform {
  encryption {
    key_provider "aws_kms" "my_key" {
      kms_key_id = "arn:aws:kms:ap-southeast-2:123456789:key/my-key-id"
      region     = "ap-southeast-2"
    }

    method "aes_gcm" "encrypt" {
      keys = key_provider.aws_kms.my_key
    }

    state {
      method = method.aes_gcm.encrypt
    }
  }
}

If you’ve ever lost sleep over sensitive values sitting in plaintext state files, this feature alone might be worth the switch.

Early Variable Evaluation

Since v1.8, you can use variables and locals inside terraform blocks and module sources. This might sound minor, but anyone who’s tried to dynamically set a backend configuration or module source in Terraform knows the pain.

The enabled Meta-Argument (Beta)

OpenTofu v1.11 introduced a beta enabled meta-argument for conditional resource provisioning. No more count = var.enable_thing ? 1 : 0 hacks.

Provider Compatibility

All Terraform providers work with OpenTofu without modification, including the top 100 providers from the Terraform Registry. Many provider maintainers now test against both. OpenTofu also maintains its own registry with 3,900+ providers and 23,600+ modules.

That said, compatibility will gradually diverge as both projects evolve independently. If you’re using niche or vendor specific providers, best to verify OpenTofu support before making the jump!

Migration Reality Check

Fidelity’s experience is instructive. They achieved 70% migration in two quarters by targeting the largest Terraform users first. Their key insight?

“The code itself isn’t the hard part. Changing the CLI in a pipeline is trivial. The complexity lives in the surrounding ecosystem: versioning, CI/CD, governance, and artifact management.”

Sounds spot on to me! The tofu CLI is a drop in replacement for the terraform CLI. Your .tf files don’t need to change. But your CI/CD pipelines, your state backend configurations, your governance workflows will all need attention.

Pulumi — The Language-Native Approach

Languages: TypeScript, Python, Go, .NET, Java, YAML

Pulumi takes a fundamentally different approach. Instead of learning HCL, you write infrastructure code in the language you already know. For a Python dev, that’s Python. For a TypeScript shop, that’s TypeScript. No new syntax to learn.

// Pulumi - infrastructure in TypeScript
import * as aws from '@pulumi/aws';

const bucket = new aws.s3.Bucket('blog', {
  bucket: 'hexamatic.com.au',
  website: {
    indexDocument: 'index.html',
    errorDocument: '404.html',
  },
  tags: {
    Environment: 'production',
    ManagedBy: 'pulumi',
  },
});

export const bucketName = bucket.id;

# Or the same thing in Python
import pulumi_aws as aws

bucket = aws.s3.Bucket("blog",
    bucket="hexamatic.com.au",
    website=aws.s3.BucketWebsiteArgs(
        index_document="index.html",
        error_document="404.html",
    ),
    tags={
        "Environment": "production",
        "ManagedBy": "pulumi",
    },
)

pulumi.export("bucket_name", bucket.id)

Pulumi Neo — The AI Wildcard

The headline launch of 2025 was Pulumi Neo, a purpose built AI agent for platform engineering. Unlike generic coding assistants, Neo understands cloud environments, IaC patterns, and secrets management natively.

Werner Enterprises is one of the early adopters and reported reducing infrastructure provisioning time from 3 days to 4 hours while maintaining SOC 2 compliance. That’s… impressive if it holds up at scale.

Pulumi also shipped an MCP Server that connects AI code assistants (GitHub Copilot, Claude, Cursor) with Pulumi’s CLI and registry. Whether you think AI assisted infrastructure is genius or terrifying… probably depends on how many times you’ve accidentally nuked a production resource.

The Testing Advantage

This is where Pulumi genuinely shines. Because you’re writing in a real programming language, you get access to mature testing ecosystems:

• Unit tests with pytest, Jest, Go testing, NUnit
• Property tests that run assertions during deployment
• Integration tests that deploy temporary infrastructure and validate

Compare that to Terraform’s .tftest.hcl files and it’s night and day. If testing is a priority for your team, Pulumi has a compelling argument.

The Terraform Bridge

Here’s Pulumi’s sneaky play. They’ve announced native HCL support and Terraform/OpenTofu state support, both currently in private beta with GA targeted for Q1 2026. The idea is you can manage existing Terraform configurations directly through Pulumi without rewriting anything. Smart move.

Where Pulumi Falls Short

It’s not all roses, and this is worth being honest about:

• Community knowledge gap: Remember that 2am debugging point I made about Terraform? It cuts the other way for Pulumi. Stack Overflow coverage is a fraction of Terraform’s, and when you’re stuck on a niche provider issue…you’ll feel it.
• Library maturity: Not all language SDKs are created equal. Some provider implementations are rough around the edges, particularly for less common services.
• Pulumi Cloud dependency: While self managed backends exist (S3, Azure Blob, GCS, local filesystem), the experience is noticeably smoother with Pulumi Cloud. Raises reasonable questions about long term vendor dependency.
• Steeper than advertised: “Use the language you already know” sounds frictionless, but understanding Pulumi’s resource model, outputs, inputs, and stack references is its own learning curve on top of your language skills.

AWS CDK — The AWS-Native Option

Languages: TypeScript, Python, Java, C#, Go

If your world is AWS and you don’t need multi-cloud, there’s an elephant in the room that can’t be ignored (I’ve tried…): the AWS Cloud Development Kit. CDK lets you define AWS infrastructure using familiar programming languages, similar to Pulumi, but it synthesises down to CloudFormation templates under the hood.

The killer feature is CDK’s L2 and L3 constructs. These are high level abstractions that come with sensible defaults baked in. Create an S3 bucket and it’s encrypted by default. Create a Lambda function and CDK handles the IAM role, log group, and permissions for you. It’s opinionated in all the right ways.

// CDK - high-level constructs with sensible defaults
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';

const bucket = new s3.Bucket(this, 'Blog', {
  bucketName: 'hexamatic.com.au',
  websiteIndexDocument: 'index.html',
  websiteErrorDocument: '404.html',
  // Encryption, versioning, access logging — all configurable
  // with secure defaults out of the box
});

State management is another quiet strength. CloudFormation handles state natively, so there are no state files to manage, encrypt, or lose. Drift detection and automatic rollback on failed deployments come for free. If you’ve ever corrupted a Terraform state file… you’ll appreciate this more than you’d like to admit.

The CDKTF Cautionary Tale

Here’s a relevant footnote. HashiCorp tried to bridge this gap with CDKTF (Cloud Development Kit for Terraform), which let you use CDK style programming languages to generate Terraform configurations. In December 2025, they deprecated it. The project didn’t find product market fit at scale.

That’s telling. It suggests the community wants either proper declarative HCL or a fully imperative approach with real cloud integration, not a hybrid that sits uncomfortably between the two.

Where CDK Falls Short

• AWS only: This is the big one. If you’re multi-cloud or planning to be, CDK simply isn’t an option.
• CloudFormation ceiling: You inherit all of CloudFormation’s limitations, including slower deployments, 500 resource stack limits, and occasionally lagging support for brand new AWS services.
• Abstraction complexity: L2/L3 constructs are magic until they’re not. When you need to drop down to L1 (raw CloudFormation), the experience can be jarring.
• Vendor lock-in: You’re tying your infrastructure code directly to AWS. That’s fine until it isn’t…

The Comparison

Let’s lay it all out:

Aspect	Terraform	OpenTofu	Pulumi	AWS CDK
Licence	BUSL 1.1	MPL 2.0 (truly open source)	Apache 2.0 (engine), commercial (cloud)	Apache 2.0
Language	HCL	HCL	TypeScript, Python, Go, .NET, Java, YAML	TypeScript, Python, Java, C#, Go
Multi-Cloud	Yes	Yes	Yes	AWS only
State Management	State files (backend)	State files (native encryption)	Pulumi Cloud or self-managed	CloudFormation (managed by AWS)
State Encryption	Backend-dependent	Native AES-GCM	Encrypted by default (Pulumi Cloud)	Managed by AWS (encrypted)
Managed Backend	Terraform Cloud (paid)	Third-party (env0, Spacelift)	Pulumi Cloud (free tier available)	CloudFormation (free)
Testing	.tftest.hcl, Terratest	.tftest.hcl, Terratest	Native language test frameworks	Native language test frameworks
Provider Ecosystem	Largest	Same providers, own registry	Bridges Terraform providers	AWS services (L1/L2/L3 constructs)
Governance	IBM/HashiCorp	Linux Foundation, community	Pulumi Inc.	AWS
Learning Curve	Moderate (HCL)	Same as Terraform	Moderate (resource model + language)	Moderate (constructs + CloudFormation)
AI Features	Limited	None	Pulumi Neo, MCP Server	Amazon Q integration

So Which One Do You Pick?

Alright, decision time. Here’s my honest take based on what I’ve seen in the wild:

Stick with Terraform if:

• You have a massive existing Terraform codebase and no compelling reason to migrate
• You’re using Terraform Cloud/Enterprise and it works for you
• The BSL licence doesn’t affect your use case (most internal teams, it won’t)
• You value the largest community knowledge base and want the most Stack Overflow answers

Move to OpenTofu if:

• The licence change genuinely concerns your organisation or your legal team has flagged it
• Native state encryption is a must have (and honestly, it should be)
• You want a truly open source tool governed by a foundation, not a corporation
• You’re starting a new project and want to hedge against future licence changes

Choose Pulumi if:

• Your team already has strong Python/TypeScript/Go skills and resents learning HCL
• You need multi-cloud support and want to write in a real programming language
• Testing infrastructure code is a genuine priority (it should be, but let’s be real…)
• You’re willing to trade community knowledge breadth for language native tooling

Choose AWS CDK if:

• You’re all in on AWS with no multi-cloud ambitions
• You want high level abstractions with secure defaults out of the box
• State management headaches are something you’d rather not think about
• Your team already knows TypeScript or Python and wants the tightest possible AWS integration

For what it’s worth, vendor lock in has always been my reason for avoiding CDK. For multi-cloud or cloud agnostic work, I am now considering OpenTofu for HCL-based work. The state encryption and dynamic terraform blocks addresses things that have bothered me about Terraform for years.

But if you’ve got a mature Terraform setup that’s working? Don’t migrate for the sake of it. The grass isn’t always greener, and migration costs are real. As Fidelity discovered, the code change is trivial but the ecosystem around it is where the complexity hides.

Honourable Mentions

This article focuses on the big four, but the IaC landscape is vaster than that. A few tools worth keeping on your radar:

Crossplane graduated as a CNCF project in October 2025, with over 3000 contributors from 450+ organisations including Nike, NASA, SAP, and IBM. If you’re running Kubernetes and want to manage cloud resources as custom resources within your cluster, Crossplane is the Kubernetes-native answer to infrastructure provisioning. It’s a different paradigm entirely, not a Terraform replacement, but increasingly relevant for platform teams.

Terragrunt is approaching its 1.0 release and remains the go-to for keeping HCL configurations DRY across environments. The new Stacks feature (GA as of v0.78) brings improved orchestration for multi-stack deployments.

What’s Next?

The IaC space isn’t done shifting. Keep an eye on:

• IBM’s next move with the BSL — Will they reverse it? Open it up? Double down?
• OpenTofu v1.12 — Stabilising external key providers for state encryption
• Pulumi’s HCL/State GA — If this works well, it could be a genuine bridge for Terraform teams
• Provider divergence — As Terraform and OpenTofu evolve independently, provider compatibility will be the canary in the coal mine
• Crossplane v2 maturity — CNCF graduation gives it serious credibility; watch for broader adoption beyond Kubernetes-native teams

Whatever you choose, the fact that we have genuine competition in this space is a good thing. Competition breeds innovation, and we’re all better off for it.

---