The state of infrastructure as code in 2026

Every infrastructure team I’ve worked with in the last decade has had the same argument, and the argument has barely changed while the vendors around it reshuffled completely. So a status report, from someone who has written CloudFormation for healthcare, CDK for this site, and Terraform for platforms doing hundreds of millions of requests a day.

Terraform survived its own license change

In August 2023 HashiCorp moved Terraform from open source to the BUSL, and for a few months the sky was reliably falling. Then IBM bought HashiCorp (the deal closed in early 2025), which was the second predicted apocalypse. Here’s what actually happened in production terms: almost nothing.

Terraform still has the largest provider ecosystem, the deepest pool of engineers who can write it, and the most battle-tested workflows. The license change matters if you’re building a product that embeds Terraform. For the overwhelming majority of teams, who run it internally against their own cloud accounts, BUSL changed nothing about their daily work. That’s not a defense of the move, which spent a decade of community goodwill in one press release. It’s an observation about switching costs.

OpenTofu, the Linux Foundation fork, turned out to be exactly what a good fork should be: a credible exit. It reached 1.0 within months of the fork, has shipped features on its own cadence since (state encryption landed there first), and it keeps HCL skills portable. Some teams have moved. Most, in my experience, noted its existence, felt relieved the option exists, and kept running Terraform. The fork’s biggest achievement may be disciplinary: it put a ceiling on how badly the steward can treat the ecosystem.

I run multi-region Terraform on Terraform Cloud at my day job. It’s boring in the way infrastructure tooling should be boring. The pain points are the same ones as five years ago: state surgery when someone needs to split a workspace, plans that slow down as a workspace bloats, provider upgrades that arrive as surprises, and module versioning discipline that decays without an owner.

CloudFormation is the COBOL of the cloud, and I mean that respectfully

Nobody starts a greenfield multi-cloud platform on raw CloudFormation in 2026. But dismissing it misreads where it lives: underneath everything. CDK synthesizes to it. SAM is it. Control Tower and half of AWS’s own service integrations emit it. And an enormous amount of running production, including systems I built at Aetna that are presumably still processing healthcare traffic, is plain CloudFormation that works and has no business case for replacement.

I led a migration of hundreds of resources from CloudFormation to Terraform, and the lesson wasn’t that CloudFormation is bad. The lesson was that the migration is a state-and-sequencing project, not a rewrite. The YAML-to-HCL translation is the trivial 10%. The other 90% is importing resources without replacing them and carving module boundaries that match how teams actually own things, all while the platform keeps shipping underneath you.

CDK and Pulumi: real languages, real tradeoffs

The imperative-language tools found their niche and stayed in it. CDK is a genuinely good developer experience when your world is all-AWS and your engineers think in TypeScript or Python; this site is deployed by CDK, and constructs like “a private bucket behind CloudFront with Origin Access Control” being one line is a real productivity claim. Pulumi offers the same shape across clouds.

The tradeoff shows up at operations time. A loop that stamps out resources is lovely to write and miserable to diff. When something drifts at 2am, the distance between the code someone wrote and the resource that actually exists is longer than it is with HCL, and on-call pays that distance. I’ve watched platform teams standardize on Terraform not because it’s more expressive but because it’s less: the constraint is the feature.

What I’d pick today

For a platform team on AWS with mixed workloads: Terraform or OpenTofu, chosen on license posture, with remote state you control, plan-on-PR wired into CI through OIDC (no stored cloud keys), a small set of versioned modules, and a named owner for them. For an all-AWS product team that lives in TypeScript: CDK is a fine answer, and pretending otherwise is tool tribalism.

Two disciplines matter more than the tool choice. First, everything goes through the pipeline; the console is for reading. Click-ops drift is still the largest source of IaC rot I see, regardless of tool. Second, review the plan, not the code. The diff that matters is the one against reality.

The tool argument is the fun part, which is why it consumes so many design docs. The disciplines are the part that determines whether your infrastructure is actually as-code three years from now.