Pulumi vs Terraform: The Real Infrastructure as Code Tradeoffs

Pulumi vs Terraform is usually framed as “real programming languages versus HCL.” That framing is useful for about five minutes, then it starts hiding the real decision.

The real question is not whether Python feels better than HCL, or whether TypeScript autocomplete is nicer than Terraform’s expression language. The real question is which tool creates a better operating model for your team after the first three months: fewer unsafe changes, clearer ownership, better review workflows, less state anxiety, more reusable infrastructure, lower platform cost, and a learning curve your organization can actually absorb.

Terraform is still the conservative default for many teams because its ecosystem is enormous, its workflow is familiar, and its module/provider gravity is hard to beat. As of May 2026, the Terraform Registry browse pages list more than 6,300 providers and more than 21,800 modules. That number matters because infrastructure teams do not choose tools in a vacuum. They choose search results, Stack Overflow answers, vendor examples, hiring market, module maturity, and years of operational habits.

Pulumi is not just “Terraform in Python.” It is an Infrastructure as Code platform that runs a program, builds a resource graph, computes a desired state, and uses providers to create, update, or delete cloud resources. It supports TypeScript and JavaScript, Python, Go, .NET, Java, and YAML. It also has a serious platform story around Automation API, policy, secrets, cloud deployments, drift detection, and an internal-developer-platform model. The attraction is real: application engineers can use familiar languages, shared packages, unit testing frameworks, IDE tooling, and normal software abstractions to build infrastructure.

That attraction is also where the danger lives. A general-purpose language gives you power, but power can turn infrastructure code into a clever software project that only its author can safely change. HCL is more limited, but those limits are not only weakness. They create a smaller vocabulary, a more predictable review surface, and a style that travels well between companies.

This article is a deep comparison for platform teams, DevOps engineers, SREs, cloud engineers, and technical leaders who need to choose a default IaC path. It covers facts, pricing, learning curve, policy, state, ecosystem, migration, and real scenarios. The goal is not to crown a winner. The goal is to make the tradeoff explicit before you bet your infrastructure platform on a slogan.

Short Version

Terraform is usually the better default when the organization values ecosystem maturity, standardization, hiring familiarity, and a predictable plan/apply workflow more than language expressiveness.

Pulumi is usually the better fit when the organization wants infrastructure code to live closer to product engineering, needs real programming constructs, wants to build custom platform APIs, or has enough engineering discipline to keep a general-purpose language from becoming an unreviewable abstraction maze.

The cleanest decision is not tool-first. It is team-first.

The paradox: Terraform is less expressive, which often makes it easier to standardize. Pulumi is more expressive, which often makes it easier to build powerful platform abstractions. The wrong team can make either tool painful.

The Current Facts That Should Anchor The Debate

It is easy to compare stale versions of both tools. Do not do that. As of May 4, 2026, these are the facts I would put on the whiteboard before choosing.

Notice the pricing row. If you run Terraform CLI with an S3 backend and DynamoDB or native S3 locking, the software cost can be near zero, but the operational cost is yours. If you use HCP Terraform, pricing moves into managed resources and feature tiers. If you use Pulumi Cloud, pricing moves into resources, deployment minutes, secrets, governance, and edition limits. The spreadsheet matters because a tool that looks “free” in a proof of concept can become a platform budget line later.

For teams already using HCP Terraform, the new HCP Terraform Infragraph guide covers where graph-based visibility fits next to state, modules, Backstage, and blast-radius reviews.

Also notice the registry row. Terraform’s larger registry does not mean every module is production quality. It means the probability of finding an example, issue, provider, module, blog post, or prior production pattern is much higher. Pulumi’s smaller registry does not mean Pulumi lacks coverage. Pulumi supports native providers, Pulumi packages, Terraform-provider bridging, and Terraform module consumption. It means the search path is different and sometimes less paved.

The Mental Model Difference

