Pulumi

License	FOSS problems	Maintenance	SSO	Users	Tested
Apache-2.0Permissive license. Like MIT, but each contributor grants users a patent licence covering their contribution, preventing later suits.	—	Active	—	Unlimited	❌

Description

Pulumi is infrastructure as code written in a general-purpose language — TypeScript, Python, Go, C#, Java — instead of a dedicated config format like Terraform/OpenTofu's HCL. A Pulumi program imports the SDK plus provider packages (@pulumi/aws, @pulumi/kubernetes, and so on) and instantiates resources as objects; running it sends those resource registrations to Pulumi's engine over gRPC, which builds the desired-state graph, diffs it against tracked state, and computes a plan — the same conceptual shape as terraform plan, just arrived at by executing code rather than parsing a static file.

Features

• Real language, not a DSL — actual loops and conditionals instead of for_each/count/dynamic workarounds, functions and classes for genuine reuse, the normal package manager and test framework for whatever language is in use, full IDE support (autocomplete, type-checking) on the infrastructure code itself.
• Inherited provider ecosystem — many providers are auto-generated wrappers around actual Terraform providers, so it inherits Terraform's coverage rather than reimplementing every cloud API from scratch; some providers are Pulumi-native.
• Drift detection — pulumi refresh diffs declared state against actual reality; not unique to Pulumi, OpenTofu has the same capability under a different name. The CLI does this on demand either way; Pulumi Cloud can additionally run it on a schedule with alerting or auto-remediation.
• Secrets encryption — config and state secrets are encrypted by default; not Cloud-only, the encryption key can come from Pulumi Cloud (automatic, per-stack), a local passphrase (PULUMI_CONFIG_PASSPHRASE, no Cloud dependency), or your own KMS (AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault).
• Policy as code, RBAC, audit logs — org-scale governance features, primarily a Pulumi Cloud concern.

Example usage

The same OpenStack instance and boot volume as OpenTofu's example, in TypeScript — a real loop where HCL would need for_each:

import * as openstack from "@pulumi/openstack";

const keypair = new openstack.compute.Keypair("main", {
  publicKey: process.env.SSH_PUBLIC_KEY!,
});

const bootVolume = new openstack.blockstorage.Volume("personal-services-boot", {
  size: 20,
  volumeType: "CEPH_1_perf1",
});

const instance = new openstack.compute.Instance("personal-services", {
  flavorName: "a4-ram16-disk0",
  keyPair: keypair.name,
  blockDevices: [{
    uuid: bootVolume.id,
    sourceType: "volume",
    destinationType: "volume",
    bootIndex: 0,
  }],
});

pulumi up runs this program, diffs the resulting resource graph against tracked state, and applies the difference — same outcome as terraform apply against the equivalent .tf file.

Usage patterns

• Standalone — a full replacement for Terraform/OpenTofu, infrastructure defined entirely in one general-purpose language.
• Self-managed backend — state in S3, Azure Blob, GCS, an S3-compatible server (Minio, Ceph), Postgres, or a local file, with zero Pulumi Cloud dependency — the same shape this project already uses for Terraform state; secrets encrypted via a local passphrase or your own KMS rather than Pulumi Cloud's managed keys.
• Pulumi Cloud — for teams that want scheduled drift detection, RBAC, and audit logs without building that tooling themselves.

License and governance

Genuinely open-core, but the mild version — closer to Coolify's shape than the bait-and-switch pattern elsewhere in this catalog (Dockhand, Outline). The CLI and SDKs are Apache 2.0, and the actual IaC engine — plan, apply, state — is never gated; self-managed backends work with zero Cloud dependency. What's Cloud-only is the productised layer on top: scheduled drift detection with alerting, RBAC, audit logs, org-wide policy management — behind a free Individual tier (500 deployment minutes, 25 secrets, unlimited stacks, single user) and paid tiers above that.

Against OpenTofu specifically, there's a governance gap that the license alone doesn't close. OpenTofu is Linux Foundation-governed, multiple competing companies on the steering committee, specifically so no single company can unilaterally relicense it — the exact thing HashiCorp did to Terraform. Pulumi is one company, VC-backed. Apache 2.0 protects code already released, but that's the same protection Terraform's MPL 2.0 code had, and it didn't stop the license changing going forward. Choosing Pulumi over OpenTofu trades away the specific governance property this project has otherwise prioritised.

Conclusion

Why you would — real language features once HCL's expression language starts to strain: loops, functions, IDE tooling. Secrets handling is also more mature than OpenTofu's — built-in encryption for both config and state, not just the state file, with a choice of key source going back further than OpenTofu's own state encryption (added in v1.7).

Why you wouldn't — a language runtime is one more moving part a declarative tool doesn't have, and code that loops and branches can be non-deterministic in ways a static file can't. Its provider ecosystem is a bridged wrapper around Terraform's own, not an independent one. And this project already has working Terraform config — moving to OpenTofu is close to a rename, moving to Pulumi means rewriting from scratch, for infrastructure that doesn't come close to where HCL's limits would start to bite.