Spacelift vs Atlantis: which fits a pull request workflow
Atlantis fits a team whose main need is plan on pull request and apply on approval. It runs as a standalone application in your own infrastructure, listens for pull request webhooks, runs terraform plan and comments the output back on the pull request. Commenting atlantis apply runs the apply and posts the result, and Atlantis locks the directory or workspace until the pull request is merged or the lock is deleted. Spacelift fits a team that wants that same review loop but also expects a managed run and state layer, stack-level policy and a control plane that its operators do not have to build. The decision is less about whether pull requests drive changes and more about how much of the surrounding platform you want to own.
Four questions decide it. First, how many stacks and workspaces you run, and whether they are organized as a few repositories with many directories or as many independent projects that need shared settings. Second, whether you need a policy and governance layer beyond what a pull request review gives you, such as approval rules tied to specific run types or drift detection across many stacks. Third, where your data may live, since Atlantis keeps everything in the infrastructure you deploy, while Spacelift is a managed service, so confirm with its vendor where runs execute and where state is stored for your contract. Fourth, who will operate the service, because Atlantis needs someone to maintain its deployment, upgrades and webhooks.
Atlantis also needs a separate state backend. It has no permanent storage and does not commit state files back to version control, so you must provision and secure a remote backend such as an object store or database with locking and access controls before the first plan. Confirm which Terraform or OpenTofu versions your repositories pin, since Atlantis lets each repository or project use a different version and may need an atlantis.yaml file for modules, workspaces or custom tfvars layouts. Budget for that backend, its access policies and its backup as part of the Atlantis deployment, not as an afterthought.
Which option fits which team
This table matches common team profiles to the better fit between Spacelift and self-hosted Atlantis, judged on pull request automation, locking, state backend and operating effort. Read each row against your own repository layout and compliance constraints, then confirm the open points with the vendor and in your own environment before deciding.
| Team scenario | Better fit | Reason |
|---|---|---|
| Small team, one repository, GitHub or GitLab | Atlantis | Atlantis comments plans on pull requests and applies on command, which covers a single repo with little setup. Confirm your chosen state backend works with Atlantis, since local state is not supported. |
| Platform team with many directories and modules | Spacelift | Spacelift manages stacks, runs and state centrally, while Atlantis needs an atlantis.yaml file that grows with each directory, workspace or custom tfvars layout. Compare the upkeep of that file against the operating effort of Spacelift's managed model. |
| Team that needs OPA-style policy and drift handling | Spacelift | Atlantis focuses on plan and apply through pull requests and does not provide drift detection as a core feature in the documentation reviewed here. Confirm any policy or drift approach you plan to build on Atlantis with the project before committing. |
| Regulated team requiring all state and plans inside its network | Atlantis | Atlantis runs as a standalone application in your infrastructure and you choose the state backend, so state stays on your side. Confirm how plan files are stored and encrypted, and consider OpenTofu state encryption with a key provider you control. |
| Team that wants locking tied to pull request lifecycle | Atlantis | Atlantis locks a directory or workspace until the pull request is merged or the lock is deleted, which keeps changes sequenced in review. Check how your team will clear stale locks and who owns that step. |
| Team running OpenTofu with a custom workflow | Atlantis | Atlantis documents running OpenTofu by installing the tofu binary and setting ATLANTIS_TF_DOWNLOAD to false, which fits a pinned toolchain. Confirm that your Atlantis version and custom workflow match your OpenTofu release. |
| Team with no in-house platform operators | Spacelift | Atlantis adds ownership of the server, webhooks, credentials, upgrades and state backend to your own staff. Ask any managed or supported Atlantis provider to describe who operates each of those parts. |
How Atlantis handles a pull request from plan to apply
Atlantis runs as a standalone application inside your own infrastructure, and it starts every run from a pull request. It listens for pull request webhooks from your Git host, checks out the branch, runs terraform plan (or tofu plan if you point it at OpenTofu) and posts the output back as a comment. Nothing is applied until someone comments atlantis apply on that pull request. At that point Atlantis runs the apply and posts the result to the same thread, so the reviewer sees what changed, who approved it and what happened, all in one place. Before you commit to this flow, confirm with your Git host and Atlantis version which webhook events and comment permissions your team will need, and who is allowed to trigger apply.
Atlantis locks the directory or workspace it is working on until the pull request is merged or someone deletes the lock. That lock is what stops two open pull requests from planning and applying against the same state at once, but it also means a forgotten pull request can block a directory for other engineers. Set a rule for who may clear a stale lock and how that is recorded. Where a repository contains modules, several workspaces or custom tfvars files, you also need an atlantis.yaml file at the repository root to tell Atlantis which projects exist, which workspace and Terraform or OpenTofu version each uses, and in what order they run. Keep that file under review like any other code, because a wrong project definition is a common source of unexpected applies.
Spacelift handles the same stages as a managed run, so your team configures stacks, policies and approvals in the platform rather than writing and maintaining the pull request workflow yourself. That is a real benefit when you have many stacks and want a consistent UI, audit trail and policy engine out of the box. With Atlantis, the equivalent work sits with your team: the webhook setup, the atlantis.yaml layout, the custom workflows and the server that runs them. Ask your team to list which of those tasks it can own today, and which approval and policy checks it would need to build before it could match a managed run's controls.
Capabilities compared: Spacelift against Atlantis
This table compares how Spacelift and Atlantis handle runs, pull request workflows, locking, state, version control providers, IaC tools, policy and hosting. Read the Atlantis column as what ships with the project, and confirm every Spacelift cell against the current Spacelift documentation and a written statement from the vendor before you decide.
| Capability | Spacelift | Atlantis |
|---|---|---|
| Run triggering | Runs are triggered from VCS events, the UI, the API and the CLI, depending on stack configuration. Confirm current trigger options with the vendor. | Runs start from pull request webhooks. A comment such as atlantis plan or atlantis apply triggers the run. |
| Plan and apply on pull requests | Plan output and approval flows are available for pull requests. Confirm the exact approval and gating behavior for your setup with the vendor. | Runs terraform plan and comments the output on the pull request. Commenting atlantis apply runs terraform apply and posts the result. |
| Locking | Stacks and runs are coordinated by the platform. Confirm how concurrent runs on the same stack are queued or blocked. | Locks a directory or workspace until the pull request is merged or the lock is deleted. |
| State management | Managed state is stored by the platform. Confirm state export options and any external state backend support before migration. | Supports all Terraform state backend types except local state. You must provide and operate the backend, since Atlantis does not store state permanently. |
| Version control providers | Confirm the list of supported providers and self-hosted options with the vendor. | GitHub, GitLab, Gitea and compatible forks such as Forgejo, Bitbucket Cloud, Bitbucket Server and Azure DevOps. |
| IaC tools | Supports OpenTofu, Terraform, Pulumi and other IaC tools. Confirm the exact versions and tool list with the vendor. | Runs Terraform and supports all Terraform versions, including 0.12. OpenTofu works through a custom workflow, with ATLANTIS_TF_DOWNLOAD set to false and the tofu binary installed in the image. |
| Policy | Policy enforcement is a platform feature. Confirm the policy engine and how it applies to plans and runs with the vendor. | No built-in policy engine. Teams usually add checks through custom workflow steps or a separate policy tool, which you must select, integrate and maintain. |
| Hosting | Managed by the vendor as a SaaS offering. Confirm the self-hosted options and their licensing with the vendor. | Deployed as a standalone application in your infrastructure, with a Helm chart, manifests, Docker, AWS Fargate, Google Kubernetes Engine, OpenShift and custom installs documented. |
Where your plans, state and credentials live
With Spacelift, plans, state and runner credentials sit in a vendor-managed control plane unless you negotiate otherwise. With Atlantis, you decide where every piece lives, which makes the hosting, state backend and access model the first things to design and verify.
Data location and control plane
Atlantis is a standalone application you deploy in your own infrastructure. It receives pull request webhooks, runs terraform plan and posts the output back as a comment, so plan output and the code it reads stay inside your network boundary. Spacelift's managed runs and state are hosted by the vendor. Ask Spacelift where its control plane and run logs are stored, and confirm which parts of your data leave your environment in each option.
Hosting models for Atlantis
The Atlantis deployment documentation covers a Kubernetes Helm chart, Kubernetes manifests, Kustomize, OpenShift, AWS Fargate, Google Kubernetes Engine, Docker and custom installs, using the image ghcr.io/runatlantis/atlantis. Choose the model that matches your existing platform team skills and patching process. Each option carries its own upgrade, scaling and network-ingress work, which DeployOpen can plan and implement under a written scope.
State backend ownership
Atlantis supports every Terraform state backend type except local state, because it has no permanent storage and does not commit state files to version control. You must provide and operate the backend, such as an S3 bucket with locking or another supported store. Spacelift holds state for you. Confirm backup, versioning, access logging and restore procedures for your own backend before cutover, since they become your responsibility.
State and plan encryption with OpenTofu
OpenTofu encrypts state and plan files at rest, for local storage and remote backends, using key providers such as AWS KMS, GCP KMS and OpenBao. This is a feature of the CLI you run, so it applies whether Atlantis or another runner calls it. Decide which key provider holds the keys, who can rotate them, and how keys are backed up before you enable it, because losing a key makes encrypted state unreadable.
Identity and credential access
In Atlantis, the server holds cloud credentials and the VCS token used to read repositories and post comments, and it runs the plan for anyone who can trigger it. Restrict who can comment apply, protect the webhook secret, and scope each credential to the directories it manages. Review how Spacelift's roles and integrations map to your own identity provider, and document the mapping before you move production workspaces.
Compliance evidence, not compliance outcomes
Moving runners and state into your own environment changes which controls you operate and which evidence you must keep, including access reviews, change records and key management logs. DeployOpen can prepare systems, configuration and evidence for a compliance assessment. Independent auditors and certification bodies decide whether controls meet a framework, so confirm the requirements with them early.
Why the state backend and license matter for this choice
Choosing Atlantis means taking on state storage yourself, and that decision comes before any pull request automation. Atlantis supports every Terraform state backend type except local state, because it has no permanent storage and does not commit state files back to version control. In practice, you must provision a remote backend first, such as an object store with locking or a database backed store, and confirm that the runner's credentials can read and write it from every pull request workflow. Ask your platform team who owns that bucket or database, how it is backed up, who can read state files (state often contains secrets), and how access is audited. Those answers belong in the design before you compare run features.
The license context affects how long the stack stays stable. HashiCorp announced on August 10, 2023 that future releases of its products would move to the Business Source License 1.1, with the main restriction aimed at vendors offering competitive services. OpenTofu is an MPL-2.0 fork under the Linux Foundation, created by a group including Gruntwork, Spacelift and Harness, and it was accepted to the CNCF Sandbox on April 23, 2025. Atlantis is licensed under Apache 2.0. Your legal and procurement teams should confirm which licenses they accept for the CLI and the orchestrator, and record that decision alongside the version of each component.
Pin and verify versions before you commit. The current releases to check against are Atlantis v0.48.1 and OpenTofu v1.13.1. Confirm in the Atlantis releases page and the OpenTofu releases page that these are still the versions you intend to deploy, and set ATLANTIS_TF_DOWNLOAD and your workflow to match the binary you have tested. If your configurations use OpenTofu features added after the fork, such as state encryption, confirm that your chosen key provider and backend work with the Atlantis version in your environment before enabling them.
What each option costs to run
This table sets Spacelift's subscription against the components you pay for when Atlantis runs in your own infrastructure. Read each row as who is paid, whether the cost is one-time or recurring, and what moves the number. Spacelift pricing is quoted per contract, so the questions to bring to a quote matter as much as the table itself.
| Cost component | Spacelift (managed) | Atlantis (self-hosted) |
|---|---|---|
| Software licence | Annual subscription, with tiers set in the commercial agreement. Confirm current tiers and inclusions in writing. | Free under Apache 2.0. No licence fee; check the Apache 2.0 terms for your own redistribution needs. |
| Compute to host Atlantis | Included in the subscription; Spacelift runs the control plane and workers. | Recurring. A small Kubernetes, Fargate, GKE or VM footprint, sized by how many plans run in parallel. |
| State backend | Managed state is included. Confirm retention and export options before you commit. | Recurring. You pay for a remote backend such as an object store with locking, plus its backup and access controls. |
| Secrets handling | Managed by the platform. Confirm how cloud credentials and variables are stored and audited. | Recurring tooling and staff time to store cloud credentials, webhook secrets and VCS tokens in a secrets manager. |
| Engineering time to set up | One-time onboarding of stacks, policies and integrations, mostly on your side. | One-time. Writing atlantis.yaml, server-side workflows, module and workspace layouts, and pull request policies. |
| Upkeep and upgrades | Largely handled by the vendor. Confirm upgrade cadence and support hours. | Recurring. Atlantis, OpenTofu or Terraform, provider and Kubernetes upgrades, plus on-call for the runner. |
| Support and incident response | Vendor support tier in the contract. Confirm response targets in writing. | Recurring internal rota, or a retainer with an implementation partner for upkeep and incident work. |
| What drives cost up | Number of stacks, workers and seats, plus the support tier. | Number of repositories and parallel plans, required HA, audit logging, and how often versions change. |
| What to ask for in a quote | Itemized tiers, worker limits, state retention, export rights, support hours and renewal uplift caps. | Your own build: hosting estimate, backend and secrets design, migration plan and who operates the service after cutover. |
Moving from Spacelift to Atlantis, step by step
This sequence moves each Terraform or OpenTofu directory from Spacelift's managed runs and state to Atlantis on infrastructure you control, one directory at a time, with a checked plan at each stage.
Inventory directories, workspaces and dependencies
Your platform team lists every Spacelift stack and maps it to a directory or workspace in Git, along with its variables, contexts, attached policies and module sources. Record which stacks read outputs from other stacks, because those dependencies decide the cutover order. The output is a written inventory with one owner per directory and a note on each stack's state location. Confirm the list against Spacelift's stack settings rather than memory, since Spacelift contexts and policies do not map one to one onto Atlantis configuration.
Back up code and export state from Spacelift
Before any change, take a copy of each repository and export every stack's state. Run terraform state pull inside a Spacelift task, or enable external state access and read the state from your own tooling, then store the JSON in a bucket you control with versioning turned on. The check is a state file for each stack that you can list and download, plus a note of its current serial. This is the backup step in the OpenTofu migration overview, which describes it as the first of four steps. Keep the Spacelift stacks running until the cutover is complete.
Provision the state backend
Choose a remote backend that Atlantis supports, such as an S3-compatible bucket with locking or a database-backed backend, and provision it in your infrastructure. Atlantis does not support local state because it keeps no permanent storage, so the backend must be reachable from the Atlantis deployment. Check that the backend's locking works, then import each exported state into its new location. The check is that the terraform init command in each directory connects to the new backend and shows no unexpected changes. If you plan to use state encryption, decide on the key provider before importing.
Deploy Atlantis and connect your Git host
Deploy Atlantis as a standalone application using one of the documented methods, such as the Kubernetes Helm chart, Docker or a custom install, with the ghcr.io/runatlantis/atlantis image. Create a webhook from your Git host (GitHub, GitLab, Gitea or Forgejo, Bitbucket or Azure DevOps) and give Atlantis a token with the permissions it needs. Store the credentials in your secrets manager, not in configuration files. The check is that Atlantis answers a test webhook and reports its version in its logs. Confirm that your Git host version is on Atlantis's requirements list before you start.
Write atlantis.yaml and choose the OpenTofu or Terraform binary
Add an atlantis.yaml file that lists each project's directory, workspace, Terraform version, variable files and any custom workflow. Atlantis needs this file for modules, multiple workspaces or custom tfvars layouts. If you run OpenTofu, install the tofu binary in an init container and set ATLANTIS_TF_DOWNLOAD to false, as the May 2024 Atlantis blog post on OpenTofu describes, then point the custom workflow at tofu. The check is a successful atlantis plan dry run for each project, with the binary version shown in the output.
Run plans on a test pull request
Open a pull request with a small, harmless change in one non-production directory, then comment atlantis plan and read the output. Compare it with the Spacelift plan for the same stack, which should show no changes if the state and code match. Ask the reviewer to confirm the lock on that directory blocks a second plan until the pull request closes. Do not apply yet. The check is a plan that shows no diff against the current state, and a directory lock that behaves as documented.
Check terraform_remote_state dependencies before cutover
If any configuration reads another configuration's outputs with the terraform_remote_state data source, move the producing directory to Atlantis first and confirm that its state location is the one the consumer reads. OpenTofu's migration overview warns that these configurations typically need additional care during migration and links a separate guide for that case. Test the consumer with a plan before you cut it over. The check is a clean plan in the consumer that reads outputs from the migrated state, with no unexpected resource replacement.
Cut over directory by directory
Move one directory at a time: disable Spacelift's runs for that stack, make Atlantis the only path that applies changes to it, and run the first apply through a pull request with a small change. Follow the test-with-a-small-change step from OpenTofu's migration overview, which describes the process as designed to be safe and reversible. Keep the exported state and the Spacelift stack definition until every directory has passed a clean plan for a sustained period your change board sets. The output is a register showing each directory's cutover date, its approver and its rollback path.
Questions buyers ask before choosing Atlantis or Spacelift
How much effort does switching from Spacelift to Atlantis take, and who does the work?
The work falls on your platform or DevOps team, plus whoever owns the Git host and the state backend. Atlantis is a standalone application you deploy into your own infrastructure, so the one-time effort covers hosting it, wiring up pull request webhooks, writing an atlantis.yaml file for your directories and workspaces, moving credentials and variables, and changing your review habits to use atlantis plan and atlantis apply comments. Recurring effort covers upgrades, access control and keeping the server patched. Ask any outside partner for a written scope that lists each of these items, the systems in scope and the acceptance checks for each directory.
How long does a migration to Atlantis usually take?
No supplied figure gives a typical duration, so treat any number you hear as a claim to verify. The main drivers are the count of directories and workspaces, how complex each state is (cross-stack dependencies, shared modules, custom tfvars layouts), how many pipelines or Spacelift policies must be reproduced by hand, and how many teams must agree to the new pull request workflow. The OpenTofu migration guidance also flags configurations that share data through terraform_remote_state, which usually need extra planning. Ask for a timeline tied to a directory inventory rather than a flat estimate.
Can our team migrate from Spacelift without outside help?
Yes, a team with Terraform or OpenTofu experience and Kubernetes or container operations skills can often do it internally, but the skills must cover more than the IaC code. Someone must own the server deployment, the state backend, secrets handling and the Git host integration. Before deciding, check whether your engineers have time for a parallel run, where each directory plans clean in both systems before Spacelift is switched off. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your environment under a fixed-scope written agreement, so you can split the work between internal staff and an outside team.
What does Atlantis need from our infrastructure?
Atlantis needs three things: a runtime, a state backend and a supported Git host. The deployment documentation lists a Kubernetes Helm chart, Kubernetes manifests, Kustomize, OpenShift, AWS Fargate, Google Kubernetes Engine, Docker and custom installs, using the image ghcr.io/runatlantis/atlantis. For state, Atlantis supports every Terraform backend type except local state, because it keeps no permanent storage and does not commit state to version control. For the Git side, it works with GitHub, GitLab, Gitea and compatible forks such as Forgejo, Bitbucket Cloud, Bitbucket Server and Azure DevOps. Confirm the cloud credentials and secrets store your runners will use.
Does Atlantis replace Spacelift policy enforcement?
Not directly. Atlantis gives you plan and apply through pull requests, directory locking and per-project configuration in atlantis.yaml, but it does not provide Spacelift's policy engine as a drop-in feature. Confirm which of your Spacelift policies are approval gates, plan checks, or drift and access rules, then decide how each one will be covered, for example with pull request approval rules in your Git host, custom workflow steps, or a separate policy tool. Spacelift also covers tools beyond Terraform, so list any Pulumi or other IaC workloads separately before you commit.
How does OpenTofu compatibility affect the choice between Atlantis and Spacelift?
Atlantis can run OpenTofu. The Atlantis blog from May 2024 shows installing the tofu binary in an init container and using a custom workflow with ATLANTIS_TF_DOWNLOAD set to false. Spacelift also supports OpenTofu, so the IaC binary is rarely the deciding factor. The compatibility question is about the future: OpenTofu's FAQ aims at feature parity with Terraform, but says compatibility with future Terraform releases is not guaranteed. Pin the OpenTofu version you test, such as v1.13.1 released on October 1, 2026, and recheck the release notes before each upgrade.
Should we encrypt state before moving it to our own backend?
Yes, if your data classification requires it. OpenTofu encrypts state and plan files at rest, for local storage and remote backends, using key providers that include PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault, a feature introduced in v1.7. This is client-side encryption, so it applies regardless of which runner or pull request platform you choose. Confirm which key provider your security team approves, who holds the keys, and how key rotation and recovery are documented before you migrate any production state.
When staying on Spacelift is the better decision
Staying on Spacelift makes more sense when your Infrastructure as code work has outgrown pull request comments. If you manage many stacks across several accounts, teams and environments, the cross-stack orchestration Spacelift provides (stack dependencies, shared contexts, scheduled and drift-triggered runs, and a single view of run history) is the part you would otherwise rebuild yourself on top of Atlantis. Atlantis locks a directory or workspace and runs what a pull request asks for, which works well for a bounded set of repositories. Ask your platform team how many stacks change in a typical week and how often two of them must be applied in order. If the answer is many and often, the cost of building and maintaining that coordination layer is a real input to the decision.
Approvals and policy are the second case. Atlantis gates work through the pull request itself: whoever can approve the review and comment atlantis apply can change production. If your control framework requires a separate approver for specific stacks, plan-based policy checks before any apply, or an audit trail that records who approved which run and why, confirm whether your Atlantis workflow can express those rules with the review settings and custom workflow steps you already have. Spacelift has its own policy and approval model, so compare the two against your written change management controls rather than against a feature list. Ask your compliance lead which controls depend on approval evidence, because that evidence is where the two platforms differ most in practice.
The third case is breadth. Atlantis is built around Terraform and OpenTofu, and it runs the tool you point it at through a custom workflow. If your estate also includes Pulumi or other infrastructure tools that you plan to run through one orchestration layer, staying on Spacelift keeps those workloads on a single platform and a single operating model. Confirm which tools each platform must run during the next two years, including any that are only on a roadmap, and decide whether consolidating them is worth the subscription. If your scope is Terraform or OpenTofu alone, and your pull request workflow already meets your controls, the case for staying weakens.
How DeployOpen helps evaluate and implement Atlantis
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Spacelift vs Atlantis, we start with the written scope that decides whether Atlantis fits your pull request workflow, state backend and version pinning before any work begins.
How we scope
- Inventory your repositories, directory layouts, Terraform or OpenTofu versions and pull request hosting platform before choosing a deployment path.
- Agree in writing which state backends, approval rules, lock behavior and atlantis.yaml workflows are in scope for Atlantis.
- Confirm which Spacelift features you rely on, such as policies or contexts, and record how each one will be covered or replaced.
How we build
- Deploy Atlantis in your infrastructure using the method your platform team already operates, such as Kubernetes, Docker or a custom install.
- Configure repository webhooks, credentials, state backend access and the OpenTofu or Terraform binary pinned per project.
- Test plan and apply on pull requests against non-production directories, including directory locking, before any production repository is connected.
How we hand over
- Document the deployment, configuration, atlantis.yaml conventions, upgrade steps and rollback procedure in a form your team can maintain.
- Walk your operators through approving plans, handling locks and recovering from failed applies, with the runbook as the reference.
- Provide a cutover checklist covering state migration, credential rotation and removal of the old Spacelift runs for each stack.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped separately from the initial work.
- Plan Atlantis and OpenTofu upgrades as a tested change, checking release notes against your workflows before rollout.
- Ask us to confirm any compliance evidence you need for change management, which we prepare but independent auditors assess.