Terraform starts from configuration. You write declarative HCL that describes resources, data sources, variables, outputs, providers, modules, and lifecycle behavior. Terraform loads that configuration, reads state, refreshes remote reality, calculates a plan, and applies the approved changes. The strongest Terraform habit is the plan file: show me what will change before anything changes.

Pulumi starts from a program. You write code in a supported language. That program creates resource objects. The Pulumi language host runs the program and registers resources with the deployment engine. The engine consults state, calculates operations, and uses providers to make changes. The strongest Pulumi habit is the programming model: use the same language ecosystem, package system, test framework, and IDE that engineers already use.

Those differences sound small until the first production incident.

With Terraform, a pull request often reads like configuration. Reviewers look at variables, resources, modules, plan output, provider versions, and state impact. The code may be verbose, but it is usually shaped like infrastructure.

With Pulumi, a pull request can read like software. Reviewers may need to understand functions, classes, loops, generated resource names, package versions, helper libraries, object composition, async outputs, and language-specific behavior. That is excellent when the team writes disciplined software. It is dangerous when the team hides infrastructure consequences behind abstractions that do not show intent.

The best Pulumi code still looks declarative at the edges. The best Terraform code still uses abstraction. The mistake is treating Pulumi as an excuse to write a framework for every VPC, or treating Terraform as an excuse to copy/paste HCL across 40 environments.

Language Expressiveness: The Feature That Cuts Both Ways

The obvious Pulumi advantage is language power. You can use normal loops, conditionals, functions, classes, packages, tests, and type systems. If your team already writes TypeScript services, a TypeScript Pulumi project can feel natural. If your platform team writes Go CLIs, Pulumi Automation API can sit behind a custom tool. If your data platform uses Python, Pulumi can meet those engineers where they already work.

That matters in real scenarios.

Imagine a platform team that has to create one isolated environment per customer. Each environment has a VPC, subnets, private endpoints, IAM roles, secrets, observability resources, per-tenant DNS, feature flags, and a few SaaS-side resources. In Terraform, you can absolutely build this with modules, for_each, maps, and generated variables. In fact, the Terraform for_each guide is still one of the best patterns for repeatable infrastructure. But once the environment definition becomes a product API, Pulumi starts to feel more natural because the infrastructure can be assembled from typed objects and wrapped in tests.

Now flip the scenario. Imagine a central cloud team that provides approved network, database, queue, and IAM modules to 35 application teams. Those teams mostly need to pass parameters and review plans. They do not need arbitrary code. Terraform may be better because the constrained language keeps module consumers inside a stable contract. You can combine it with Terraform testing, OPA policy-as-code, and a strong private registry model to create a boring, governed path.

The better question is not “is a real programming language better?” The better question is “who will review this code at 4 PM on Friday before it touches production?”

State: Both Tools Hide It Until It Becomes The Whole Problem

State is the part of IaC people underinvest in until it hurts them. Both tools need state. Both tools can use a managed backend. Both tools can use object storage. Both tools can create serious risk when access control, locking, encryption, versioning, and recovery are weak.

Terraform’s own documentation is blunt: Terraform must store state to map real-world resources to configuration, track metadata, and determine what changes to make. By default, Terraform stores local state, but team workflows should use a remote backend such as HCP Terraform or cloud storage with locking and access control. If you are still using local state for anything shared, stop and fix that before debating Pulumi.

Pulumi stores state per stack. Pulumi Cloud is the default managed backend, but Pulumi also supports DIY backends such as AWS S3, Azure Blob Storage, Google Cloud Storage, S3-compatible storage, and local filesystem. Pulumi Cloud adds transactional checkpointing, locking, update history, encryption, auditing, RBAC, and policy integration. A DIY backend gives control but shifts operational responsibility to you.

This is where the comparison becomes less philosophical.

