Terraform has been the default answer to "how do I manage cloud infrastructure as code" for most of the past decade. It works, it's widely understood, and the provider ecosystem is enormous. But it has real limitations — HCL is a constrained DSL, the state file is a perpetual source of pain, and the 2023 BSL license change introduced commercial uncertainty that still hasn't fully settled.
Pulumi takes a fundamentally different approach. Instead of learning a new configuration language, you write infrastructure in the programming language your team already uses. TypeScript, Python, Go, C#, Java — real languages with real loops, conditionals, functions, classes, unit tests, and IDE support. The question isn't whether this approach is interesting — it clearly is. The question is whether the trade-offs make sense for your situation.
What Pulumi is
Pulumi is an open-source Infrastructure as Code platform that uses general-purpose programming languages to define cloud resources. Under the hood it works similarly to Terraform — it maintains a state file, computes a diff between desired and actual state, and makes API calls to provision or update resources. The key difference is the interface: instead of writing HCL, you write code in a language you already know.
It supports all major cloud providers — AWS, Azure, GCP, Kubernetes — plus a wide range of SaaS tools. Pulumi bridges to Terraform providers via the Terraform Bridge, meaning most Terraform providers work in Pulumi too, which partially closes the ecosystem gap.
Pulumi is Apache 2.0 licensed for the open-source CLI and SDKs. Pulumi Cloud (state management as a service) has a free tier for individual use and paid tiers for teams.
The core idea: infrastructure as software
The philosophical difference between Pulumi and Terraform is significant. Terraform treats infrastructure as configuration — you declare what you want, HCL expresses it, and Terraform figures out the steps. Pulumi treats infrastructure as software — you write code that produces infrastructure, using the same tools, patterns, and practices you use for application code.
What this unlocks in practice:
- Real abstractions — write a function that creates a standard VPC with your organization's conventions, call it from multiple stacks, and update it in one place. In Terraform this requires modules with all their friction. In Pulumi it's just a function or class.
- Real loops — create 10 similar resources with a for loop. Terraform's
countandfor_eachwork but feel bolted-on. Pulumi's loops are just loops. - Unit testing — write tests for your infrastructure logic using your language's existing test framework. Jest, pytest, Go testing — whichever you already use. Testing Terraform requires external tools like Terratest.
- IDE support — autocompletion, type checking, refactoring, jump to definition. Your editor understands your infrastructure code the same way it understands your application code.
- Package management — share infrastructure components via npm, PyPI, or Go modules. Versioned, published, reusable.
Supported languages
Pulumi supports TypeScript/JavaScript, Python, Go, C#/.NET, Java, and YAML. In practice most teams pick TypeScript or Python — TypeScript for the type safety and IDE experience, Python for teams already heavy on Python automation.
A basic S3 bucket in Python:
import pulumi
import pulumi_aws as aws
bucket = aws.s3.Bucket("my-bucket",
bucket="my-company-data",
acl="private",
versioning=aws.s3.BucketVersioningArgs(
enabled=True,
),
tags={
"Environment": "production",
"Team": "platform",
}
)
pulumi.export("bucket_name", bucket.id)
pulumi.export("bucket_arn", bucket.arn)The same in TypeScript:
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
const bucket = new aws.s3.Bucket("my-bucket", {
bucket: "my-company-data",
acl: "private",
versioning: {
enabled: true,
},
tags: {
Environment: "production",
Team: "platform",
},
});
export const bucketName = bucket.id;
export const bucketArn = bucket.arn;State management
Pulumi needs to store state somewhere, just like Terraform. Your options:
- Pulumi Cloud — the default. Free for individuals, paid for teams. Includes state history, secrets encryption, audit logs, and team access controls. No setup required.
- AWS S3 / Azure Blob / GCP GCS — self-managed state backend, similar to Terraform's S3 backend. You own the data, you manage the access.
- Local filesystem — fine for experimentation, not for production.
Pulumi Cloud is significantly more polished than Terraform's remote state story out of the box. The web console shows deployment history, resource graphs, drift detection, and policy violations in a clean UI. If you're currently managing Terraform state in S3 with a DynamoDB lock table, Pulumi Cloud is a notable quality-of-life improvement.
Secrets handling
Pulumi has built-in secrets management. Mark any value as a secret and Pulumi encrypts it in the state file automatically — no separate external secret storage required for basic use cases. The encryption key can be managed by Pulumi Cloud, by a cloud KMS (AWS KMS, Azure Key Vault, GCP KMS), or by a passphrase.
# Mark a value as secret
pulumi config set --secret database_password "supersecret"
# Use it in code
const dbPassword = config.requireSecret("database_password");In Terraform, you're expected to handle secrets externally (AWS Secrets Manager, Vault, etc.) and reference them. Both approaches are valid, but Pulumi's built-in handling reduces setup for common cases.
Pulumi AI and Copilot
Pulumi has leaned heavily into AI-assisted infrastructure in 2025-2026. Pulumi AI can generate Pulumi programs from natural language descriptions. Pulumi Copilot in the cloud console answers questions about your infrastructure, helps diagnose deployment failures, and suggests fixes. For teams newer to cloud infrastructure, this lowers the barrier to getting started.
Pulumi vs Terraform: the honest comparison
Provider ecosystem: Terraform's registry lists over 4,800 providers. Pulumi's registry lists approximately 1,800 providers — though the Terraform Bridge means most Terraform providers are usable in Pulumi. For niche services, Terraform wins on native provider coverage.
Learning curve: Terraform is easier to start with for non-developers. HCL is simple, readable, and purpose-built for the task. Pulumi requires understanding your chosen language, the Pulumi SDK, and how async resource creation works in code. For developer teams, this isn't a barrier. For ops-focused teams, it can be.
Complexity handling: Pulumi wins clearly for complex infrastructure. Dynamic resource counts, conditional resource creation, and reusable abstractions are significantly cleaner in a real programming language than in HCL.
Testing: Pulumi has a real unit testing story. Terraform requires external tools. For teams with mature software engineering practices, this matters.
Community and talent: Terraform commands roughly 76% of the IaC market, Pulumi is growing at 45% year-over-year among developer-focused teams. Finding Terraform expertise is easier — more tutorials, more Stack Overflow answers, more engineers who already know it.
License: Pulumi CLI and SDKs are Apache 2.0. Pulumi Cloud is commercial. Terraform is BSL 1.1 (with OpenTofu as the MIT-licensed fork). For self-hosted teams, Pulumi is actually more permissively licensed than current Terraform.
Performance: Pulumi 4.0+ introduced Incremental State Processing, reducing deployment times by 60% for large-scale infrastructures of 1000+ resources — a meaningful improvement for organizations managing large environments.
Migrating from Terraform
Pulumi provides a pulumi convert command that converts Terraform HCL to Pulumi code in your chosen language. It's not perfect — complex modules and edge cases require manual cleanup — but it handles the majority of common patterns. For teams sitting on a large Terraform codebase, migration is a real investment, not a weekend project.
# Convert existing Terraform code to Python
pulumi convert --from terraform --language python --out ./pulumi-infraWhen to choose Pulumi
Pulumi is the better choice when:
- Your infrastructure team is developer-led and already writes TypeScript or Python
- You need complex logic — dynamic resource generation, conditional infrastructure, reusable components across multiple projects
- You want proper unit testing for infrastructure code
- You're starting fresh and don't have an existing Terraform investment
- The BSL license is a concern and OpenTofu isn't a sufficient answer
Stick with Terraform/OpenTofu when:
- Your team is ops-focused and comfortable with HCL
- You have a large existing Terraform codebase
- You need the broadest possible provider coverage without any bridging
- Your organization needs to hire IaC engineers — Terraform skills are easier to find
- Simplicity and readability for mixed-skill teams matters more than programming language flexibility
My take
Pulumi makes infrastructure feel like software development, and for teams that think that way, it's genuinely better than Terraform for complex use cases. The ability to write real abstractions, test infrastructure logic, and use existing package ecosystems is not a gimmick — it solves real problems that come up when you're managing infrastructure at scale.
The trade-offs are real too. Smaller native provider ecosystem, harder to hire for, and a steeper learning curve for non-developers. For teams already managing significant Terraform infrastructure, migration is a substantial investment with uncertain ROI unless you're hitting Terraform's limitations regularly.
My recommendation: if you're starting a new infrastructure project and your team writes Python or TypeScript daily, seriously evaluate Pulumi before defaulting to Terraform. If you have existing Terraform that's working, OpenTofu is probably the lower-friction path for addressing the license concern. Pulumi is worth the migration cost when you're regularly fighting HCL's limitations — not before.
Need help with infrastructure as code?
Whether you're evaluating Pulumi, migrating from Terraform, or building infrastructure pipelines from scratch — Pipoline handles IaC setup and consulting. Get in touch and we'll figure out what makes sense for your stack.

Member discussion