Pulumi vs. Spacelift

Pulumi and Spacelift sit at different layers of the infrastructure stack. Pulumi is an infrastructure as code platform: you define infrastructure in general-purpose languages (Python, TypeScript, JavaScript, Go, C#, Java, or YAML), and Pulumi Cloud and Pulumi Deployments manage state, enforce policy, and run deployments. Spacelift is a CI/CD and orchestration platform for infrastructure as code: it doesn’t author infrastructure itself, but runs and manages the IaC tools you already use — including Pulumi, Terraform, OpenTofu, CloudFormation, Ansible, and Kubernetes — from a single control plane.

Because Spacelift runs Pulumi as a first-class runtime, the two are frequently used together. Where they genuinely overlap is the management layer: Spacelift’s orchestration, policy, and collaboration features cover much the same ground as Pulumi Cloud and Pulumi Deployments. This page covers what each tool is, a feature-by-feature comparison, the key differences in detail, and how Pulumi and Spacelift work together.

What is Pulumi?

Pulumi is an infrastructure as code platform for provisioning and managing resources across any cloud or SaaS platform. Pulumi programs are written in general-purpose programming languages — Python, TypeScript, JavaScript, Go, .NET, and Java — as well as YAML. The Pulumi Registry covers all major clouds, including first-party native providers that are generated from upstream API schemas for same-day coverage of new platform features. The Pulumi CLI and SDKs are open source under the Apache 2.0 license. Pulumi Cloud is the commercial product that adds managed state, secrets, RBAC, audit logs, policy management, and other features for running Pulumi at organizational scale.

For teams coming from Spacelift, the closest points of comparison are Pulumi Cloud and Pulumi Deployments. Together they provide managed state, role-based access control, policy enforcement, drift detection, and remote, Git-driven runs, forming a management layer built for infrastructure you author with Pulumi. Pulumi’s engine is open source and runs anywhere, so you can also drive it from any CI/CD system, Spacelift included.

What is Spacelift?

Spacelift is a commercial CI/CD and orchestration platform for infrastructure as code. It runs the IaC tools you already use and wraps a management layer around them: version-control integration, policy enforcement, access control, and continuous drift detection. Spacelift supports Terraform, OpenTofu, Terragrunt, Pulumi, AWS CloudFormation, Kubernetes, and Ansible as run backends, so an organization can manage a heterogeneous mix of tools from one control plane.

Work in Spacelift is organized into stacks — each a combination of source code, state, and configuration tied to a Git repository — that execute runs when changes are pushed. Runs execute on worker pools: a public pool hosted by Spacelift, or private workers you operate in your own cloud account for tighter control over credentials and network access. Governance is handled through policies written in Open Policy Agent’s Rego language, which Spacelift evaluates at distinct decision points across a run’s lifecycle, from login and stack access to plan approval and notification routing.

Spacelift is proprietary software, though it’s built on open-source components such as Open Policy Agent and Docker. It’s delivered primarily as a hosted SaaS product, with self-hosted and airgapped options on its highest tier. Pricing starts with a free tier of two users and one public worker, then moves up through annual subscription plans for larger teams.

Detailed comparison

Key differences

Two layers: an infrastructure as code platform and an orchestration platform

Pulumi and Spacelift come at infrastructure from opposite ends. Pulumi is an infrastructure as code platform: it’s where infrastructure is authored, in a general-purpose language, and it ships with a management layer — Pulumi Cloud and Pulumi Deployments — for state, policy, access control, and remote runs. Spacelift’s core job is orchestration: it runs infrastructure you’ve written in another tool and adds governance and collaboration on top. In the landscape of infrastructure tooling, Spacelift sits alongside offerings like Terraform Cloud: a management plane for infrastructure code more than the code itself.

A like-for-like comparison, then, is less “Pulumi vs. Spacelift” than “Pulumi Cloud and Pulumi Deployments vs. Spacelift.” And because Spacelift runs Pulumi as one of its supported tools, the most common outcome is teams using them together, authoring with Pulumi and orchestrating with Spacelift.

Infrastructure authoring and language support

Pulumi programs are written in general-purpose languages, so you get loops, conditionals, classes, package management, IDE support, and the testing frameworks that already exist in those ecosystems, along with YAML for teams who prefer a markup format. Spacelift has no authoring model of its own; what you write depends on the tool you run on it. If that tool is Terraform, you write HCL; if it’s Pulumi, you write a Pulumi program and keep every one of Pulumi’s language features. When the question is really about how infrastructure is expressed, then, the comparison is between Pulumi and whichever tool you’d otherwise run, not between Pulumi and Spacelift, which is happy to run Pulumi.

Execution model, GitOps, and drift

Both platforms give you managed, Git-driven runs, and they reach a similar experience from opposite directions. Spacelift is built around version control: a push opens a proposed run that previews changes on a pull request, and a merge triggers a tracked run that applies them, all executed on public or private worker pools. Pulumi Deployments offers the same shape for Pulumi specifically: remote runs triggered by Git, review stacks that stand up an ephemeral environment per pull request, scheduled deployments, and time-to-live stacks, all running on Pulumi-hosted or self-hosted runners. Both detect drift on a schedule and can remediate it: Pulumi Deployments and Spacelift each run a periodic check and, where configured, open a run to reconcile. The practical difference is scope. Pulumi Deployments is purpose-built for Pulumi, while Spacelift applies one execution model across every tool it supports.

State and secrets

Pulumi manages state in Pulumi Cloud by default, or in a self-managed backend such as Amazon S3, Azure Blob Storage, or Google Cloud Storage, and it treats secrets as a first-class primitive: values marked secret are encrypted in transit and at rest, with per-stack encryption keys and pluggable KMS providers. Pulumi ESC extends this into centralized secrets and configuration shared across stacks and environments.

Spacelift provides a managed state backend too, but only for Terraform and OpenTofu. For Pulumi, Spacelift runs pulumi login against a backend you configure, which means your Pulumi state still lives in Pulumi Cloud or your own self-managed backend even when Spacelift orchestrates the run. Spacelift secures its own configuration and credentials with encrypted environment variables and contexts. The upshot is that adopting Spacelift for orchestration doesn’t move your Pulumi state off Pulumi’s backends; the two responsibilities stay cleanly separated.

Policy as code and governance

Pulumi Policies runs as part of pulumi preview and pulumi up, and policies can be written in Python, TypeScript, or Open Policy Agent Rego. It’s open source and free, and Pulumi Cloud adds centralized management, policy groups, and pre-built compliance packs for frameworks like CIS, HITRUST, NIST, and PCI DSS. Spacelift also builds on Open Policy Agent, but takes a broader, orchestration-oriented view: Rego policies run at distinct points in a run’s lifecycle — who can log in, who can access a stack, whether a plan is approved, how a Git push is interpreted, and how notifications are routed. Because Pulumi Policies run inside the deployment itself, they apply on Spacelift too; Pulumi’s enforcement and compliance packs stay in force even when Spacelift orchestrates the run. The two operate at different scopes: Pulumi Policies govern Pulumi deployments, while Spacelift’s Rego policies govern the whole run lifecycle across every tool it orchestrates.

Building platforms programmatically

Pulumi’s Automation API lets a host application drive Pulumi directly, without shelling out to the CLI, which is useful for embedding provisioning in a SaaS product, building an internal developer platform, or generating preview environments from CI. It puts the IaC engine inside your software. Spacelift exposes a GraphQL API, a spacectl CLI, and a Terraform/OpenTofu provider for managing Spacelift objects like stacks and policies. The difference is one of altitude: the Automation API embeds infrastructure provisioning in your own code, while Spacelift’s API automates the orchestration platform that runs your infrastructure tools.

AI and agents

Both platforms have moved into AI-assisted infrastructure from different starting points. Spacelift’s Intelligence layer comprises an assistant that answers questions about your estate; Intent, which provisions from natural language by calling cloud provider APIs directly, bypassing Terraform/OpenTofu entirely; and a hosted MCP server that applies Spacelift’s policies and access controls to AI coding tools like Claude Code and Codex. Pulumi comes at it from the authoring side: because infrastructure lives in general-purpose languages, the coding agents your team already uses can read and change it directly through Agent Skills and the Pulumi MCP server, and Pulumi Neo is a purpose-built infrastructure agent for deeper, governed automation. Use your own agent, use Neo, or use both. Either way, both keep humans and policy in the loop, and the split mirrors the rest of this comparison: Spacelift governs AI-driven changes to the tools it orchestrates, while Pulumi brings AI to authoring and managing infrastructure as code.

Using Pulumi and Spacelift together

Because Spacelift treats Pulumi as a first-class runtime, running the two together is a supported, documented path rather than a workaround. Spacelift’s Pulumi integration runs the Pulumi CLI directly, so your Pulumi programs behave as they do anywhere the CLI runs. On each run it executes pulumi login against your backend, selects your stack, and runs pulumi preview and pulumi up with refresh and diff enabled. Plan policies receive the Pulumi plan as structured input, and Pulumi secrets are redacted as [secret] rather than shown in plaintext. A couple of Pulumi features are limited under Spacelift today: module CI/CD isn’t available, and pulumi import isn’t supported, so you import resources with tasks instead. For teams that would rather not operate a separate orchestration platform, Pulumi Deployments provides the same Git-driven runs, drift detection, and review environments as an integrated part of Pulumi.

When to use Pulumi or Spacelift

These aren’t mutually exclusive. Pulumi authors infrastructure and manages it, so it works as a complete platform on its own. Spacelift runs Pulumi as a first-class tool, so the two pair cleanly: author in Pulumi and orchestrate through Spacelift. They overlap at the management layer, where Pulumi Cloud and Pulumi Deployments cover the same ground Spacelift does for the tools it runs.

Lead with Pulumi (with Pulumi Cloud and Pulumi Deployments) when you:

1. Want a single platform that both authors and manages infrastructure, without operating a separate orchestration tool.
2. Are standardizing on Pulumi and want a management layer built for it — managed state, first-class encrypted secrets, Pulumi ESC, review stacks, and drift detection.
3. Need an embeddable SDK, the Automation API, to drive provisioning from your own application or internal developer platform.
4. Prefer policy authored in the same general-purpose languages as your infrastructure.
5. Want an open-source engine you can run anywhere, on any CI/CD system.

Reach for Spacelift alongside Pulumi when you:

1. Run a heterogeneous estate of IaC tools — Terraform, Pulumi, CloudFormation, and Ansible side by side — and want one orchestration plane across all of them, with Pulumi running next to the rest.
2. Have already standardized on Spacelift and want to keep its worker pools, Rego policies, and run workflow while authoring in Pulumi.

Whichever way you run it, Pulumi is where infrastructure is authored and managed; Spacelift or Pulumi Deployments handles the orchestration.

Adoption: using Pulumi with Spacelift

You can adopt Pulumi alongside or in place of Spacelift in a few common ways, and they can be combined:

1. Run Pulumi on Spacelift. Configure a Spacelift stack with the Pulumi vendor, point it at your Pulumi backend, and Spacelift orchestrates pulumi preview and pulumi up on every change while your state stays in Pulumi Cloud or your own backend. This lets a team keep authoring in Pulumi while running a mixed-tool estate through one control plane.
2. Standardize on Pulumi Cloud and Pulumi Deployments. If you’d rather not operate a separate orchestration platform, Pulumi Deployments provides remote runs, drift detection, review stacks, and Git-driven deploys as an integrated part of Pulumi.
3. Bring a Terraform estate on Spacelift into Pulumi. If much of your Spacelift estate is Terraform, Pulumi can embrace it rather than replace it — use existing Terraform modules, work with any Terraform or OpenTofu provider, and convert HCL with pulumi convert --from terraform — while pulumi import brings already-provisioned resources under management. You can keep orchestrating with Spacelift or move those workloads to Pulumi Deployments.

Frequently asked questions

Is Spacelift an infrastructure as code tool?

No. Spacelift is an orchestration and CI/CD platform for infrastructure as code, not an IaC language or framework of its own; it runs the IaC tools you author with — Pulumi, Terraform, OpenTofu, CloudFormation, Ansible, and Kubernetes — and adds state, policy, access control, and drift detection around them.

Can Pulumi run on Spacelift?

Yes. Spacelift runs Pulumi as a first-class vendor, invoking the Pulumi CLI on its workers. On each run it executes pulumi login against your configured backend, then pulumi preview and pulumi up with refresh and diff. Two Pulumi-specific features are limited: module CI/CD isn’t available, and pulumi import isn’t supported, so you import resources with tasks instead. See Spacelift’s Pulumi documentation for details.

Does Spacelift replace Pulumi?

No — the two work together at different layers. You author infrastructure with Pulumi, and Spacelift orchestrates the runs. Where Spacelift overlaps with Pulumi is the management layer, Pulumi Cloud and Pulumi Deployments, not Pulumi’s authoring engine.

If you run Terraform on Spacelift, should you consider Pulumi?

Often, yes. Teams frequently adopt Spacelift to add collaboration and governance on top of Terraform. Pulumi offers a different path: rather than orchestrating Terraform in place, you can bring that Terraform investment into a general-purpose IaC platform with an integrated management layer. Pulumi uses existing Terraform modules directly, works with any Terraform or OpenTofu provider, and converts your HCL with pulumi convert --from terraform, so your existing work carries forward. For a team weighing how to evolve its Terraform estate, that’s often a stronger long-term move than adding an orchestration layer on top of it.

Does Spacelift manage Pulumi state?

No. Spacelift offers a managed state backend for Terraform and OpenTofu, but for Pulumi you bring your own backend. Spacelift runs pulumi login against the backend you configure, so Pulumi state continues to live in Pulumi Cloud or a self-managed backend — Amazon S3, Azure Blob Storage, Google Cloud Storage, or a local file — even when Spacelift orchestrates the run.

Is Spacelift open source like Pulumi?

No. Pulumi’s CLI, SDKs, and providers are open source under Apache 2.0, and Pulumi Cloud is the commercial offering, with a free Individual tier and paid plans. Spacelift is proprietary, commercial software; it’s built on open-source components like Open Policy Agent and Docker, but it isn’t an open-source product itself.

Next steps

• Get started with Pulumi
• Pulumi Deployments
• Pulumi Cloud
• Pulumi vs. Terraform