With Terraform on AWS, a common pattern is S3 for encrypted versioned state and a locking mechanism. BitsLovers has a dedicated guide for Terraform state locking with S3 and DynamoDB because that operational detail matters. A broken state lock is not a theoretical problem. It is how two applies corrupt the same environment.

With Pulumi, Pulumi Cloud simplifies the state story, but the convenience belongs in the cost and dependency model. If you use Pulumi DIY state in S3, you regain control and reduce SaaS dependency, but you must own security, permissions, backup, locking behavior, and recovery. Pulumi’s docs explicitly describe that tradeoff: managed backend convenience versus DIY operational responsibility.

The state decision should be made before the tool decision is final. If a team cannot operate a Terraform backend safely, it should not assume it can safely operate a Pulumi DIY backend. If a team cannot accept a SaaS dependency for state, it should model the extra work honestly.

Workflow 1: Choosing The Right IaC Default

Use this workflow before a proof of concept. A proof of concept can lie because it rewards the person who already knows the tool.

1. Start with ownership. Decide whether infrastructure will be owned mostly by platform engineers, application engineers, or a blended model. If platform owns most of the code, Terraform’s standardization advantage grows. If application teams own substantial infrastructure and the platform team provides guardrails, Pulumi becomes more interesting.

2. Classify your infrastructure. VPCs, IAM, Kubernetes clusters, databases, network boundaries, and shared security controls often benefit from strict module contracts. Per-service infrastructure, tenant environments, preview environments, developer sandboxes, and product-coupled resources often benefit from programmatic composition.

3. Count ecosystems, not opinions. Check provider support, module availability, examples, release cadence, issue quality, and managed-service options for your actual cloud providers. Terraform’s registry numbers are a real advantage, but not every module is safe. Pulumi’s smaller package count is a real constraint, but not every use case needs a public module.

4. Model state and cost. Compare Terraform CLI with self-managed state, HCP Terraform, Terraform Enterprise, Pulumi Cloud, and Pulumi DIY backends. Include managed resource counts, deployment minutes, policy features, secrets, audit logs, SSO, private networking, support, and the staff time required to operate the platform.

5. Test governance before scale. Write one policy that blocks public S3 buckets, one policy that requires tags, one policy that blocks broad IAM, and one policy that prevents production database deletion. If the policy path feels awkward in the first week, it will not magically become easy with 80 repositories.

6. Run the 90-day review simulation. Ask who will review changes, who will debug failed applies, who will upgrade providers, who will write modules/components, who will handle state repair, and who will train new engineers. This reveals the actual tool fit.

That workflow should produce one of three decisions: Terraform default, Pulumi default, or split usage. Split usage is valid, but only with boundaries. “Anyone can pick whichever they like” is not a platform strategy. It is future archaeology.

Workflow 2: Operating Terraform At Scale

A strong Terraform operating model usually looks like this:

1. Reusable modules define the approved infrastructure shapes: VPC, EKS, RDS, IAM roles, S3 buckets, queues, monitoring, and deployment primitives.

2. Root modules compose those reusable modules per environment or product. They should stay boring. The more logic you put in a root module, the harder it becomes to reason about blast radius.

3. Remote state is mandatory. State storage is encrypted, versioned, locked, and restricted. Human access to state is exceptional and audited.

4. Pull requests show plan output. The plan is reviewed before apply. Production applies are gated.

5. terraform validate, terraform fmt, terraform test, policy checks, and plan JSON scans run in CI. See Terraform Testing in 2026 for the testing pyramid that makes this practical.

6. OPA, Sentinel, or equivalent controls block dangerous plans before they reach production. BitsLovers has a full OPA Terraform policy guide because “we trust code review” is not enough once multiple teams write IaC.

7. Provider and module versions are pinned. Upgrades are tested in lower environments first. The Terraform 1.15.0 compatibility incident in May 2026 is a useful reminder: even mature tools need release discipline.

