Pulumi

What it is

Pulumi is an infrastructure-as-code tool that lets you define cloud resources using general-purpose programming languages — TypeScript, Python, Go, C#, Java, and YAML — instead of a domain-specific templating language. It compiles down to a resource graph and manages state the same way Terraform does, but the authoring experience is closer to writing application code: loops, functions, classes, package managers, and IDE autocomplete all work as expected. It supports AWS, Azure, GCP, Kubernetes, and a long list of other providers, plus a growing set of "Pulumi Crosswalk" and Automation API patterns for embedding provisioning logic directly into custom tooling.

Who builds it and why

Pulumi is developed by Pulumi Corporation, a VC-backed company that sells a hosted state/collaboration layer (Pulumi Cloud) on top of the open-source engine. The open-core model means the CLI, providers, and SDKs are Apache-2.0 and fully usable without paying anything, while the company monetizes team features — state locking, RBAC, policy enforcement, audit logs, and CI/CD integration — through its cloud product. This is the same commercial pattern as HashiCorp's pre-license-change Terraform: give away the engine, sell the control plane.

Production readiness signal

The GitHub numbers are solid for a tool at this stage: 25,376 stars, 385 contributors, and a recent commit history extending into mid-2026 indicates active, ongoing maintenance rather than a project coasting on inertia. A release cadence that's reached v3.248.0 tells you this project ships frequently — that's a lot of point releases, which is typical for a provider-heavy IaC tool where every cloud API surface change needs a corresponding SDK update. Apache-2.0 licensing removes the legal ambiguity that's plagued some competitors. CNCF maturity level is not publicly available — Pulumi is not currently a CNCF-hosted project, so don't expect graduation/incubation signaling here; you're relying on vendor health and community activity instead.

Who should use this

Teams that are already polyglot on the application side and want their infrastructure code to live in the same language, same test framework, and same CI pipeline as their app code. If you're tired of HCL's limitations — no real loops without workarounds, weak abstraction, clunky conditionals — and you want actual unit tests around your infra logic, Pulumi's programming-language-native approach is a legitimate upgrade. Also a good fit for platform teams building internal developer platforms who want to expose provisioning as a library/API (Automation API) rather than a CLI wrapper.

Who should NOT use this

If your team is HCL-fluent, has a mature Terraform module library, and isn't feeling real pain — don't switch just because "real languages" sounds appealing. Migration cost is nontrivial and Terraform's state ecosystem, provider maturity, and hiring pool are still larger. If you need a tool with formal CNCF governance backing for procurement/compliance reasons, Pulumi doesn't currently offer that story. Also skip it if your org wants to minimize the number of languages platform engineers must know — Pulumi's flexibility means five different teams may write infra code in five different styles, which becomes a maintenance headache without strong internal conventions enforced from day one.

Alternatives

• Terraform (OpenTofu) — the incumbent DSL-based approach; larger provider ecosystem and community, HCL instead of general-purpose languages.
• AWS CDK / CDKTF — similar "real code" philosophy but CDK is AWS-native only, while CDKTF layers the same idea onto Terraform's provider ecosystem.
• Crossplane — Kubernetes-native, control-loop-based provisioning; better fit if your provisioning model is already GitOps/Kubernetes-centric rather than CLI-run.

Pricing

The core engine, CLI, SDKs, and providers are fully open source under Apache-2.0 — no functional gate. Pulumi Cloud (state management, team collaboration, policy-as-code, deployment automation) is a paid SaaS with a free tier for individuals/small teams; self-hosted state backends (S3, GCS, Azure Blob, local) are supported if you want to avoid the SaaS entirely and pay nothing.