Why Snap CD: An Extensive Supporting Toolset

Karl Schriek·March 15, 2026

A deployment tool can have a brilliant core and still fail adoption. The team evaluates it, likes the concept, runs through the getting-started guide — and then hits a wall. The docs stop at "hello world." There's no way to manage the tool's own configuration as code. The example repo was last updated eighteen months ago. The deployment instructions are a paragraph in a README that starts with "something like."

Adoption doesn't stall because the tool is bad. It stalls because everything around the tool is incomplete.

Snap CD ships with a full supporting ecosystem specifically to avoid this. This article walks through what's available and why each piece matters.

The adoption surface

Think of a deployment tool's adoption surface as everything a team needs beyond the core product to go from "this looks interesting" to "this is running in production and we're confident in it." That surface typically includes:

Documentation — not just tutorials, but concept explanations, API references, and advanced patterns.
Infrastructure-as-code support — the ability to manage the tool's configuration the same way you manage everything else.
Deployment artifacts — container images, manifests, and compose files so you're not reverse-engineering how to run the thing.
Examples — realistic patterns that go beyond a single-resource demo.
Source access — the ability to read the code, understand what it does, and extend it if needed.

Most tools cover one or two of these well and leave the rest as an exercise for the reader. Snap CD covers all five.

Documentation

The documentation site at docs.snapcd.io is structured around three layers:

Getting started. A quickstart guide that takes you from zero to a working deployment in minutes. It covers installing the Runner, connecting it to the Snap CD Server, creating your first Stack, and deploying a Module.

Concepts. Detailed explanations of every core concept — Stacks, Namespaces, Modules, Runners, sources, inputs, outputs, approvals, and the permission model. These aren't just glossary entries. Each concept page explains what the object is, how it relates to other objects, and the design decisions behind it.

API reference. Every API endpoint is documented with request/response schemas. If you're building automation on top of Snap CD, you don't need to reverse-engineer the API from the UI's network tab.

This matters because different people on a team need different things. The engineer doing the initial proof-of-concept needs the quickstart. The architect evaluating the permission model needs the concepts. The platform team building automation needs the API reference. If any layer is missing, someone on the team is blocked.

Terraform Provider

The Snap CD Terraform provider lets you manage all Snap CD configuration objects as infrastructure-as-code. Stacks, Namespaces, Modules, Runners, sources, inputs, role assignments — everything you can do in the UI, you can do in Terraform.

This means your Snap CD configuration lives in version control, goes through code review, and is reproducible across environments. You don't click through a UI to set up a new environment — you copy a Terraform module and change the variables.

A practical example

Here's what it looks like to define a Module with a Git source and wire its inputs from another Module's outputs:

resource "snapcd_module" "networking" {
  name         = "networking"
  namespace_id = snapcd_namespace.platform.id
  source_id    = snapcd_source_git.infra.id
  runner_id    = snapcd_runner.platform.id
}

resource "snapcd_module" "compute" {
  name         = "compute"
  namespace_id = snapcd_namespace.platform.id
  source_id    = snapcd_source_git.infra.id
  runner_id    = snapcd_runner.platform.id
}

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"
}

This is standard Terraform — you plan it, review it, apply it. No manual steps.

The module-within-module pattern

The Terraform provider enables a powerful composition pattern: a Snap CD Module that deploys additional Snap CD Modules.

Say you have a platform team that maintains the base infrastructure — networking, DNS, a Kubernetes cluster. Application teams each need their own set of Modules (database, cache, application deployment) that depend on the platform outputs. Rather than having the platform team manually create Modules for each application team, you write a Terraform module that:

Takes the application name and configuration as inputs.
Creates a Snap CD Namespace for the application.
Creates the application's Snap CD Modules within that Namespace.
Wires the inputs from the platform Modules' outputs.

Deploy this Terraform module through Snap CD itself, and you have a self-service system: the platform team defines the pattern once, and new applications are onboarded by adding an entry to a configuration file.

resource "snapcd_namespace" "app" {
  name     = var.app_name
  stack_id = var.stack_id
}

resource "snapcd_module" "database" {
  name         = "database"
  namespace_id = snapcd_namespace.app.id
  source_id    = var.database_source_id
  runner_id    = var.runner_id
}

resource "snapcd_module_input_from_output" "cluster_endpoint" {
  module_id        = snapcd_module.database.id
  input_kind       = "Param"
  name             = "cluster_endpoint"
  output_module_id = var.platform_compute_module_id
  output_name      = "cluster_endpoint"
}

This is Snap CD managing Snap CD — and it's just Terraform. No special API, no meta-language, no plugins.

Deployment specifications

Getting a deployment tool running shouldn't itself be a deployment project. Snap CD provides ready-to-use deployment specifications:

Docker Compose — a complete compose file that starts the Snap CD Server, a Runner, and all dependencies (PostgreSQL, RabbitMQ). Run docker compose up and you have a working local environment. The images are version-pinned, the ports are documented, and the volume mounts are pre-configured.

Kubernetes manifests — production-grade manifests for deploying the Server and Runners to a Kubernetes cluster. These include deployments, services, config maps, and service accounts. They're the same manifests used to run the Snap CD SaaS offering, not a simplified demo version.

This matters because the gap between "I have the binary" and "it's running correctly" is where many evaluations die. If it takes two days to figure out the right container configuration, environment variables, and volume mounts, most teams move on to the next option.

Examples

The documentation includes real-world implementation patterns that go beyond single-resource demos:

Multi-environment — how to structure Stacks and Namespaces for dev/staging/production, with shared Modules and environment-specific overrides.
Multi-cloud — deploying to AWS and Azure from the same Snap CD organization, with Runners scoped to each cloud provider.
Team-scoped permissions — using the permission system to give application teams full control over their Namespaces while restricting access to shared infrastructure.
GitOps workflows — configuring sources to track Git branches or tags, with approval gates before production applies.

These patterns are designed to be copied and adapted, not just read. They use realistic resource counts and dependency structures, not a single S3 bucket.

Source-available Runner

The Runner component is source-available on GitHub. You can:

Read the code to understand exactly what happens during a plan or apply. There's no black box between "job dispatched" and "terraform apply ran."
Build custom images with additional tools pre-installed — extra Terraform providers, custom scripts, cloud CLIs for specific environments.
Run it anywhere — on a VM, in a container, in Kubernetes, on a developer's laptop for testing. The Runner connects outbound to the Snap CD Server via WebSocket, so it works behind firewalls without inbound network rules.

Source access removes the trust gap that blocks adoption in security-conscious organizations. When the security team asks "what does the Runner actually do with our cloud credentials?", you can point them at the code.

Why completeness matters

Each piece of the supporting toolset solves a different adoption blocker:

Blocker	What solves it
"I can't figure out how to set it up"	Quickstart guide + deployment specs
"I don't understand the concepts"	Concept documentation
"I can't manage it as code"	Terraform provider
"I don't know what a real setup looks like"	Examples and patterns
"I can't see what the Runner does"	Source-available code
"I need to automate on top of it"	API reference

A tool that's missing any one of these forces the team to fill the gap themselves — and that's work they didn't sign up for. Snap CD ships with all of them because the goal is for your team to spend its time on your infrastructure, not on figuring out how to use the deployment tool.