No More Monolithic Terraform States
Seven key advantages of Snap CD.
1. Modular Deployments
Break infrastructure into small, focused modules — each with its own state file, lifecycle, and blast
radius. Outputs from any module automatically become inputs to others, so the dependency graph is derived
from your configuration itself: no terraform_remote_state glue, no wrapper scripts, no hard-coded
CI chains.
❌ Monolithic State
all.tfstate
✅ Modular Architecture
2. Event-driven CD
GitOps - Trigger on new commits/versions
Dependencies - Trigger on upstream output changes
Configuration - Trigger on module definition changes
Approval - Scrutinize plans before approving deployment
Changes propagate automatically. A new commit or version tag, a changed upstream output, or an edited module definition each triggers a deployment — a true GitOps orchestrator that keeps everything in sync. Add approval thresholds wherever you want plans to run automatically but applies to wait for human sign-off.
3. Runner Isolation
Keep your cloud credentials out of the control plane. The server coordinates work; execution happens on
runners you deploy in your own infrastructure. You decide where they run, what access they have, and which
modules may use them via runner supply — giving you per-environment credential isolation, so a
prod deploy never touches a dev runner.
snapcd.io
Orchestration & ConfigurationAuthenticated WebSocket Connection
Job DistributionAzure (dev)
Azure (prod)
AWS
4. Permission System
Organization Roles
@org
@org
Scoped Roles
stack: prod
namespace: prod/networking
module: prod/networking/vpc
Role-based access control at every level of the hierarchy — organization, stack, namespace, module — plus who can manage runners, agents, and integrations. Scope users, service principals, and groups precisely. The model applies to every path, whether you approve in the dashboard, call the REST API, or use the Terraform provider: there is no unenforced path.
5. Non-invasive Orchestration
Your Terraform code doesn't know Snap CD exists — no wrapper CLI, no proprietary plan format, no DSL layered
on top. Runners clone your repo, Snap CD writes the inputs (.tfvars, .env,
plan.sh, apply.sh), and real terraform init/plan/apply binaries run in a
normal shell. Drop into a runner and run them yourself — and if you ever leave, your code and state stay put.
1. Download Module
Git clone or registry download2. Prepare Inputs
.env, .tfvars, scripts3. Execute
terraform plan & apply6. Extensive Supporting Toolset
Documentation
Complete guides & API referenceTerraform Provider
Full infrastructure-as-code managementDeployment Specs
Quick start templatesExamples
Real-world implementation patternsAround the core sits a full adoption surface: extensive documentation, ready-to-use deployment repos for local, Docker, and Kubernetes, and working samples. A Terraform provider manages nearly every Snap CD object as code.
7. AI on a Leash
In infrastructure, the gap between "run this command" and "destroy this resource" is one flag — so broad-access agents are all-or-nothing. Snap CD gives AI a first-class Agent component instead: a narrow, event-driven Missions framework, governed by the same RBAC that controls your people. Missions only fire on the events and scopes you grant; the agent's role decides what it may do — Contributor on test, Reader on prod, blocked past an approval gate — and every action is attributed to the agent in the audit trail.
AI Agent as a Principal
test/*
prod/*
runner-prod
Guardrails
Approval gates — human sign-off before apply
Audit trail — every action logged and attributable
Intelligent GitOps for Infrastructure as Code. Automate, orchestrate, and scale your infrastructure deployments with confidence.
© 2026 Snap CD. All rights reserved.