One afternoon in August 2023, a friend who does DevOps at a cross-border ecommerce company messaged me. “HashiCorp changed Terraform’s license. Our entire infrastructure is built on it. Should I be worried?”
He wasn’t the only one worried. After HashiCorp announced it was switching Terraform from MPL 2.0 to the Business Source License, the open-source community erupted. In plain terms, BSL means competitors can no longer take Terraform’s source code and build commercial products on it. For most end users, day-to-day work was unaffected, but the unease of “will the rules change again someday” lodged itself like a splinter.
Soon after, the Linux Foundation stepped in to host OpenTofu, a project forked from Terraform’s last open-source release, with a promise to stay open forever. Community splits, tool forks, license battles: none of this is rare in the open-source world. But when it happens to the infrastructure tool you depend on every day, anyone would stop and reconsider their stack.
And right at that moment, more and more people started taking a serious look at another name: Pulumi.
When HCL Becomes a Kind of Faith
To understand why Terraform ruled the IaC world for so many years, you first have to understand HCL.
HCL, the HashiCorp Configuration Language, is a declarative domain-specific language. You don’t tell it “create the VPC first, then the subnet, then attach the route table.” You describe the final state you want, and Terraform works out what it takes to get from the current state to the target. The approach is elegant and safe. You write down what the world should look like, not how to change the world step by step.
I’ve watched plenty of teams fall in love with Terraform for its determinism. One ops team managing three clouds wrote hundreds of modules in Terraform covering every resource across AWS, Azure, and GCP. Every change went through terraform plan, they reviewed the diff, then ran apply, and when something broke they rolled back the state. Everything was traceable, everything auditable.
Terraform’s provider ecosystem is its deepest moat. There are thousands of providers on the Terraform Registry today, from the major cloud vendors to niche SaaS, and almost any service you can think of has a provider written for it. That means no matter how unusual your stack is, you can probably find a place for it in Terraform’s world.
But HCL has its maddening moments too.
When you need to express complex logic in infrastructure code, HCL’s expressiveness starts to run out. Want a conditional? count and ternary expressions barely cover it. Want a loop? for_each works, but nest a few and readability collapses. Want to abstract a reusable chunk of logic? Modules are the standard answer, but designing module interfaces, passing variables, and referencing outputs, after enough of it, feels like using a programming language that keeps insisting it isn’t one, while still forcing you to think like a programmer.
A backend developer once vented to me, “Something I’d solve in three lines of Python takes twenty lines of HCL, and I still have to dig through the docs to confirm whether the syntax even supports it.”
When Developers Say “I Want to Use My Own Language”
Pulumi exists precisely as a response to that pain.
Pulumi’s core idea is that infrastructure code is code. Not a config file that acts “like code,” not some restricted DSL, but an actual programming language. You can define infrastructure in TypeScript, Python, Go, C#, Java, or even YAML.
What does that buy you?
Picture yourself as a full-stack developer writing Node.js services in TypeScript on the backend and React on the front. Now you need to set up infrastructure: an ECS cluster, an RDS database, a set of IAM policies. With Terraform, you’d learn a new language (HCL), grasp its particular module system, and get used to its way of passing variables. With Pulumi, you open VS Code, run npm init, and describe the infrastructure in the TypeScript you write every day. IDE autocomplete, type checking, and refactoring tools all work. Need a function to abstract repeated logic? Trivial. Need to generate resource config dynamically from an environment variable? One if statement.
I know a three-person startup, all Python people on the backend, who always found Terraform awkward for managing AWS resources. After switching to Pulumi, their speed writing infrastructure code doubled, because they no longer had to “translate” the Python logic in their heads into HCL syntax. They wrapped groups of related resources in Python classes, handled tagging with decorators, and tested infrastructure logic with pytest. All of it was the world they already knew.
Pulumi also works declaratively. You still describe the desired state and the engine diffs and executes it. The only difference is that the way you express that desired state moves from a restricted DSL to a Turing-complete programming language.
State Management: Who Keeps Your Source of Truth
One of the most fundamental concepts in any IaC tool is state. The state file records what the infrastructure currently looks like, and that’s the basis for calculating change plans. Get state management wrong and, at best, you drown in drift alerts; at worst, you delete production resources by accident.
Terraform’s state management evolved from local files to remote storage. Early on, people just dropped terraform.tfstate in an S3 bucket and called it done. Then came state locking through DynamoDB, and later Terraform Cloud offered one-stop remote state, team collaboration, and policy as code through Sentinel. If you’d rather not use Terraform Cloud, you can use an open-source backend like S3, GCS, or Azure Blob, but then you have to handle the locking and access control yourself.
Pulumi offered Pulumi Cloud as the default state backend from the start. It handles state storage, encryption, concurrency control, change history, and team permissions as one package. Pulumi supports self-hosted state storage too (S3, Azure Blob, local filesystem), but the company clearly prefers you use its cloud service.
There’s a subtle difference here. In the Terraform ecosystem, you can avoid every one of HashiCorp’s commercial products and run the whole flow purely on open-source tooling. Pulumi’s engine is open source, but if you skip Pulumi Cloud, the self-hosted state experience takes a hit. It’s not that you can’t do it, you just have to fill in the things Pulumi Cloud would otherwise handle for free.
One Table for the Core Differences
When there’s too much information, a table helps you find the key differences fast.
| Dimension | Terraform | Pulumi |
|---|---|---|
| Language | HCL (declarative DSL) | TypeScript / Python / Go / C# / Java / YAML |
| State management | Local file / S3 / Terraform Cloud | Pulumi Cloud / S3 / local file |
| Provider ecosystem | Thousands, extremely broad | Fewer but growing, can bridge Terraform providers |
| Learning curve | Must learn HCL, friendly to pure ops | Quick start with a familiar language, developer-friendly |
| Logic expression | Limited (count / for_each / ternary) | Full programming language (loops/functions/classes/packages) |
| Testing | Limited (terraform test, newer) | Native unit and integration testing |
| Pricing | CLI free and open source; Terraform Cloud charges per resource | CLI free and open source; Pulumi Cloud free for individuals, teams charged per resource |
| License | BSL 1.1 (since 2023) | Apache 2.0 |
| Best-fit team | Large ops teams, multi-cloud, existing HCL investment | Developer-led teams, complex logic, general-language preference |
But a table only tells you what things are, not how they feel. The real selection decision usually happens in the scenarios a table can’t hold.
Ecosystem Isn’t Just About Numbers
Pulumi holds a hidden card: it can bridge Terraform’s providers. Through the Pulumi Terraform Bridge, a large number of Terraform providers can be used directly inside Pulumi. That means Pulumi users get to enjoy the breadth of Terraform’s ecosystem indirectly.
But “bridged” and “native” aren’t the same thing. Bridged providers occasionally lag on versions, carry incomplete type definitions, or lack documentation. When you hit an edge case, the debugging path gets longer, because you have to work out whether the problem sits in the Pulumi layer or the Terraform provider underneath.
Terraform’s native providers, polished over years, come with detailed docs, rich community Q&A, and troubleshooting posts everywhere. When you’re chasing a production issue at three in the morning, whether you can find an answer on GitHub Issues or Stack Overflow within five minutes is a very real gap.
The Logic Behind Pricing
Both CLIs are free and open source, and you can use them without spending a cent.
The difference is the cloud service. Terraform Cloud’s free tier gives you remote state storage and basic team collaboration, while the paid version charges by the number of resources managed, plus Sentinel policies, SSO, and other enterprise features. Pulumi Cloud’s individual plan is also free (with a resource cap), and the team plan likewise charges per resource.
One trend to watch: after HashiCorp was acquired by IBM in 2024, Terraform Cloud’s enterprise pricing became more “IBM-flavored,” leaning toward bundling enterprise features for large customers. Pulumi, a comparatively young company, keeps a more flexible pricing strategy that’s a bit friendlier to smaller teams.
That said, pricing is rarely the deciding factor. Unless you’re at a scale that manages tens of thousands of resources, neither cloud service will be your budget bottleneck. The expensive thing is always labor. Whichever tool makes your team more efficient is the cheaper one.
OpenTofu: The Third Person in the Room
You can’t discuss Terraform versus Pulumi without OpenTofu.
OpenTofu is the Terraform community’s direct answer to the BSL change. It maintains API compatibility with Terraform and promises to keep the MPL 2.0 open-source license. If your core anxiety is license risk, OpenTofu is a solution that doesn’t require migrating your stack. Your HCL code, modules, and providers can move across almost seamlessly.
But OpenTofu faces real challenges. How fast the post-fork community grows, how it handles feature divergence from later Terraform releases, and who keeps investing in maintenance are all questions that need time to answer. As of 2026, OpenTofu has its own stable releases and independent features, but it’s still catching up on user base and enterprise adoption.
So the question becomes a three-way choice: stay on Terraform (accept BSL), migrate to OpenTofu (keep the HCL ecosystem), or switch to Pulumi (change the paradigm).
Who Should Choose Terraform
If your team fits the following description, Terraform (or OpenTofu) is probably the safer pick.
You have a dedicated infrastructure or platform engineering team, and they aren’t necessarily software developers by background, more ops and SRE. HCL is already their native tongue, they’ve built up a large module library, and their CI/CD pipelines are built around terraform plan and terraform apply. The migration cost is real, and your infrastructure spans multiple cloud vendors and depends on plenty of niche providers.
In that scenario, Terraform’s value isn’t that it’s “better,” it’s that it’s “more mature.” The pitfalls you’ll hit, someone hit before. The problems you’ll face, someone answered. The integration you need, someone wrote. The efficiency that comes from that ecosystem maturity is hard for any new tool to replicate in the short term.
Another common scenario is heavily regulated industries like finance and healthcare. Terraform’s change flow suits auditing naturally. Declarative code plus plan output plus state history equals a complete audit trail. An auditor can read what a plan will create and destroy, which is far more intuitive than interpreting the result of a TypeScript program.
Who Should Choose Pulumi
If your team matches this picture, Pulumi may feel like water to a fish.
You’re a developer-led team, and infrastructure is managed by the same people writing the business code (the “you build it, you run it” model). Everyone is more comfortable with TypeScript or Python than with any DSL. Your infrastructure logic has a lot of dynamism: generating resources automatically based on the number of microservices, composing deployment topologies from an environment config matrix, calling external APIs inside infrastructure code to fetch parameters.
In that scenario, Pulumi’s advantage is overwhelming. You don’t switch back and forth between an “infrastructure language” and a “business language.” You can keep infrastructure code and application code in the same monorepo, share type definitions, share utility functions, even run the same CI pipeline. For these teams, HCL isn’t a “clean declarative language,” it’s an unnecessary cognitive load.
There’s one more scenario that suits Pulumi especially well: when your infrastructure is itself part of the product. Say you’re building a PaaS platform that needs to spin up isolated infrastructure resources for each tenant dynamically. That kind of need expresses itself naturally in a programming language and takes plenty of workarounds in HCL.
When You Choose, Be Honest With Yourself
The worst reason I’ve seen for a decision is “this one’s newer and cooler.” The best reason I’ve seen is honestly asking yourself three questions.
First, is your team more comfortable writing code or writing config? If most of the team are developers who “want to close the laptop the moment the YAML is done,” Pulumi suits them naturally. If the team is more used to declarative thinking and believes “less code is safer,” Terraform’s philosophy fits better.
Second, how complex are your infrastructure’s logic needs? If it’s relatively static, patterned resource orchestration (say “a standard VPC plus EKS plus RDS per environment”), HCL’s expressiveness is plenty. If you need heavy conditional logic, loop generation, and dynamic references, a programming language wins by a mile.
Third, how much ecosystem risk can you carry? Terraform’s ecosystem has ten years of validation. Pulumi’s is growing fast, but coverage and community depth still trail. If your project relies on a lot of fringe cloud services, Terraform has a higher chance of having a ready-made provider.
No single tool suits everyone. But if a team honestly answers the three questions above, the answer usually surfaces on its own. No fence-sitting, no “it depends.” Your team profile and technical context have already made most of the decision. What’s left is just the nerve to take the step.
Related reading
- Terraform vs Pulumi: Which IaC Tool to Choose in 2026? HCL or Real Programming Language?
- Terraform Alternatives in 2026: OpenTofu, Pulumi, Spacelift, env0, and Crossplane Compared
- IaC Management Platform Comparison 2026: Spacelift vs env0 vs Terraform Cloud vs Scalr
- GPT-5.5 Reasoning Effort Levels: How Developers Pick the Right Setting
- Claude Code Channels vs OpenClaw: Two Competing Visions for How Developers Will Talk to AI
Stay updated with our latest AI insights
