COMING SOON!

No More Monolithic Terraform States

Why Snap CD?

Six key advantages that make Snap CD the intelligent choice for modern infrastructure deployment

1. Modular Deployments

Terraform/OpenTofu provides excellent dependency management within a single state, but struggles when the monolithic state becomes too large. Breaking down monolithic states into smaller ones however means that you now have interdependencies that you need to handle manually! Snap CD solves this with a modules system that allows you to plug infrastructure components in or out of a stack at any time.

Each module is a specification defining where to find your code (Git repo, Terraform registry), which inputs to provide, and which runners to use for deployment. Outputs from any module automatically become available as inputs to other modules, creating a declarative dependency system across your entire infrastructure.

❌ Monolithic State

all.tfstate

✅ Modular Architecture

network.tfstate
compute.tfstate
database.tfstate
security.tfstate
application.tfstate
...

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

Snap CD operates like a "GitOps" operator, continuously monitoring for changes and automatically triggering deployments. Point a module to a Git reference and deployments will be triggered whenever new commits (or tagged versions if you prefer) become available.

The event-driven architecture means that when one module's outputs change, any dependent modules are automatically queued for redeployment. This creates a cascading update system that keeps your entire infrastructure in sync without manual intervention.

You maintain full control with approval gates where you can instruct Snap CD to require a minimum number of approvals before applying a plan.

3. Runner Isolation

Snap CD's architecture cleanly separates orchestration from execution. The snapcd.io servers handle configuration, orchestration, and logging, while isolated runners perform the actual infrastructure deployment work. You decide how and where you deploy your runners, and what access you want to give them to your system. You also decide which Snap CD modules are allowed to use which runners, allowing you to for example easily separate between test and prod environments.

Runners connect to snapcd.io via long-lived, authenticated, bi-directional WebSocket connections, which they use to pick up jobs and post back results. The runner is an open-source component, which is maintained and published here.

snapcd.io

Orchestration & Configuration

Authenticated WebSocket Connection

Job Distribution
Runner 1
Azure (dev)
Runner 2
Azure (prod)
Runner 3
AWS

4. Permission System

Organization Roles

@org

Owner

@org

IdentityAccessAdministrator

Scoped Roles

prod

Reader

prod/networking

Contributor

prod/networking/vpc

Owner

runner-azure-prod

Owner

An enterprise-grade permission system allows you to assign granular roles to any user, service principal or group. organization roles like Owner or IdentityAccessAdministrator provide broad permissions within your organization.

Roles assignments can be scoped down to stacks (e.g. prod and test), namespaces (e.g. prod/networking, prod/storage, prod/application) or modules (e.g. prod/networking/vpc) allowing you to granularly determine who can access what.

You can also scope role assignments to runners. A runner's Owner can for example decide which modules are allowed to use it.

All roles apply universally - whether actions are performed through the web UI, direct API calls, or via the Terraform Provider. This ensures consistent security across all interaction methods.

5. Non-invasive Orchestration

Snap CD doesn't force proprietary tooling into your deployment process. When a runner downloads modules onto its local storage, it executes deployments using standard shell sessions with native Terraform/OpenTofu commands.

Snap CD provides your runners with the inputs they need, such as .env files, .tfvars files, plan.sh and apply.sh scripts etc. Your existing Terraform workflows remain unchanged.

If needed, you can navigate directly to a runner's storage directory and execute all commands manually. We want you to continue using Snap CD, but not because we've locked you in with low-level proprietary tooling!

1. Download Module

Git clone or registry download

2. Prepare Inputs

.env, .tfvars, scripts

3. Execute

terraform plan & apply

6. Extensive Supporting Toolset

Documentation

Complete guides & API reference

Terraform Provider

Full infrastructure-as-code management

Deployment Specs

Quick start templates

Examples

Real-world implementation patterns

Snap CD comes with a comprehensive ecosystem of tools and resources. Extensive documentation covers everything from basic setup to advanced deployment patterns, with detailed API references for programmatic integration.

The Terraform provider allows you to manage all Snap CD configuration objects as infrastructure-as-code. You can even follow a module-within-module pattern where you use a Snap CD module to deploy additional Snap CD modules!

Ready-to-use deployment specifications and real-world examples help you get started quickly, while the complete toolset ensures you can implement any deployment pattern your organization requires.

Snap CD

Intelligent GitOps for Infrastructure as Code. Automate, orchestrate, and scale your infrastructure deployments with confidence.


© 2025 Snap CD. All rights reserved.

An unhandled error has occurred. Reload 🗙