8. Drift detection is scheduled. Humans clicking in the cloud console is treated as an exception, not a parallel workflow.

This operating model works because Terraform is opinionated enough to make the workflow consistent. It also works because many people know it. A new engineer can join from another company and probably understand workspaces, modules, providers, state, plan, and apply quickly.

Terraform fails at scale when every team invents its own folder layout, remote-state pattern, module versioning scheme, naming model, and CI pipeline. The tool cannot save you from platform entropy. If you need a production pipeline reference, the GitLab CI/CD Terraform pipeline article shows the kind of gates that make Terraform safer in teams.

Workflow 3: Operating Pulumi At Scale

A strong Pulumi operating model looks different.

1. Pick approved languages. Do not let every team choose a different Pulumi language casually. A company that allows TypeScript, Python, Go, C#, and Java with no boundaries will eventually have five IaC ecosystems, five testing styles, five package-management problems, and five onboarding paths.

2. Build components intentionally. Pulumi components should expose the infrastructure contract product teams need, not the entire cloud-provider API in a prettier wrapper. A good component makes the safe path easy and the dangerous path explicit.

3. Keep programs deterministic. Pulumi preview and update depend on running the program. Avoid non-deterministic naming, time-dependent resource generation, hidden network calls, random values outside managed resources, and environment-dependent logic that changes between preview and apply.

4. Use normal software testing, but do not forget infrastructure tests. Unit tests can validate component behavior. Integration tests can create real stacks. Automation API can drive test deployments. Policy must still guard the final resource graph.

5. Treat stack boundaries as product boundaries. Pulumi stacks commonly represent dev, staging, prod, feature environments, tenants, or regions. Stack outputs and references are powerful, but they must not become an invisible dependency web.

6. Decide between Pulumi Cloud and DIY backends early. Pulumi Cloud simplifies collaboration, state, history, policy, drift, and deployments. DIY backends reduce SaaS dependency but require platform operations.

7. Use Pulumi Automation API only when you really need a platform API. Automation API is a major Pulumi advantage for custom CLIs, internal portals, service provisioning APIs, blue/green workflows, and integration tests. It is overkill if a normal pulumi up in CI would be enough.

8. Apply governance centrally. Pulumi Policies can run locally with policy packs or centrally through Pulumi Cloud. They can use TypeScript, JavaScript, Python, or OPA. The important part is not the language. It is whether a non-compliant deployment can be blocked before it exists.

Pulumi fails at scale when it becomes “whatever code style the service team likes.” Infrastructure code is not ordinary application code. It has external side effects, state, credentials, compliance impact, and deletion risk. Pulumi’s best teams borrow software engineering practices without forgetting that cloud infrastructure has a blast radius.

Learning Curve: Day 1, Day 30, Day 90

Terraform usually wins day 1 for infrastructure teams. The basic workflow is easy to explain: write HCL, run init, run plan, review, apply. Providers expose resources. Modules group resources. State tracks reality. The language has quirks, but a motivated engineer can read simple Terraform quickly.

Terraform gets harder around day 30. That is when engineers hit dynamic blocks, provider aliasing, remote state references, dependency ordering, imports, state moves, lifecycle rules, for_each key stability, and module versioning. The syntax is not hard. The consequences are hard.

Terraform gets organizational around day 90. Now the real questions are ownership, drift, module contracts, policy, upgrade cadence, environment promotion, plan review, and production access. If those are missing, Terraform becomes a pile of scripts with a state file.

Pulumi often has a less predictable day 1. A TypeScript team may love it immediately. A traditional infrastructure team may feel it has too much language surface. A Python-heavy data platform may see it as natural. A multi-language company may accidentally create fragmentation on day one.

Pulumi gets powerful around day 30 if the use case needs real composition. Components, packages, typed interfaces, unit tests, and Automation API become meaningful. Engineers can build higher-level infrastructure products instead of only parameterized modules.

