Snap CD vs Atlantis

Atlantis is one of the most widely used open-source tools for running Terraform via pull requests. It pioneered the "plan on PR, apply on merge" workflow that many teams now consider table stakes. If you're using Atlantis today, it's likely because it solved a real problem: getting Terraform out of individual laptops and into a reviewable, auditable CI-like flow.

Snap CD solves a different set of problems. It provides persistent orchestration, cross-state dependency management, approval workflows, drift detection, and granular access control — things that become important as infrastructure grows beyond what a single PR-driven workflow can manage. This guide compares the two.

Architecture

Atlantis

Atlantis is a self-hosted webhook server. You deploy it (typically as a container or Kubernetes pod), point your GitHub/GitLab/Bitbucket webhooks at it, and it responds to PR events. When someone opens a PR that touches Terraform code, Atlantis runs terraform plan and posts the output as a PR comment. When the PR is approved and someone comments atlantis apply, it runs the apply.

The entire lifecycle is tied to the pull request:

• Plans are triggered by PR events. No PR, no plan. If infrastructure drifts between PRs, Atlantis doesn't know.
• Apply happens via PR comment. The approval model is GitHub's (or GitLab's) native PR approval — whoever can approve the PR can trigger the apply.
• State is ephemeral. When the PR is merged and the Atlantis process restarts, there's no record of what happened beyond what's in the PR comments and Git history.

Snap CD

Snap CD separates orchestration from execution. The Server (snapcd.io or self-hosted) handles configuration, dependency tracking, source monitoring, and persistent history. Runners — lightweight agents deployed in your infrastructure — execute the actual terraform plan and terraform apply commands.

• Plans are triggered by source changes, dependency updates, or manual actions. No PR required — a commit to the monitored branch is enough.
• Apply goes through built-in approval gates with configurable thresholds, independent of your Git platform's PR model.
• History is persistent. Every plan, apply, approval, and output change is recorded server-side with a structured audit trail.

Drift detection

This is Atlantis's most significant gap. Atlantis has no drift detection — the single most requested feature in the project's history. If someone changes a resource in the cloud console, Atlantis doesn't know until the next PR happens to touch that resource.

Snap CD runs scheduled drift checks per module. When drift is detected, a new plan is created and routed through the normal approval workflow. You see the drift before it causes a surprise in someone's next PR.

For teams managing production infrastructure where manual changes happen (incident response, console fixes, vendor support tickets), drift detection isn't optional — it's how you prevent the next terraform apply from silently reverting a critical hotfix.

Cross-state dependencies

Atlantis treats each Terraform project (root module) as independent. There's no concept of "module A's outputs feed into module B's inputs." If your networking state produces a VPC ID that your compute state needs, Atlantis doesn't help you coordinate that. You're back to terraform_remote_state, wrapper scripts, or manual coordination.

There's been a long-standing request for prerequisite apply ordering — the ability to say "don't apply production until staging has been applied first." It remains unimplemented.

Snap CD makes cross-state dependencies a first-class concept. Modules declare their inputs from other Modules, and Snap CD builds the dependency graph:

resource "snapcd_module" "networking" {
  name         = "networking"
  namespace_id = snapcd_namespace.platform.id
  source_url   = "https://github.com/myorg/infra-networking.git"
  runner_id    = snapcd_runner.platform.id
}

resource "snapcd_module" "compute" {
  name         = "compute"
  namespace_id = snapcd_namespace.platform.id
  source_url   = "https://github.com/myorg/infra-compute.git"
  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"
}

When networking's vpc_id output changes, compute automatically re-plans. No terraform_remote_state, no manual coordination, no PR required.

Execution model

Parallelism

Atlantis runs plans and applies on its own server. Running multiple projects in parallel has been requested for years. The current model runs projects sequentially within a PR, and concurrent PRs touching the same workspace can conflict.

Snap CD distributes execution across Runners. Independent Modules run in parallel on different Runners. The server handles queuing and ensures only one operation runs against a given module at a time — no lock contention, no manual retry.

High availability

Atlantis is a single server. Running a highly available cluster with multiple nodes is not natively supported. If the Atlantis server goes down, PR-based planning and applying stops until it's back.

Snap CD's Runners are stateless workers that reconnect automatically. You can run multiple Runners for redundancy. The server itself (on snapcd.io) is managed; self-hosted deployments can be scaled independently.

Approval and access control

Atlantis

