DevOps / IaC Landscape
Choosing an infrastructure as code tool after the fork
Three years after HashiCorp relicensed Terraform, the infrastructure as code layer has settled into a genuine choice rather than a formality. OpenTofu and Terraform have diverged, Pulumi has quietly become the option for teams who want real languages, SST runs on top of Pulumi, and Ansible is still doing a completely different job that people keep confusing with this one.
Reviewed August 2026. Back to DevOps guides.
Two lanes people keep merging
Provisioning creates and destroys resources that did not exist: networks, databases, buckets, DNS records, clusters, queues. It is declarative, it keeps state, and the state file is the crown jewels. Terraform, OpenTofu, Pulumi, SST, CloudFormation, and Bicep all live here.
Configuration management takes a machine that already exists and makes it match a desired shape: packages, users, services, files, kernel parameters. Ansible, Chef, and Puppet live here, and they hold no state file because the machine itself is the state.
Most teams need the first and only some need the second. If your servers are cattle rebuilt from an image or a container on every deploy, configuration management is a lane you can skip entirely - which is exactly what happened to it over the last decade.
And one honest caveat before the tool list: if your entire infrastructure is one VPS and a managed database, IaC is overhead. A README with the four clicks in it is a legitimate answer until you have a second environment. IaC starts paying the moment you need staging to be genuinely identical to production, or the moment more than one person changes infrastructure.
The tools, with verdicts
OpenTofu
About 12% adoption - the greenfield default
The community fork of the last MPL-2.0 Terraform, now a Linux Foundation project that joined the CNCF in 2025 with a special exception to keep its open source license. It reads and writes the same HCL and the same state format, so switching is usually one binary swap. What it has that Terraform's open source CLI does not: native state encryption at rest, and for_each on provider blocks. Adoption reached roughly 12 percent of IaC practitioners by April 2026 with another 27 percent evaluating. opentofu.org
Verdict: Start here on anything new. Truly open license, and the migration cost is near zero.
Terraform
Still the largest installed base
Source-available under BUSL 1.1 since 2023, and now an IBM property. For the overwhelming majority of users the license changes nothing - it restricts building a competing commercial IaC service, not running your own infrastructure. What you are really buying into is the HCP Terraform ecosystem: the public module registry, remote state with locking, Sentinel policy as code, drift detection, and a support contract a procurement department will accept. The commercial gravity around it is real and is the main argument for staying. developer.hashicorp.com
Verdict: Stay if you are on HCP or need a vendor to call. Do not migrate for its own sake.
Pulumi
3.x line - real programming languages
Same model as Terraform - declare resources, keep state, diff and apply - but written in TypeScript, Python, Go, C#, Java, or YAML instead of HCL. That means loops, functions, classes, package managers, and unit tests for your infrastructure, plus 150-plus providers including ones bridged straight from the Terraform ecosystem. The 3.x line ships continuously and had reached 3.256 by early August 2026. The tradeoff is genuine: real languages invite real abstractions, and a clever infrastructure codebase is much harder to review than a boring one. pulumi.com
Verdict: Pick it when the infrastructure needs logic, or when HCL is the thing slowing your team down.
SST v3
TypeScript on AWS, built on Pulumi
SST v3 threw out CDK and CloudFormation and rebuilt on the Pulumi engine with Terraform providers underneath, which removed CloudFormation's stack limits and its famously slow deploys. You describe an application - a Next.js site, a queue, a cron, a bucket, a Postgres - in TypeScript, and it provisions the AWS resources plus the wiring between them. Live development against real cloud resources is the standout feature. It is opinionated toward AWS application shapes, so it is an application framework that happens to provision, not a general IaC tool. sst.dev
Verdict: The fastest path from TypeScript app to running AWS infrastructure. Narrow by design.
Ansible
A different lane, not a competitor
Agentless configuration management over plain SSH: YAML playbooks that install packages, render templates, manage services, and enforce users on machines that already exist. No state file, no agent to install, and it will happily manage a server somebody built by hand five years ago - which is why it survives in every environment with physical hardware, network gear, or long-lived VMs. It can provision cloud resources through modules, but it is worse at that than any tool above because it has no state to diff against.
Verdict: Use it alongside a provisioner, never instead of one.
Cloud-native options
AWS CDK, CloudFormation, Bicep
Every major cloud ships its own: CloudFormation and CDK on AWS, Bicep and ARM on Azure, Deployment Manager and Config Connector on GCP. They win on same-day support for new services and on being the format the vendor's own documentation uses. They lose on portability, on cross-vendor resources such as DNS and observability, and - for CloudFormation specifically - on how long a failed stack takes to roll back. Reasonable if you are single-cloud forever and want zero third parties in the chain.
Verdict: Defensible on one cloud. A trap the moment a second vendor appears in your stack.
The differences that decide it
| Tool | License | You write | Best fit |
|---|---|---|---|
| OpenTofu | MPL-2.0, open source | HCL | New multi-cloud infrastructure, and anyone who wants encrypted state without a paid backend. |
| Terraform | BUSL 1.1, source-available | HCL | Existing estates, HCP Terraform users, and organizations that need a support contract. |
| Pulumi | Apache 2.0 CLI, paid cloud backend | TypeScript, Python, Go, C#, Java | Teams that want types, tests, and loops in infrastructure code without learning HCL. |
| SST v3 | MIT, runs on the Pulumi engine | TypeScript | Full-stack TypeScript applications deploying to AWS, especially serverless shapes. |
| Ansible | GPL-3.0, Red Hat | YAML playbooks | Configuring long-lived servers, network devices, and anything you cannot rebuild from an image. |
Gotcha: state files move cleanly between Terraform 1.5.x and OpenTofu in both directions - until you enable OpenTofu's state encryption. After that Terraform cannot read the file, which makes encryption the one genuinely one-way step in the migration. Turn it on deliberately, not on day one.
Our pick
OpenTofu for new work, Terraform if you are already there
For anything greenfield, OpenTofu. It speaks the same HCL, consumes the same providers and modules, carries a real open source license, and ships native state encryption that the open source Terraform CLI still does not have. There is no meaningful learning cost and no meaningful exit cost, which makes it the low-regret option.
If you already run Terraform at scale on HCP, stay. Migrating a working estate to gain a license you were not violating and a feature you may not need is not a good use of a quarter. Revisit it when a renewal comes up or when state encryption becomes a compliance requirement.
Choose Pulumi when the team is strongly typed-language-first and HCL is genuinely costing you velocity, and SST when the whole product is TypeScript on AWS. Add Ansible only if you own machines that outlive a deploy. And if you are running one VPS, skip all of it and write the runbook - see the self-hosting guide.
Where to go next
Terraform vs OpenTofu
The fork three years on, and the real cost of switching.
Read the verdictTerraform cheatsheet
HCL blocks, state commands, workspaces, and the plan flags you forget.
Open the referenceCI/CD pipeline
Run plan on pull requests and apply on merge, with OIDC instead of keys.
Follow the guideHosting layer
What you will actually be provisioning, priced and compared.
Browse the layerIf the infrastructure you are describing is mostly containers, read container tools first - the orchestration decision changes how much of this you need to write at all.