Pulumi gets dangerous around day 90 if the platform team has not set rules. By then, the codebase may include clever helper libraries, shared packages, generated resources, environment-aware logic, and stack references. That can be excellent or terrifying. The difference is discipline.

The hidden Pulumi learning curve is not Python or TypeScript. It is Pulumi’s resource model, output model, state model, provider behavior, preview/update lifecycle, and stack organization. Existing language skill helps, but it does not remove the IaC learning curve.

Policy, Security, And Compliance

IaC without policy is just fast infrastructure mutation. That is dangerous.

Terraform has several governance paths. HCP Terraform supports policy workflows, run tasks, private registries, team permissions, VCS-driven runs, cost estimation, and managed execution depending on edition. Terraform also works well with OPA/Conftest because the plan can be exported as JSON. A common pattern is: run plan, convert to JSON, evaluate policy, block unsafe changes, then allow apply only after approval.

Pulumi’s policy story is more language-native. Pulumi Policies can define guardrails in TypeScript, JavaScript, Python, or OPA. Pulumi’s docs describe preventative policies that block non-compliant stack updates and audit policies that scan discovered infrastructure, including resources created manually or with tools like Terraform or CloudFormation. That broader audit angle matters if your cloud estate is mixed.

For security teams, the comparison should focus on enforceability.

Pulumi has a notable secret-handling advantage in its transitive secret tracking model. Pulumi docs describe secrets as propagating through dependent values so derived outputs remain secret. Terraform has improved sensitive handling over the years, and modern Terraform also has ephemeral-resource patterns, but you still need to be extremely careful with state, plan artifacts, logs, and provider behavior.

For Terraform, the Terraform ephemeral resources pattern is worth understanding when secrets should not persist in state. For both tools, the real rule is the same: do not treat “sensitive” display masking as a complete secret-management strategy.

Pricing And Cost: The Spreadsheet Nobody Wants To Build

Tool pricing is not the same as platform cost.

Terraform CLI with self-managed state can look free. It is not free if you count the engineering time required to build secure remote state, CI execution, policy gates, private registries, drift checks, audit trails, SSO, access controls, and incident recovery. Still, for many capable teams, Terraform CLI plus cloud-native storage is an excellent low-cost model.

HCP Terraform moves those concerns into a managed service. The current docs say free organizations are limited to 500 managed resources. The HCP Terraform cost page defines managed resources as resources in HCP Terraform-managed state where mode equals managed, excluding null_resource and terraform_data. The example given for Essentials pay-as-you-go is 1,000 managed resources at $0.0001359 per resource-hour, or about $97.85/month for 24x7 usage over a 30-day month.

Pulumi Cloud uses its own resource and feature model. The pricing page lists Team at $40/month with 500 resources included and additional resources at $0.1825/month. Enterprise starts at $400/month with 2,000 resources included and additional resources starting at $0.365/month. Deployment workflow minutes and secrets have their own pricing details. Pricing pages change, so verify numbers before making a purchase decision, but the shape is clear: resource count matters.

The practical cost model should include:

A rough rule: if you already have mature Terraform operations, Pulumi must solve a specific productivity, platform API, or developer ownership problem to justify migration. If you are starting from scratch and building a developer platform where infrastructure provisioning is part of product workflows, Pulumi’s cost may be justified by reduced glue code and better developer experience.

Ecosystem: Terraform’s Gravity Versus Pulumi’s Bridge

Terraform’s ecosystem advantage is the strongest practical argument for Terraform. The provider count is huge. The module count is huge. Cloud vendors publish Terraform examples. Security tools parse Terraform. CI templates assume Terraform. Engineers know Terraform. Managed services support Terraform. Even tools that compete with Terraform often support Terraform first.

Pulumi has a different ecosystem story. It has native providers for major platforms, a registry of packages, and a bridge that can adapt Terraform providers. Pulumi’s Terraform comparison docs state that Pulumi can adapt any Terraform provider for use. The Pulumi Registry includes “Any Terraform” packages alongside native packages. Pulumi can also consume Terraform modules.