Atlantis delegates approval to your Git platform. If a PR is approved in GitHub, atlantis apply proceeds. Enforcing that only certain people can plan or apply — particularly for GitLab and Bitbucket — has been an open request since 2018.

You can configure apply_requirements in atlantis.yaml to require PR approval before apply, but the controls are coarse:

• No per-workspace or per-directory approval thresholds.
• No concept of "this user can approve staging but not production."
• No distinction between "can trigger a plan" and "can approve an apply."

Snap CD

Snap CD has hierarchical RBAC with roles (Owner, Contributor, Reader, Approver) scoped to any level — organisation, Stack, Namespace, Module, or Runner:

# Platform team owns the platform namespace
resource "snapcd_role_assignment" "platform_team" {
  principal_id = snapcd_group.platform_team.id
  role         = "Owner"
  scope_id     = snapcd_namespace.platform.id
  scope_type   = "Namespace"
}

# Junior engineer can view production but not approve
resource "snapcd_role_assignment" "junior_prod" {
  principal_id = snapcd_user.junior.id
  role         = "Reader"
  scope_id     = snapcd_stack.prod.id
  scope_type   = "Stack"
}

Approval thresholds are per-Module — you can require two approvals for production networking and zero for a dev sandbox. The approval system is independent of your Git platform.

Plan output and sensitive data

Atlantis posts plan output directly to PR comments. This is convenient for review, but plan output can contain sensitive data — database passwords, API keys, connection strings marked as sensitive in Terraform. Once it's in a PR comment, it's in your Git platform's history. Atlantis has added some redaction for sensitive values, but the underlying tension remains: PR comments are visible to anyone with repo access.

Snap CD displays plan output in its own dashboard, governed by RBAC. Only users with the appropriate role on the Module can see the plan. Sensitive outputs are encrypted into the secret store and never exposed in plain text.

Locking

Atlantis implements its own workspace-level locking. When a PR triggers a plan for a workspace, Atlantis locks that workspace to prevent other PRs from planning or applying against it until the first PR is merged or the lock is manually released. This prevents concurrent modification but creates friction — an external locking backend has been requested to make locks persistent across Atlantis restarts.

Snap CD's server-side queue eliminates lock contention entirely. Each Module has its own deployment queue. If two changes are triggered for the same module, they run sequentially — no errors, no manual unlocking, no stale locks after a server restart.

SSO and authentication

Atlantis's web UI has no built-in authentication. SAML/SSO for the Atlantis UI and API is a top-requested feature. Teams typically put Atlantis behind an OAuth proxy or restrict network access.

Snap CD has built-in OAuth/OpenID Connect authentication. Users authenticate via your identity provider, and RBAC governs what they can see and do.

Comparison table

When to choose which

Atlantis is a good fit when:

• Your team is small and your workflow is PR-centric — every infrastructure change goes through a pull request.
• You don't need cross-state dependency management — your Terraform projects are independent.
• Drift detection isn't a concern (or you handle it separately).
• You want a free, open-source tool with a simple operational model.
• GitHub/GitLab's native PR approval is sufficient for your access control needs.

Snap CD is a good fit when:

• You need cross-state dependencies managed automatically — outputs flowing between Modules with cascading re-plans.
• Drift detection is important — you want to know when infrastructure diverges from code between deployments.
• You need granular RBAC beyond what Git platform permissions provide — per-Stack, per-Namespace, per-Module access control.
• Your infrastructure spans multiple teams or cloud providers and you need distributed execution across isolated Runners.
• You want a persistent audit trail of every plan, apply, and approval — not just PR comments.
• Applying on merge rather than via PR comments is how you want to work — Snap CD's source monitoring triggers plans on commit, independent of PRs.

Migrating from Atlantis to Snap CD? Your Terraform code doesn't change. Atlantis and Snap CD are both non-invasive — they run standard terraform plan and terraform apply. The migration is about replacing the orchestration layer, not rewriting infrastructure code. You can run both in parallel during the transition: Atlantis handling some workspaces while Snap CD handles others.

See also

• Modular Deployments — how Snap CD's Module system wires cross-state dependencies
• Self-Hosted Terraform Runners with Credential Isolation — how Runners provide per-environment credential isolation
• A Permission System Built for Infrastructure — granular RBAC across the Stack/Namespace/Module hierarchy
• Non-invasive Orchestration — Snap CD runs standard Terraform commands, no wrappers
• Detecting and Managing Terraform Drift — how Snap CD handles drift detection