Snap CD vs Spacelift

Both Snap CD and Spacelift solve the same core problem: orchestrating Terraform deployments across multiple states with proper dependency management, approval workflows, and access control. They take notably different approaches to architecture, policy enforcement, and how much they expect you to change your existing Terraform workflows.

This guide walks through the key differences to help you decide which fits your team better.

Architecture

Spacelift is a fully managed SaaS platform. Your Terraform runs execute in Spacelift's cloud infrastructure by default. You can optionally deploy "private workers" inside your own network for runs that need access to internal resources, but the control plane always lives in Spacelift's environment.

Snap CD separates orchestration from execution. The control plane (snapcd.io) handles configuration, scheduling, and state tracking. The actual terraform plan and terraform apply commands run on Runners — lightweight agents you deploy wherever you need them (a Kubernetes pod, a VM, a container on your laptop). Runners connect back to the control plane via authenticated WebSocket connections.

The practical difference: with Spacelift, you send your code and credentials to their infrastructure (or set up private workers). With Snap CD, your code and credentials never leave your environment — the runner pulls jobs and pushes results, but the execution happens on machines you control.

Organising your infrastructure

Spacelift: stacks

Spacelift organises work into stacks. Each stack maps to a Terraform root module with its own state. You configure stacks with a source repo, branch, working directory, and environment variables. Stacks can be grouped into spaces for organisational purposes.

Dependencies between stacks are declared using stack dependencies — you specify that stack B depends on stack A, and Spacelift will trigger B after A completes. Output-to-input wiring is handled through output references that pass values between stacks.

Snap CD: modules in stacks and namespaces

Snap CD uses a three-level hierarchy: Stacks contain Namespaces, which contain Modules. A Module is analogous to a Spacelift stack — it points to a Terraform root module and manages one state file.

Dependencies are declared with snapcd_module_input_from_output resources:

resource "snapcd_module_input_from_output" "vpc_id" {
  module_id        = snapcd_module.compute.id
  input_kind       = "Param"
  name             = "vpc_id"
  output_module_id = snapcd_module.networking.id
  output_name      = "vpc_id"
}

When networking's outputs change, compute automatically re-plans. The dependency graph is explicit in code, not configured through a UI.

The Namespace layer lets you scope permissions and group related Modules. For example, prod/networking and prod/application can have different owners with different access levels, while both live under the prod Stack.

Policies and access control

Spacelift: OPA policies

Spacelift uses Open Policy Agent (OPA) for policy enforcement. You write Rego policies that evaluate against plan output, push events, or approval requirements:

• Plan policies inspect the Terraform plan and can warn, deny, or require additional approval.
• Push policies control which Git events trigger runs.
• Approval policies define who can approve a run and under what conditions.
• Access policies control who can see and interact with stacks.

This is powerful and flexible, but it means learning Rego and maintaining a separate policy codebase.

Snap CD: RBAC and approval gates

Snap CD uses a hierarchical role-based access control system. Roles (Owner, Contributor, Reader, Approver) are assigned to principals (users, service principals, groups) at any scope — organisation, Stack, Namespace, Module, or Runner.

Approval gates are configured per Module: you set the number of required approvals before an apply can proceed. Anyone with the Approver role at the Module's scope (or above) can approve.

There's no equivalent to OPA plan policies in Snap CD. If you need to inspect plan output and enforce rules programmatically, Spacelift's policy engine is more flexible. If your access control needs map to hierarchical roles and approval thresholds, Snap CD's model is simpler to set up and maintain.

Drift detection

Both platforms support drift detection — periodically running terraform plan to check whether actual infrastructure has diverged from the desired state.

Spacelift lets you configure drift detection per stack with a schedule. When drift is detected, it can automatically trigger a reconciliation run or notify you.

Snap CD offers configurable drift check intervals per Module. When drift is detected, a new plan is created and routed through the normal approval workflow before any changes are applied. The minimum interval is governed by your subscription tier.

The approaches are similar in practice. The main difference is that Spacelift can auto-reconcile without approval, while Snap CD always routes drift-triggered plans through approval gates.

Runner and worker model

Spacelift runs Terraform in its own cloud by default. For access to private networks, you deploy private workers — Docker containers that poll Spacelift for jobs. Workers need outbound HTTPS access to Spacelift's API. You can configure worker pools and assign stacks to specific pools.

Snap CD Runners are self-hosted by design — there is no managed execution environment. Runners connect to snapcd.io via authenticated, bi-directional WebSocket connections. You control where they run, what credentials they have, and which Modules can use them (via RBAC on the Runner resource).

The Runner is source-available and maintained as part of the Snap CD monorepo, so you can inspect exactly what it does or build custom images.

If you prefer a fully managed environment where you don't operate any infrastructure for running Terraform, Spacelift's default execution model is simpler. If you want full control over the execution environment and credentials, Snap CD's runner model gives you that without the complexity of setting up private workers.

Non-invasive vs integrated

Spacelift integrates into your workflow in several ways. It injects spacelift.auto.tfvars into your Terraform runs, uses its own state backend, and provides features like spacelift_environment data sources that reference Spacelift-specific concepts. Your Terraform code doesn't need to change, but the execution context is Spacelift-specific.

Snap CD takes a non-invasive approach. When a Runner picks up a job, it clones your repo and runs standard terraform init, terraform plan, and terraform apply in a shell session. Inputs are provided via standard .tfvars files and environment variables. Your Terraform code has no Snap CD-specific constructs — you can run the same code with terraform apply on your laptop.

You can SSH into a Snap CD Runner, navigate to the working directory, and execute commands manually. Nothing is hidden behind abstractions.

Managing the platform with Terraform

Both platforms provide Terraform providers for managing their own configuration as code.

Spacelift has the spacelift provider, which lets you define stacks, policies, contexts, and integrations in Terraform.

Snap CD has the snapcd provider (Terraform Registry), covering stacks, namespaces, modules, runners, role assignments, and dependency wiring. Snap CD also supports a "module-within-module" pattern where a Snap CD module can deploy additional Snap CD modules.

Pricing

Spacelift prices by the number of workers (concurrent execution slots) and the feature tier. The free tier includes one worker. Additional workers and features like private workers, SSO, and audit logs come with paid plans.

Snap CD prices based on usage — modules managed, users, and module jobs. There is no per-runner cost; you can deploy as many runners as you need. The pricing is consumption-based rather than seat-based.

Comparison table

When to choose which

Spacelift may be a better fit if:

• You want a fully managed execution environment and prefer not to operate runners.
• You need fine-grained policy enforcement with OPA/Rego.
• Auto-remediation of drift without human approval is important to your workflow.
• You're already using OPA elsewhere and want to reuse that expertise.

Snap CD may be a better fit if:

• You need full control over where Terraform runs and what credentials it can access.
• You want your Terraform code to remain completely portable — no platform-specific constructs.
• Your access control maps well to hierarchical roles scoped to Stacks, Namespaces, and Modules.
• You want to inspect or customise the Runner (it's source-available).
• You prefer consumption-based pricing over per-worker pricing.

See also

• Modular Deployments — deep dive into Snap CD's Module, input, and dependency system
• Self-Hosted Terraform Runners with Credential Isolation — how Runners keep credentials in your environment
• Non-invasive Orchestration — how Snap CD runs standard Terraform commands without wrappers
• A Permission System Built for Infrastructure — hierarchical RBAC vs OPA policy engines