This bridge is powerful, but it does not erase the ecosystem gap. If you are using a bridged provider, your debugging path may include Pulumi, the bridge layer, the generated SDK, and the upstream Terraform provider. That does not make it bad. It means you should test provider behavior early, especially for less common services.

The ecosystem question should be answered per provider, not abstractly.

Terraform wins when ecosystem gravity is the deciding factor. Pulumi wins when the programming model unlocks a platform capability the Terraform ecosystem does not give you cheaply.

Platform Engineering Scenarios

Here are the scenarios where I would lean Terraform.

Use Terraform when the company needs a standardized IaC baseline across many teams. The platform team can publish modules, enforce policies, standardize pipelines, and make the safe path boring. This fits shared VPCs, EKS clusters, IAM baselines, account vending, database modules, DNS, and compliance-heavy infrastructure.

Use Terraform when hiring and maintainability beat expressiveness. If your infrastructure will be maintained by rotating SREs, consultants, cloud engineers, and application teams with mixed skill levels, HCL’s common vocabulary is an advantage.

Use Terraform when public modules and provider maturity dominate. If your architecture depends on well-known Terraform modules like AWS VPC, EKS, IAM, RDS, or CloudFront patterns, migration to Pulumi may add risk without enough return.

Use Terraform when the organization already has a strong Terraform and OpenTofu decision path. If the BSL license is a concern but the Terraform ecosystem is right, OpenTofu may be a more practical alternative than switching IaC models entirely.

Here are the scenarios where I would lean Pulumi.

Use Pulumi when infrastructure is part of a product-facing platform API. If you are building an internal developer platform where teams request environments, tenants, sandboxes, or customer-specific stacks through a portal, Pulumi Automation API is a serious advantage.

Use Pulumi when application code and infrastructure must be composed together carefully. Serverless apps, SaaS tenant provisioning, preview environments, data-platform workspaces, and feature environments often benefit from using the same language ecosystem as the application team.

Use Pulumi when you need stronger component abstraction than Terraform modules naturally provide. Components can represent product-level infrastructure concepts, not only cloud resources. That is useful when the platform team wants to expose “managed service environment” instead of 42 module variables.

Use Pulumi when the team can standardize on one or two languages and enforce code quality. Pulumi gets much weaker if every team writes a different style with no shared review discipline.

There is also a valid hybrid scenario. Keep Terraform for foundational infrastructure and use Pulumi for higher-level developer platform workflows. For example, Terraform manages accounts, VPCs, clusters, IAM guardrails, and shared databases. Pulumi provisions per-service or per-tenant resources through an internal API. That hybrid can work, but only if ownership and state boundaries are clean.

Migration: Do Not Rewrite Just To Rewrite

Most Terraform-to-Pulumi migrations are not worth doing if the only reason is “developers like Python better.” A mature Terraform estate contains years of operational knowledge: state files, module contracts, naming conventions, import decisions, drift history, policy exceptions, and incident scars. Rewriting that into Pulumi can create a prettier codebase with less production knowledge.

A better migration workflow is incremental.

1. Start with a new bounded use case. Pick preview environments, tenant provisioning, ephemeral test stacks, or a non-critical service. Do not start with the production network baseline.

2. Keep state boundaries clean. Do not have Terraform and Pulumi manage the same resource unless you are executing a planned import/ownership transfer.

3. Use outputs instead of shared ownership. If Pulumi needs a VPC ID created by Terraform, pass it through a controlled interface: remote state data, stack output, config, parameter store, or a platform inventory API. Do not let two tools fight over the VPC.

4. Test import paths. Pulumi can import existing resources and has conversion tooling, but imports should be rehearsed in lower environments. Terraform also has mature import and state-move workflows. Treat state migration as a change-management project.

