When Atlantis is a fit for a team replacing env zero's pull request workflow
Consider a platform team whose env zero use is mostly plan and apply on pull requests: changes to Terraform or OpenTofu code are reviewed in Git, the plan is posted for review, and the apply runs after approval. For that team, Atlantis running in its own infrastructure covers that workflow, because Atlantis listens for pull request webhooks, runs the plan, comments the output back on the pull request, and runs the apply when someone comments atlantis apply. It also locks a directory or workspace until the pull request is merged or the lock is deleted, which prevents two open pull requests from changing the same stack at once. The fit is strongest when the team already works in GitHub, GitLab, Gitea or Forgejo, Bitbucket, or Azure DevOps, since Atlantis supports those systems directly.
Env zero remains the better fit when the value sits outside the pull request. If your team relies on environment lifecycle (creating, updating and destroying environments from templates), approval and policy workflows across many teams, cost estimates and governance, or a managed remote state service, Atlantis does not replace those features. Atlantis has no permanent storage and does not commit state back to version control, so you must choose and operate a state backend yourself. Before you commit, answer three questions: which of your current env zero features do engineers use every week, who will own the state backend and its access controls, and who will maintain Atlantis, its atlantis.yaml files and the workflows that go with them.
The first question is a feature inventory. Export or list what your environments depend on, including templates, scheduled destroys, drift handling, and any OPA or cost policy checks, and mark which ones have a direct Atlantis equivalent through a custom workflow and which would need new tooling or manual process. The second is state ownership. Atlantis supports every Terraform state backend type except local state, so the backend you pick, its locking, encryption and access logging, become your responsibility, and you should confirm how your team will handle state during the migration, using the documented path in the state migration guide. The third is runtime and tooling. Atlantis can run OpenTofu as well as Terraform, and the current release line is one you should pin and test, so ask whether your team can keep the Atlantis image, the IaC binary and the workflows updated on a schedule. If the answers point to a small set of repositories with plan and apply at their core, Atlantis is a good fit. If they point to environment lifecycle and governance across many teams, plan for that gap before you switch.
Which option fits which scenario
This table maps common reasons teams use env zero to the Atlantis capability that covers them and the gaps that remain. Read each row against your own main use of env zero: if the gap in the last column matters to you, plan for it before you switch.
| Scenario | Better fit | Why |
|---|---|---|
| Plan and apply driven by pull requests | Atlantis | Atlantis listens for pull request webhooks, runs terraform plan, comments the output and runs apply when a user comments atlantis apply. |
| Preventing overlapping changes to the same stack | Atlantis | Atlantis locks a directory or workspace until the pull request is merged or the lock is deleted. |
| Multiple environments with automatic expiry (TTLs) | env zero | Atlantis has no environment lifecycle feature, so time-limited environments need separate tooling or a manual process. |
| Cost governance and budget controls | env zero | Atlantis does not provide cost governance or budgets; confirm the current env zero feature set against your own budget policy. |
| Full self-hosting in your own infrastructure | Atlantis | Atlantis is deployed as a standalone application in your infrastructure under Apache 2.0, and it runs on Kubernetes, Docker, AWS Fargate and other targets. |
| Teams that want state hosted for them | env zero | Atlantis supports most Terraform state backends but does not host state; you must provision and operate the backend yourself. |
| Using OpenTofu with pull request automation | Atlantis | Atlantis documents running OpenTofu with a custom workflow, so you install the tofu binary and set ATLANTIS_TF_DOWNLOAD to false. |
| Git provider coverage | Atlantis | Atlantis supports GitHub, GitLab, Gitea, Forgejo, Bitbucket Cloud, Bitbucket Server and Azure DevOps. Confirm your exact provider version against the requirements documentation. |
How Atlantis runs a plan and apply from a pull request
Atlantis runs as a standalone application inside your own infrastructure. You deploy it with one of the documented methods, then register a webhook with your source control system so that pull request events reach it. Atlantis does not sit between your engineers and your cloud accounts as a hosted service; it runs in your network with the credentials you give it, and the webhook is the only inbound trigger that starts work. Your platform team owns the deployment, the image version, the secrets it holds and the network path to the state backend and cloud APIs.
- Supported deployment paths: 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. - Webhook registration: Atlantis listens for pull request webhooks from GitHub, GitLab, Gitea and compatible forks, Bitbucket Cloud, Bitbucket Server or Azure DevOps.
- Credentials at runtime: Cloud and provider credentials live in the Atlantis environment, so access control for the deployment is effectively access control for every apply it can make.
- Version pinning: Each repository or project can use a different Terraform or OpenTofu version, so record which binary each project depends on.
Before go-live, confirm with your security team where the Atlantis secrets are stored, how webhook secrets are rotated, and which network paths the instance needs.
When a pull request is opened or updated, Atlantis runs terraform plan for the affected projects and posts the output as a comment on the pull request. Reviewers see the proposed change in the same place they review the code, which is the main reason teams adopt this model. The plan is generated from the branch being proposed, so the reviewer evaluates what would change before anything is merged. The quality of this comment depends on how your repository is laid out and on whether Atlantis can determine which projects the change touches.
- Automatic planning: Atlantis plans on pull request open and update events, and reports results per project.
- Changed-file detection: Which projects run depends on your configuration, so confirm how the team handles changes to shared modules that affect several environments.
- Plan output as review input: Reviewers read the plan, not only the diff, so plans with sensitive values need masking or restricted comment visibility on your forge.
- Failure reporting: A failed plan is posted back with its error, which keeps the failure in the review thread.
- Tool version: The plan runs with the binary configured for that project, so a version mismatch shows up here first.
Check that your reviewers understand that the plan is a preview, and that drift between plan and apply can still occur if the environment changes after review.
After review, an approved engineer comments atlantis apply on the pull request. Atlantis then runs terraform apply for the project and posts the output back to the same thread. The apply is initiated by a human comment, not by merging, so the approval step is a comment command backed by your forge's permissions and, if you add them, branch protection and approval rules. Atlantis does not decide who may apply on its own policy; that boundary has to be designed and tested before production use.
- Explicit trigger: Apply runs only when someone comments the command on the pull request, which creates a visible record in the thread.
- Output retained in the thread: The apply log is posted to the pull request, which helps auditors trace a change to its approver.
- Access control gap: Confirm which forge roles can post the apply command, since commenting rights may be broader than deployment rights.
- Order of operations: Plan the sequence for dependent projects, because applying one project before another can fail or leave partial state.
- Policy checks: Atlantis supports workflow customization, but any policy gate, such as cost or security scanning, must be built and maintained by your team.
Before relying on this stage for production, test an apply in a non-production environment and verify who can trigger it under your forge's permission model.
Atlantis locks a directory or workspace when a plan runs, so a second pull request cannot change the same target until the first is finished. The lock is released when the pull request is merged or when someone deletes the lock. This protects against two concurrent changes overwriting each other, but it also means a stale or abandoned pull request can block work on that target. Your team needs a rule for who clears locks, how that is recorded, and what happens when a pull request is closed without merging.
- Scope of the lock: Locks apply to the directory or workspace, so the granularity of your project layout determines how often engineers collide.
- Release on merge: A merged pull request releases the lock, which ties the lock lifecycle to your review flow.
- Manual release: Deleting a lock is a deliberate action, so define who may do it and log the reason.
- Stale lock risk: Abandoned pull requests can hold locks for a long time, so add a review routine.
- Concurrency with state: The lock controls Atlantis runs, while your state backend should provide its own locking where the backend supports it.
Confirm your lock-clearing procedure with the team that will be on call for the platform before you rely on it.
Atlantis keeps no permanent storage, and it does not commit state files back to version control. That is why it needs a remote state backend for any environment that matters: each plan and apply must read and write state somewhere that survives the container. Local state is not supported for this reason. Separately, if your repository contains modules, several workspaces, or custom variable files, you need an atlantis.yaml file that tells Atlantis how to find and run each project. Without it, Atlantis falls back to its default discovery, which may not match your layout.
- Remote backend requirement: Atlantis supports all Terraform state backend types except local state, so choose a backend such as an object store or a managed database and confirm it works from the Atlantis network.
- Project definitions: Use
atlantis.yamlto declare projects, directories and workspaces, and to point each project at its tfvars files. - Custom workflows: Modules, shared variable files and multiple workspaces per directory usually need explicit project entries.
- Version per project: The configuration file can also pin the Terraform or OpenTofu version for each project.
- OpenTofu: The May 2024 Atlantis blog shows running
tofuby installing the binary in an init container, withATLANTIS_TF_DOWNLOADset to false.
Review the atlantis.yaml file with your platform engineers and confirm the state backend's own encryption and access controls with your security team.
What Atlantis leaves out and when that gap matters
Atlantis covers the pull request loop well: plan, comment, apply and lock. The gaps sit around that loop, in how environments live and die, how spend is governed, where state is kept and how approvals extend beyond a code review. Each card below names the condition under which the gap starts to hurt and what your team would need to build or buy to close it.
Environment lifecycle and TTLs
env zero tracks environments as objects with a lifecycle: creation from a template, scheduled or time-to-live teardown, and clean removal when a branch is abandoned. Atlantis has no concept of an environment beyond a directory or workspace that a pull request touches. If your teams spin up short-lived preview stacks for feature branches, nothing in Atlantis destroys them automatically when the pull request closes. Check whether your team relies on scheduled destroys today, then decide whether a scheduled job running terraform destroy per stack, or a separate tool, will own that duty.
Cost governance
env zero provides cost estimation and budget-oriented controls as part of its platform. Atlantis runs plans and applies but does not track spend across stacks or enforce budget thresholds on its own. This gap matters when finance or platform leads need per-team cost reporting or want to block a plan that increases monthly spend beyond a set limit. Teams usually add a cost estimation step in the workflow and a reporting job outside Atlantis. Ask which cost signals your approvers use today before you decide what to rebuild.
State hosting and retention
Atlantis supports every Terraform state backend type except local state, so it does not store state itself. The state lives in a backend you run, such as an object store with locking or a database. That means someone must provision, back up, encrypt and version the backend, and manage access to it. If you move state out of env zero, decide early who owns the backend and how state versions are retained. OpenTofu's client-side state encryption with a key provider such as AWS KMS or OpenBao can add a layer of protection before state reaches the backend.
Policy and approval beyond review
Atlantis gates applies on pull request approval and the lock that holds a directory until merge. It does not provide a multi-step approval chain, per-environment approvers or policy checks that run against plans with a managed policy library. If your controls require a second approver from a separate group for production, or policy evaluation of plan output before any apply, those rules need an external policy engine such as Open Policy Agent wired into the workflow, plus branch protection and CODEOWNERS on the repository. Confirm with your compliance owner which approval records they need to retain and where they will be stored.
Where state, plans and credentials live with each option
Atlantis is a standalone application that you deploy inside your own infrastructure, on a Kubernetes cluster with the Helm chart or manifests, Kustomize, OpenShift, AWS Fargate, Google Kubernetes Engine, Docker or a custom install, using the ghcr.io/runatlantis/atlantis image. Plans and applies run in that process, so the cloud credentials Atlantis uses sit in your environment rather than with a vendor. State does not live in Atlantis: it stays in whatever remote backend your team configures, because Atlantis supports every Terraform state backend type except local state. Confirm before go-live which backend holds each state file, who can read it, and whether the backend itself is in the same account and region as the workloads it manages. Also confirm which identity Atlantis assumes for each directory or workspace, since a single broad role across all repositories widens the blast radius of a bad pull request.
Audit and compliance questions follow from that layout. Your evidence will be spread across the Git host's pull request history, Atlantis logs, the cloud provider's audit trail and the state backend's versioning, so decide early which system is the record for plan output and approvals. Atlantis plan comments can contain sensitive values if variables are printed, so review how outputs are shown and who can view the repository. DeployOpen can help plan and implement these controls and collect the evidence they produce, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so ask your assessor which artifacts they expect before you finalize the design.
OpenTofu adds client-side encryption of state and plan files, with key providers including AWS KMS, GCP KMS, OpenBao, Azure Vault and PBKDF2, and the OpenTofu state and plan encryption documentation describes the configuration. Treat this as a control to confirm rather than a default: check that your Atlantis workflow runs the tofu binary with encryption configured, that the key provider is reachable from the Atlantis pods, and that key rotation and access to the keys are assigned to named owners. Because encryption is applied by the client, a backend that stores encrypted state still needs its own access controls, and the key policy becomes a second place where access must be reviewed.
Hosting, identity and compliance implications for regulated teams
Atlantis moves plan and apply out of env zero's hosted service and into your own infrastructure, so the questions that matter shift to where runs execute, who can approve them and what evidence you can produce. The four areas below are the ones assessors and security teams usually ask about first, and each depends on how your team configures its environment.
Data residency of state and plans
With Atlantis, the runner, the state backend and the plan output all sit where you deploy them. Plan files can contain sensitive values, so the location of the Atlantis pod or host, the object store or database holding state, and the logs Atlantis writes all fall within your residency scope. Confirm which regions your cloud accounts use, where pull request comments are stored by your Git host, and whether any copy of state leaves your network during a migration. Ask env zero for the same answers about its hosted backend before comparing.
Hosting model and operating responsibility
Atlantis is a standalone application you deploy with a Helm chart, manifests, Docker or a custom install, so patching, scaling, high availability and backups of its runtime become your team's tasks. In env zero's hosted model, the vendor operates the control plane. Decide whether your platform team can own that service on a supported schedule, and document who restarts it, who rotates its webhook secret and where its logs are retained. Agree these responsibilities in writing before the cutover.
Identity for pull request approvals
In Atlantis, the person who comments atlantis apply is the person whose approval gate matters, so the identity behind each comment and the branch protection rules on your Git host must agree. Check that only authorized users can trigger apply, that required reviewers are enforced by the forge rather than by convention, and that Atlantis's credentials for cloud accounts are scoped per directory or workspace. Map these controls to your existing identity provider groups and document the mapping as an access review input.
Evidence for assessors
Atlantis produces pull request comments with plan and apply output and holds directory locks while changes are pending, but it does not by itself provide a tamper-evident audit store, retention policy or control mapping. Plan a place to keep plan outputs, approval records and the Git history together, and confirm with your auditor which evidence they expect for change management. DeployOpen can help prepare systems, controls and evidence for a compliance assessment, but independent auditors issue any audit report or attestation.
How a move from env zero to Atlantis is structured
The sequence moves pull request based Terraform workflows onto Atlantis running in your infrastructure, with state migrated and each environment retired without destroying the resources it manages. Each step ends with a check you can confirm before the next one begins.
Inventory pull request based env zero workflows
Your platform or DevOps team lists every env zero environment and classifies it by how changes reach it: pull request triggered plan and apply, manual deploys from the env zero UI, scheduled runs, or runs started from the CLI. Record for each environment the repository, directory, OpenTofu or Terraform version, backend, variables, and any approval policies or cost checks attached to it. Only the pull request based group is a fit for Atlantis's model, so the other groups need a separate decision. The step is done when you have a written list that the security and platform owners have both reviewed.
Back up state and code before any change
Before touching a backend, the team pulls a copy of each environment's current state and keeps it in a store the migration does not modify, along with the Git commit that produced it. The state download uses the env zero backend through the Terraform login flow, and access to these backups should be limited to the people running the migration. The step is done when every environment has a state file and a commit reference stored together, and someone has confirmed the files open and match the expected resource count.
Install Atlantis and the IaC binary in your infrastructure
The platform team deploys Atlantis as a standalone application in your own cluster or host, using one of the documented methods such as the Helm chart, Kubernetes manifests, Docker or a custom install. Decide between OpenTofu and Terraform at this point: Atlantis can run either, and the OpenTofu migration overview recommends installing the binary, initializing and verifying the configuration. Configure the webhook secret, the Git provider token, and the state backend credentials in your secrets store. The step is done when Atlantis responds to a test webhook and reports the binary version it will use.
Write atlantis.yaml for each project
Engineers translate each env zero environment into a project entry in
atlantis.yaml, setting the directory, workspace, Terraform or OpenTofu version, and any custom tfvars files. Modules, multiple workspaces and custom layouts all require this file, so review it against the inventory from the first step. Add workflow overrides only where the default plan and apply behavior is insufficient. The step is done when a pull request touching a single project triggers a plan for that project alone and the output matches the expected change.Migrate state with the backend swap and init
For each environment, the engineer replaces the env zero backend block with the target backend that Atlantis will use, then runs initialization with the state migration option so the state moves into the new location. Remote state sharing needs particular care: the OpenTofu migration guide warns that configurations using the terraform_remote_state data source usually need additional work, so list every consumer of those outputs and migrate producers and consumers in a planned order. Keep the old state backup until the verification step passes. The step is done when init completes and the new backend holds a state with the same resources as the backup.
Verify with a no-change plan
Run a plan against each migrated project and confirm it reports no changes. A plan that proposes creates, updates or deletes means the configuration, variables, provider versions or state do not match what env zero was managing, and the cutover for that project stops until the difference is explained. Check that the plan output in the pull request matches what the platform team expected for that environment. The step is done when every project in the inventory returns a clean plan and the results are recorded against the inventory.
Switch webhooks and mark env zero environments inactive
Point the repository webhook at Atlantis and disable any env zero triggers for the same environments, so a single change cannot be planned or applied by both systems. Mark each env zero environment inactive in the env zero console rather than destroying it, so the resources it created stay in place and the deployment history remains available. Confirm that Atlantis's pull request locks behave as expected by opening a test change in a non-production project. The step is done when a test pull request produces one plan from Atlantis, env zero shows no new runs for those environments, and the managed resources are unchanged.
Questions teams ask before switching from env zero to Atlantis
What does it cost to move from env zero to Atlantis?
The software is free under Apache 2.0, so the cost is labor, hosting and the time your team spends on the move. Expect one-time work to cover writing an atlantis.yaml file for each repository layout, wiring the webhook to your Git host, moving credentials into a secrets store and reviewing the workflows that replace env zero's approval steps. Recurring costs are the Kubernetes or container hosting Atlantis runs on, the state backend you choose and the people who maintain the server and its upgrades. The main cost drivers are the number of repositories and workspaces, how many custom workflows you need and how many cloud accounts Atlantis must reach. When requesting a quote from any implementation partner, ask for the written scope, the list of repositories included and who owns upgrades after handover.
Can our internal platform team migrate to Atlantis without outside help?
Often yes, if the team already runs Terraform in version control and has someone comfortable operating Kubernetes or a container host. Atlantis is a single application that listens for pull request webhooks, so the core setup is small compared with a full environment platform. Outside help tends to be useful when the estate is large, when state must move between backends, when the team has no Kubernetes experience, or when audit evidence for the change must be prepared. Be honest about gaps: env zero's environment lifecycle and cost features will need replacements built by your team. Ask any provider to confirm which of these tasks are in the written scope and which stay with your staff.
How long does an env zero to Atlantis migration take?
The duration depends on scope, not on a fixed rule. The main drivers are the number of repositories and directories that run plan and apply, the number of state backends you must keep or move, how many pull request workflows need custom steps, and how much of your approval logic lives inside env zero templates. A pilot with one low-risk repository lets you test locking, comments and apply behavior before you commit a timeline. Ask any partner for a phased plan with a pilot milestone and a cutover date agreed in writing before work begins, since most engagements are fixed-scope.
What happens to env zero environments and their cloud resources during the switch?
Your cloud resources stay where they are. Switching the tool that runs Terraform does not destroy infrastructure, as long as the state file continues to describe the same resources. The safe sequence is to back up state and code, move state to a backend Atlantis can reach, run a no-change plan to confirm the configuration matches reality, and then mark the env zero environments inactive without running a destroy. Do not let env zero and Atlantis apply to the same state at the same time. Confirm the exact steps for your env zero version with the vendor, because environment deactivation behaves differently from a plain state move.
Does Atlantis support OpenTofu as well as Terraform?
Yes, Atlantis documents running 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. OpenTofu is MPL-2.0 licensed and describes itself as a drop-in replacement for Terraform that preserves existing workflows and configurations. Compatibility with future Terraform releases is not guaranteed, so check the OpenTofu version you pin against your providers and modules. Atlantis also supports Terraform versions per repository or project, so you can migrate one directory at a time.
What do we lose on environment lifecycle and cost tracking?
Atlantis focuses on running plans and applies from pull requests, so several env zero capabilities are not included. Based on the scope of Atlantis itself, the gaps are:
- Environment lifecycle features such as creating, cloning and destroying environments from templates on demand
- Cost governance, including per-environment cost estimates and budget controls, which you would add with a separate tool
- Hosted state storage, since Atlantis keeps no permanent state and you must run and back up your own backend
- Built-in policy and approval workflows beyond what your Git host and custom Atlantis workflows provide
Confirm each item against the current Atlantis documentation and your env zero contract, then decide which gaps your teams need to cover.
Primary sources to check before deciding
Start with the Atlantis guide and the Atlantis requirements documentation before you commit to a design, because they define what Atlantis expects from your repositories, your state backend and your pull request platform. The requirements page is where you confirm which state backend types Atlantis supports (it excludes local state, since Atlantis has no permanent storage and does not commit state back to version control), which Terraform versions you can pin per repository, and whether your pull request host is on the supported list. Check the Atlantis guide for the plan and apply comment workflow, and the lock behavior that holds a directory or workspace until the pull request is merged or the lock is deleted.
Next, read the Atlantis blog post on integrating with OpenTofu. It describes installing the tofu binary in an init container, using a custom workflow and setting ATLANTIS_TF_DOWNLOAD to false. Treat it as a worked example from May 2024, not a current reference. Confirm the exact binary handling, workflow syntax and environment variable names against the Atlantis version you plan to run, since the project publishes new releases regularly and the behavior of custom workflows can change between them.
Then work through the OpenTofu migration guide and the OpenTofu state and plan encryption documentation. The migration guide's warning about configurations that share data through terraform_remote_state is the item most likely to change your plan, so check every workspace for that data source before you cut over. The encryption documentation determines whether state and plan files are encrypted client-side before they reach your backend, and which key provider (such as AWS KMS, GCP KMS or OpenBao) your team must operate. Confirm the provider list and configuration keys against your OpenTofu version, because compatibility and feature support depend on the release you pin.
How DeployOpen helps teams evaluate and implement Atlantis
DeployOpen plans, implements, hardens, backs up and documents a self-hosted Atlantis deployment inside your own infrastructure, under a fixed-scope written agreement. Before any installation, the scope should name the repositories and Git platform in use (GitHub, GitLab, Gitea, Forgejo, Bitbucket or Azure DevOps), the Terraform or OpenTofu versions each project pins, the state backend for each environment, and the deployment target you choose from the supported options such as Kubernetes with the Helm chart, Docker or AWS Fargate. Those inputs determine the atlantis.yaml layout, the workflow for each directory or workspace, and the webhook and credential design. Agreeing them in writing turns the evaluation into a defined set of deliverables rather than an open-ended project.
The hardening and documentation work covers the controls that a plan-and-apply service needs to be trusted. That includes how the Atlantis service account is scoped in each cloud account, how webhook secrets and provider credentials are stored, which pull request approvals gate atlantis apply, how locks are cleared when a pull request is closed without merging, and how the state backend is backed up and versioned. If you adopt OpenTofu, the scope should also decide whether state and plan encryption through a key provider such as AWS KMS is configured. DeployOpen prepares these systems and the evidence for them, while independent auditors and certification bodies decide whether they meet any framework you are assessed against.
Ongoing support, upgrades and continuous testing are available as retainers, which matters because Atlantis releases move. Ask for the upgrade process in writing: who tests a new release against your workflows, how the rollback is handled, and who approves the change. Retainer scope should also state whether it covers the things Atlantis does not provide, such as environment lifecycle, cost governance or state hosting, and how those gaps are filled. Confirm the current release and compatibility details directly with the Atlantis project before you size the work, since those details change.
