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. See Self-Hosted Terraform Runners with Credential Isolation for the full deployment model.

• 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.
• Execution is non-invasive. Runners run standard Terraform commands in a shell session — your code has no Snap CD-specific constructs. See Non-invasive Orchestration.

Drift detection

Atlantis

Atlantis added alpha drift detection APIs in v0.45.0 (June 2026). The feature is API-only — you call endpoints to trigger drift checks and retrieve results, with optional Slack or webhook notifications. There is no scheduled drift detection built into the server; you orchestrate checks externally (e.g. via cron or CI). The APIs are marked as alpha and may change.

Snap CD

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. See Detecting and Managing Terraform Drift for a detailed walkthrough.

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

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

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

resource "snapcd_module" "networking" {
  name            = "networking"
  namespace_id    = snapcd_namespace.platform.id
  source_url      = "https://github.com/myorg/infra-networking.git"
  source_revision = "main"
  runner_id       = data.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"
  source_revision = "main"
  runner_id       = data.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. See Event-driven Continuous Deployment for how output changes cascade through the dependency graph.

Execution model

Parallelism

Atlantis runs plans and applies on its own server. Since v0.17.0, Atlantis supports parallel_plan and parallel_apply flags that run projects within a PR concurrently. However, all execution still happens on the single Atlantis server, 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 defaults to a single server with local disk-based locking. Since v0.19.0, a Redis locking backend enables running multiple Atlantis instances behind a load balancer, but this requires a shared filesystem for plan data and additional infrastructure. Native HA clustering remains an open request.

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:

• You can set apply_requirements per project, but there's no configurable approval count — it's "at least one approval" or none.
• 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. See A Permission System Built for Infrastructure for the full model:

# Platform team owns the platform Namespace
resource "snapcd_namespace_role_assignment" "platform_team" {
  principal_id            = snapcd_group.platform_team.id
  principal_discriminator = "Group"
  role_name               = "Owner"
  namespace_id            = snapcd_namespace.platform.id
}

# Junior engineer can view production but not approve
resource "snapcd_stack_role_assignment" "junior_prod" {
  principal_id            = snapcd_user.junior.id
  principal_discriminator = "User"
  role_name               = "Reader"
  stack_id                = snapcd_stack.prod.id
}

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

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

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

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 — stale locks can accumulate if PRs are closed without unlocking. Since v0.19.0, a Redis locking backend makes locks persistent across restarts, but this adds operational overhead (running and maintaining a Redis instance).

Snap CD

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

Atlantis's web UI supports HTTP basic auth (a shared username and password), but has no per-user authentication. SAML/SSO for the Atlantis UI and API remains an open request. Teams typically put Atlantis behind an OAuth proxy or restrict network access for proper identity-based access control.

Snap CD

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 via the alpha API (externally triggered, no built-in schedule) is sufficient for your needs.
• 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.
• You want scheduled, built-in drift detection with automatic plan creation — not an external cron triggering an alpha API.
• 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
• Event-driven Continuous Deployment — how output changes cascade through the dependency graph
• Detecting and Managing Terraform Drift — how Snap CD handles drift detection

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

Impressum Privacy Policy Terms of Service Contact

---

© 2026 Snap CD. All rights reserved.