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, but on the other hand provides no dependency management when you break it up into smaller states. 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
...

GitOps - New commits & semantic versions

Dependencies - Output changes trigger downstream

Configuration - Module definition changes

Manual - Dashboard or API instructions

2. Event-driven CD

Snap CD operates as a true "GitOps" operator, continuously monitoring for changes and automatically triggering deployments. Point a module to a Git reference or even a Semantic Version Range, and deployments will be triggered whenever new commits 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 manual deployment triggers available through both the dashboard and API, perfect for planned maintenance windows or emergency deployments.

3. Runner Isolation

Snap CD's architecture cleanly separates orchestration from execution. The Server handles configuration, orchestration, and logging, while isolated Runners perform the actual infrastructure deployment work.

Runners are identified by Service Principals and receive deployment instructions via a Service Bus. This gives you complete flexibility: deploy a single runner for everything, or create dedicated runners for specific clouds (Azure, AWS, GCP), environments (dev, staging, prod), or even restrict runners to specific modules or teams.

This architecture provides superior security isolation - no central system needs god-mode access to all your cloud providers. Each runner only has the credentials it needs for its designated scope.

Snap CD Server

Orchestration & Configuration

Service Bus

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

Global Roles

Administrator - Full system access

Identity Admin - Manage users & roles

Resource Roles

Owner - Full resource control

Contributor - Modify resources

Reader - View only access

4. Permission System

An enterprise-grade permission system allows you to assign granular roles to any User or Service Principal. Global Roles like Administrator or Identity Access Administrator provide broad system management capabilities.

Resource Roles provide scoped permissions on specific resources. Make a user a Creator on a Namespace and they can create new Modules within that namespace (and automatically become Owner of those modules). Assign Contributor access to specific modules for deployment permissions without broader system access.

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 simply provides your deployment sessions with the inputs they need - .env files, .tfvars files, plan.sh and apply.sh scripts, and any other configuration. Your existing Terraform workflows remain unchanged.

If needed, you can navigate directly to a Runner's storage directory and execute all commands manually. This transparency and standards-based approach means you're never locked into proprietary deployment mechanisms.

1. Download Module

Git clone or registry download

2. Prepare Inputs

.env, .tfvars, scripts

3. Execute

terraform plan & apply
All standard tools - you can debug manually anytime

Documentation

Complete guides & API reference

Terraform Provider

Full infrastructure-as-code management

Deployment Specs

Quick start templates

Examples

Real-world implementation patterns

6. Extensive Supporting Toolset

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 - perfect for self-managing infrastructure.

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 🗙