5. Replicate policy before production. If Terraform currently blocks public S3 buckets, broad IAM, untagged resources, or database deletion, Pulumi must block the same class of change before it touches production.

6. Keep old Terraform modules alive until consumers move intentionally. Do not strand application teams mid-migration.

7. Document the rollback plan. Infrastructure migrations without rollback usually become long, tense weekends.

The opposite migration can also happen. A team may start with Pulumi and later move certain foundations to Terraform because hiring, audit, or module standardization becomes more important than language power. That is not failure. It is recognizing that foundational infrastructure and product-coupled infrastructure may need different operating models.

Common Paradoxes

The first paradox: Pulumi is more developer-friendly, but not always easier for an organization. A developer can write a clean Pulumi component quickly. An organization must maintain that component for years, teach it, review it, version it, and secure it.

The second paradox: Terraform is less expressive, but that can make it safer. HCL’s constraints reduce the number of strange patterns a team can invent. This is frustrating when you need abstraction. It is helpful when you need predictable reviews.

The third paradox: provider coverage can be both broader and blurrier in Pulumi. Pulumi can use many Terraform providers through bridging, which expands reach. But the debugging path can be more layered than using the Terraform provider directly.

The fourth paradox: managed platforms reduce operational burden and increase vendor dependency. HCP Terraform and Pulumi Cloud both solve real problems. They also move state, audit, policy, and workflow into a vendor relationship. That may be exactly right. It should be explicit.

The fifth paradox: code reuse can create infrastructure coupling. A shared Pulumi package or Terraform module can be a beautiful contract. It can also become a central bottleneck that forces every team to wait on the platform team. Design for versioning and compatibility from day one.

The sixth paradox: the best tool may be the one your team can operate boringly. IaC does not need to impress anyone. It needs to make the next production change safer.

A Practical Decision Matrix

Use this as the final review before making the decision.

If half the answers point one way and half the other, split by infrastructure layer:

The internal developer platform angle is important. If you are building with Backstage or another portal, the tool behind the button matters less than the contract exposed to developers. The Backstage platform engineering on AWS guide covers that broader pattern: the platform should expose paved roads, not raw cloud complexity.

My Recommendation

For most organizations in 2026, Terraform should remain the default IaC baseline unless there is a concrete reason to choose Pulumi.

That is not because Terraform is technically superior in every way. It is because defaults should optimize for survivability: hiring, searchability, predictable review, provider maturity, module ecosystem, policy patterns, and operational familiarity. Terraform’s ecosystem gravity is still enormous, and the Terraform/OpenTofu split gives teams an open-source-compatible path if licensing is the main concern.

Choose Pulumi when you can name the reason clearly:

The strongest Pulumi case is platform engineering. If the platform is becoming a product, and infrastructure provisioning needs to be embedded in APIs, portals, workflows, or custom CLIs, Pulumi is compelling. Its Automation API is not a small feature; it changes what IaC can be inside a larger system.

The strongest Terraform case is standardization. If the platform team wants a common language for cloud foundations, safe review workflows, known module patterns, and broad ecosystem support, Terraform remains hard to beat. Pair it with strong tests, OPA or Sentinel, remote state, pinned versions, and drift detection. Boring Terraform is better than clever Pulumi and better than clever Terraform.

The best answer may be boring at the foundation and expressive at the edge.

Sources

• Pulumi docs: What is Pulumi?
• Pulumi docs: state and backends
• Pulumi docs: Automation API concepts
• Pulumi docs: Policies
• Pulumi pricing
• Pulumi Registry
• Pulumi CLI versions
• Terraform documentation overview
• Terraform state documentation
• Terraform tests documentation
• HCP Terraform plans and features
• HCP Terraform cost estimate documentation
• Terraform Registry providers
• Terraform Registry modules
• HashiCorp Business Source License announcement
• Linux Foundation OpenTofu announcement