Scalr vs Atlantis: which fits teams that mostly run plans and applies from pull requests
Atlantis fits when pull requests are the main control surface for Terraform or OpenTofu and your team already has state storage it trusts. It runs terraform plan or tofu plan when a pull request opens, comments the output back, and runs an apply when someone comments atlantis apply. If your Scalr use is mostly that loop, Atlantis covers the core workflow with a single application you run in your own infrastructure. The decision turns on what you use beyond the loop. Atlantis does not host state, offer a module registry or provide a workspace UI, so teams that depend on those features need a different plan.
Choose Atlantis when your reviewers work in Git, your repositories map cleanly to directories or workspaces, and your state already lives in a supported remote backend. Its locking holds a directory or workspace until the pull request is merged or the lock is deleted, which covers the most common collision risk. Check whether you need policy gates before apply. Atlantis can run conftest checks as part of a custom workflow, but you must write and maintain those steps yourself. Ask your team which Scalr policies, approvals and run history they actually rely on, because each one needs an owner in an Atlantis setup.
Choose a run platform with a UI, such as Terrakube, when you need workspace views, centralized variables, a private module registry, or run history outside pull request threads. Confirm with each vendor and in your own environment what state hosting, identity and audit features each option gives, since Atlantis documents none of these as built in. Before you commit, run a trial on one non-production repository: check that plans post to the pull request, that locks release on merge, and that the state backend works with your OpenTofu version, following the OpenTofu migration guide if you are moving off Terraform.
Which option fits which team setup
This table matches common team setups to the option that fits them better, Scalr or self-hosted Atlantis. Read each row against your Git host, where state lives and how many people can run a service. The main takeaway is that Atlantis suits teams whose review workflow already lives in pull requests, while needs for a workspace UI or minimal operations work point toward Scalr.
| Team setup | Better fit | Reason |
|---|---|---|
| Reviews all infrastructure changes in GitHub, GitLab or Forgejo pull requests | Atlantis | Atlantis runs plans from pull request webhooks and posts output as comments, so review stays in the tool engineers already use. |
| Wants a UI for run history, approvals and workspace views | Scalr | Atlantis has no workspace UI, so run history lives in pull request comments and logs. Confirm the UI and approval features you need in Scalr's documentation. |
| State already sits in its own cloud account (S3, GCS or Azure Blob) | Atlantis | Atlantis supports every Terraform state backend except local state, so state stays where it is and is not committed to version control. |
| No platform engineers available to run another service | Scalr | Atlantis is a service your team hosts, upgrades and monitors. Without an owner for that work, a managed platform reduces operating load. |
| Regulated data residency rule for plan output and state | Atlantis | Atlantis runs in your infrastructure, but confirm where your Git host stores PR comments, since plan output can include sensitive values. |
| Standardizes on OpenTofu across several repositories | Atlantis | Atlantis documents running OpenTofu with a custom workflow, and supports different tool versions per repository or project. Confirm the version pinning in your own setup. |
Capabilities side by side: Scalr against Atlantis
This table compares the capability areas that matter when Scalr is used mainly for pull request plans and applies against Atlantis, which runs in your own infrastructure. Read each Atlantis cell as a supplied fact and each Scalr cell as a prompt to confirm current behavior with Scalr before you decide. The main takeaway is that Atlantis covers the pull request workflow well but does not replace state hosting, a module registry or a workspace UI.
| Capability | Scalr | Atlantis |
|---|---|---|
| Pull request plan and apply | Runs are triggered from VCS-connected workspaces. Confirm how plan and apply comments and approvals behave for your workflow. | Plans on pull request webhooks and comments output back. A comment of atlantis apply runs terraform apply and posts the output. |
| Locking | Confirm how Scalr serializes concurrent runs against the same workspace. | Locks a directory or workspace until the pull request is merged or the lock is deleted. |
| State handling | Scalr hosts state for its workspaces. Confirm state storage, access controls and migration paths with Scalr. | Supports all Terraform state backend types except local state. It does not store state itself or commit state files to version control. |
| Policy checks | Confirm which policy engines and enforcement points Scalr offers and how they attach to runs. | Policy checks are added through custom workflows, for example with conftest. Plan the policy tooling and its ownership yourself. |
| Forge support | Confirm which VCS providers Scalr connects to in your edition. | GitHub, GitLab, Gitea, Forgejo, Bitbucket Cloud, Bitbucket Server and Azure DevOps. |
| Terraform and OpenTofu support | Confirm current support for OpenTofu alongside Terraform in Scalr. | Supports all Terraform versions including 0.12, and documents running OpenTofu by installing the tofu binary in an init container. |
| Module or provider registry | Scalr includes registry capabilities. Confirm what it provides and whether you need it for private modules. | Not provided. Pair Atlantis with a separate module source or registry if you need private modules. |
| Workspace UI and run history | Scalr provides a web console for workspaces and runs. Confirm history retention and search in your edition. | Not provided as a workspace UI. Run history lives in pull request comments and your logs, so plan how audit records are kept. |
| Deployment and licensing | Commercial SaaS billed per run. Confirm deployment options for self-hosted use with Scalr. | Apache 2.0 licensed, v0.48.1 released October 7, 2026. Deploys via Helm chart, Kubernetes manifests, Kustomize, OpenShift, AWS Fargate, Google Kubernetes Engine, Docker or a custom install. |
How Atlantis policy checks and locking change the review step
Atlantis locks a directory or workspace from the moment a plan runs until the pull request is merged or the lock is deleted. That lock is the main behavioral change for reviewers. While one pull request holds the lock on a stack, a second pull request that touches the same directory or workspace cannot apply over it, so two overlapping changes cannot race each other into the same state file. In Scalr, the equivalent protection comes from its run queue and workspace concurrency. Teams should confirm in the Atlantis guide exactly when a lock is released, how a stale lock is deleted, and who is allowed to delete one, because a forgotten lock will block every later change to that stack until someone clears it.
Policy checks sit between the plan and the apply. Atlantis runs the plan, then a custom workflow can pass the plan output to a policy tool such as conftest, which evaluates Open Policy Agent rules written in Rego against the plan in JSON form. If a rule fails, the workflow can stop the apply step from running, so the reviewer sees the denial in the pull request before anyone types atlantis apply. The exact wiring is not a built-in switch. It lives in the workflows and steps sections of atlantis.yaml, and the conftest installation, policy bundle location and failure behavior depend on how your team writes that file. Confirm the layout against the Atlantis documentation before you rely on it as a gate.
This matters most in two cases: teams where several engineers routinely open pull requests against the same stack, and teams that must show a written policy as code control before infrastructure changes reach production. If neither applies, locking and a required review may be enough. If either applies, test the gate on a throwaway repository first. Deliberately open two overlapping pull requests and confirm the second is blocked, then open a plan that violates one policy and confirm the apply is refused. Compare the results with your current Scalr OPA setup, record which rules you must port, and keep the test evidence with your change records.
What Atlantis does not provide and what you would build or buy
Atlantis runs plans and applies from pull requests and nothing more. The gaps below are what Scalr users often rely on without noticing, and each one needs an owner before you switch. Confirm each item in your own environment before you decide.
State hosting and locking
Atlantis does not store state. You point each project at a remote backend, such as an object store with a locking mechanism, and your team owns its encryption, versioning, access policy and backups. This matters most if Scalr currently hosts state for you. Confirm which backend your state will use, who can read it, how it is backed up, and whether your OpenTofu or Terraform version supports the locking you need. Consider OpenTofu state encryption if state contains secrets.
Module registry
Atlantis has no private module registry. Teams usually reference modules from Git sources pinned to tags or commits, or run a private registry alongside the stack. Scalr's registry features will not come across automatically. Confirm which modules are shared across teams, how versions are published and approved, and whether your modules must be available offline in an air-gapped network.
Workspace UI and run history
Atlantis reports through pull request comments and job logs, not a dashboard of workspaces, runs and environments. Anyone who needs a cross-workspace view must build one from logs or buy a separate observability tool. This matters for auditors and platform leads who want to see what changed where. Confirm where logs are retained, how long pull request comments persist in your forge, and who can search them.
Access control beyond the forge
Atlantis relies on the permissions of your forge for who may comment and merge, and it applies its own server-side settings. It does not provide Scalr-style role grants per environment or per workspace. Plan how approvals, required reviewers and apply commands map to your change management process. Confirm which forge roles can trigger apply, how the Atlantis service account is scoped in each cloud account, and how you revoke access.
Drift detection and scheduled runs
Atlantis runs plans when a pull request is opened or a comment is posted. It does not schedule plans to find drift between code and live infrastructure. If you rely on scheduled runs in Scalr, you need an external scheduler that triggers plans and reports results to a channel you monitor. Confirm how often drift must be detected, who reviews the output, and whether a failed scheduled run is noticed.
Cost reporting
Atlantis does not report cost or resource usage per team or project. Per-run billing ends with Scalr, so you should expect to measure the platform and its runners directly. Confirm which infrastructure costs you need to attribute, how you tag resources, and whether finance needs chargeback reports. Infrastructure costs remain yours either way, and a cost tool is a separate purchase or build.
Where state, logs and credentials live under each model
With Scalr, the vendor runs the control plane, and your runs execute on infrastructure and agents you connect to it. Confirm with Scalr exactly where state files, plan output and logs are stored, which regions they can be pinned to and how long each is retained, because the answers depend on your contract and configuration.
- State and plan output. Confirm whether state is held in the vendor's service or in an external backend you control, and who can read plan output inside the platform.
- Cloud credentials. Provider credentials are stored in the service, so ask how they are encrypted, where the keys are held and which vendor staff can access them.
- Audit logs. Ask for the export format, the retention period and whether logs can be sent to your own SIEM.
- Patching. The vendor applies platform updates on its own schedule, so your team mainly tracks release notes and the agent versions you run.
- Identity. Confirm whether SSO, group mapping and role assignments are included in your plan.
Get these answers in writing before you compare them with the self-managed model.
Atlantis runs as a standalone application in your infrastructure, so the server, its working directories and its credentials sit where you place them. The deployment documentation lists a Kubernetes Helm chart, Kubernetes manifests, Kustomize, OpenShift and Google Kubernetes Engine among its options, and the project publishes the image ghcr.io/runatlantis/atlantis.
- State. Atlantis does not host state. It supports every Terraform state backend except local state, so state stays in the backend you configure, such as a cloud bucket or a self-managed store.
- Plan output. Plan results are posted as pull request comments, so review who can read those repositories as well as who can read cluster logs.
- Cloud credentials. Credentials reach the pod through Kubernetes secrets or workload identity. Confirm which method your cluster supports and limit each role to the projects Atlantis applies.
- Audit logs. Atlantis writes server logs and the forge records comments and approvals. Collect both in your logging stack, since retention is set by you.
- Patching. Your platform team pulls new image tags, tests them and rolls the deployment, so patching is an internal responsibility.
Confirm the chart version, the secret source and the log destination with your platform team before the first apply.
For smaller footprints, the same image can run under Docker or on AWS Fargate, both of which appear in the deployment documentation. A container model removes the cluster layer, so secret handling, scheduling and health checks move to whoever operates the host or task platform.
- State. State still lives in your remote backend. Atlantis keeps no permanent storage of its own, so a container restart does not affect the state record.
- Plan output. Comments go to the forge. The container's working space is disposable, so do not treat plan files on the container as a durable record.
- Cloud credentials. Environment variables or task roles hold cloud access. Check that each role is scoped to the workspaces it applies.
- Audit logs. Ship container output to a central store, because logs kept only inside a stopped container are lost.
- Patching. Your team pulls or rebuilds the image, redeploys it and records the version each environment runs.
Ask who owns host patching and log shipping, because those tasks sit outside the Atlantis project.
The documentation also covers custom installs on virtual machines or bare metal, which suit teams with a standard build pipeline and their own operating system baseline. You own every layer, from the operating system and the OpenTofu binary to the process supervisor and the TLS termination in front of the webhook endpoint.
- OpenTofu binary. Install the
tofubinary yourself and setATLANTIS_TF_DOWNLOADtofalse. The Atlantis OpenTofu integration post shows this pattern with a custom workflow. - State. The same remote backend rules apply, and the host should not keep state files on local disk.
- Cloud and forge credentials. Store forge tokens and cloud credentials in the host secret store, and restrict read access to the service user.
- Audit logs. Forward application and system logs, and keep the webhook delivery records from your forge.
- Patching. Track Atlantis, OpenTofu and operating system updates separately, because each has its own release cycle.
Document the upgrade path for each component before go-live, so a change in one does not surprise the others.
Data residency and compliance questions usually come down to where state, plan output, credentials and logs are stored and who can reach them. In the self-managed model, your team answers those questions with evidence from your own systems. DeployOpen prepares the controls and evidence for an assessment, but independent auditors, not DeployOpen, issue any attestation.
- Residency. Map each data type to a region and account you control. This is readiness work, and the legal conclusion stays with your counsel and assessor.
- Encryption. OpenTofu can encrypt state and plan files with key providers such as AWS KMS, GCP KMS and OpenBao. Evaluate these options if you adopt OpenTofu, using the OpenTofu state encryption documentation.
- Access evidence. Keep records of who can trigger apply, who approves changes and which identities hold cloud roles.
- Log retention. Set retention for server logs and forge records to match the policy your assessor expects.
- Vendor evidence. For Scalr, request the vendor's own assurance documents and confirm their scope covers the data you plan to send.
Ask your assessor which control evidence they need before you choose between the two models.
What you pay for under each option, and what drives it
Scalr bills per run, so the first cost question is what counts as a run. Ask Scalr in writing which operations are metered, whether dry runs (plans that are not applied) count toward your allowance, how drift detection or scheduled runs are treated, and whether the plan tier or number of environments changes the rate. Ask for a sample invoice based on your last quarter of pull request activity, not a published example. Your recurring cost rises with the number of pull requests your teams open, because every push that triggers a plan is a candidate run. Also confirm what happens to unused allowance and how overages are invoiced, since those terms decide whether the bill scales smoothly or in spikes.
Atlantis itself costs nothing to license, since it is Apache 2.0 licensed, so the spend moves to components you already see on an invoice. The one-time costs are the setup work: deploying Atlantis with one of its documented methods (for example, the Kubernetes Helm chart or Docker), writing the atlantis.yaml file for each module, workspace and tfvars layout, building the server-side workflows, configuring the webhook and the forge integration, and wiring policy checks. Recurring costs are the container or cluster capacity, the state backend and its storage and access, cloud accounts used for plans and applies, forge seats, and the engineering time spent on upgrades (the project's releases, including v0.48.1, need to be tested against your Terraform or OpenTofu versions), on-call response when a lock stalls or an apply fails, and secret rotation for the credentials Atlantis holds.
Ask for a quote built from components, not a single platform fee. For the self-hosted side, request the hosting estimate for the cluster or containers and the state backend in your own accounts, the expected forge seat count, the number of hours you assume for initial setup and for each quarterly upgrade, and the on-call model you will use. For Scalr, request the metering definition in writing and an estimate that covers dry runs. Compare both over the same period and the same pull request volume. Remember that a self-hosted deployment is only as cheap as the people who run it, so record who will own Atlantis after go-live and whether that time is already budgeted. If you want an outside estimate of setup and support effort, DeployOpen prepares a fixed-scope written proposal after reviewing your repositories and environments.
How a move from Scalr to Atlantis is staged
The sequence keeps state where it already lives, proves Atlantis on one repository, and then moves the remaining repositories over one at a time. Each step closes with a check the team can verify before the next one starts.
Inventory workspaces and their state backends
The platform team lists every Scalr workspace that Atlantis will run, with its repository, working directory, Terraform or OpenTofu version, variables, and the backend block that stores its state. The team also records which configurations read another workspace's outputs through the terraform_remote_state data source, because those consumers need separate handling. The inventory is done when every workspace has one row and every row names its backend and its downstream readers.
Keep state where it already lives
Atlantis does not change the state backend, so existing remote state stays in place and the backend blocks in each configuration remain as they are. Teams confirm that the Atlantis runner can reach each backend with credentials scoped to that workspace, and they avoid local state, which Atlantis does not support. The step is complete when a plan run from a test branch reads the existing state and reports no unexpected changes.
Write atlantis.yaml for each project
Each directory or workspace that Atlantis should plan gets an entry in the repository's atlantis.yaml, covering its path, workspace name, the Terraform or OpenTofu version, and any custom tfvars files or workflow steps. Repositories that use modules or several workspaces per directory need explicit project definitions. The step is complete when a pull request touching one project produces a plan comment for that project alone.
Deploy Atlantis in a test namespace
The team installs Atlantis in the customer's own cluster or host, using one of the supported deployment methods, and connects it to a single test repository through the forge's webhook and a bot account. Credentials for cloud providers and state backends are supplied from the platform's secret store rather than stored in the repository. The step is complete when a pull request webhook reaches Atlantis, a plan comment appears, and an atlantis apply on a test change records its output.
Move policy checks and forge permissions
Scalr OPA policies are ported to the checks Atlantis runs, typically conftest policies executed against the plan output in a custom workflow, and the team confirms each check still blocks the cases it blocked before. Approval rules move into forge branch protection and code owner review, and the people allowed to comment apply are set explicitly. The step is complete when a deliberately failing test plan is blocked by the policy check and an unapproved apply is refused.
Cut over repository by repository
Each repository is switched from Scalr runs to Atlantis in a planned order, starting with low-risk configurations and leaving shared networking or identity stacks for later. For every repository, the team disables the Scalr trigger, confirms the Atlantis plan matches the last Scalr plan, and records the lock behavior for the team. The step is complete for a repository when its first real change has been planned and applied through Atlantis and the Scalr workspace has no pending runs.
Confirm OpenTofu compatibility and test migration guidance
Teams that plan to run OpenTofu follow the OpenTofu migration overview, which describes backing up state and code, installing OpenTofu, initializing and verifying the configuration, and testing with a small change. Where Atlantis runs the tofu binary, the team checks the version and download settings against the Atlantis OpenTofu guidance before the first cutover. The step is complete when a test workspace plans cleanly under OpenTofu on the same backend.
Questions buyers ask before choosing Atlantis over Scalr
Can Atlantis replace Scalr if we only use it for plans and applies?
For pull request plans and applies, Atlantis covers that core workflow. It listens for pull request webhooks, runs terraform plan and comments the output on the pull request, and runs 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 changes from applying to the same target at once. Confirm that your Scalr usage stops at these functions. If you rely on environments, run history, drift views, or a workspace UI, those need a separate plan, because Atlantis does not provide them.
What does our team need to run Atlantis?
Your team needs someone who can deploy and maintain a standalone application in your own infrastructure, plus a Git host that Atlantis supports. The Atlantis documentation lists GitHub, GitLab, Gitea and compatible forks such as Forgejo, Bitbucket Cloud, Bitbucket Server and Azure DevOps. Deployment options include a Kubernetes Helm chart, Kubernetes manifests, Kustomize, OpenShift, AWS Fargate, Google Kubernetes Engine, Docker and custom installs. You will also write an atlantis.yaml file for modules, workspaces or custom tfvars layouts, and manage webhook secrets, credentials for each cloud account, and version upgrades.
Can we run Atlantis ourselves, or do we need outside help?
Many teams with existing Kubernetes or container operations can run Atlantis without outside help, provided they have people who own the Git webhook setup, cloud credentials and upgrades. Outside help is most useful when the migration spans many repositories, when access controls must be designed to satisfy internal audit, or when no one on staff has time to maintain the deployment. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, usually under a fixed scope agreed in writing before work starts, and offers ongoing support as a retainer.
How long does a migration from Scalr to Atlantis take?
The duration depends on the number of repositories, directories and workspaces, how many Scalr workflows you need to recreate in atlantis.yaml, how variables and cloud credentials are moved, and how many teams must approve the new process. No timeline figure is given here because it varies widely by estate. For an estimate, list your repositories, workspaces, and Scalr policies, then ask any implementation partner for a fixed-scope plan with deliverables and dates agreed in writing before work starts.
Does Atlantis work with OpenTofu?
Yes, the Atlantis documentation and its May 2024 blog post describe running OpenTofu with Atlantis. The approach installs the tofu binary in an init container, sets ATLANTIS_TF_DOWNLOAD to false, and uses a custom workflow. OpenTofu is licensed under the Mozilla Public License 2.0 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 test each upgrade on a non-production repository before rollout. The current OpenTofu release listed is v1.13.1, released on October 1, 2026.
What happens to our Terraform state when we move to Atlantis?
Atlantis does not host state. It supports every Terraform state backend type except local state, because it has no permanent storage and does not commit state files to version control. Your state stays in the backend you already use, such as an S3 bucket or a Terraform remote backend. The state you pull from Scalr or HCP Terraform must be moved to that backend before cutover, and each workspace's backend configuration must point to it. OpenTofu can also encrypt state and plan files client-side with key providers such as AWS KMS, GCP KMS, OpenBao and Azure Vault, which is a useful control to evaluate for regulated data.
Do we need a workspace UI or module registry with Atlantis?
Atlantis does not provide a workspace UI, state hosting or a module registry. Pull request comments and the logs of the Atlantis service are your main views into plans and applies. If your teams depend on a web view of workspaces, run history, or private modules, plan for a separate tool for each. Options include the OpenTofu Registry for public providers and modules, which lists more than 3,900 providers and 23,600 modules, and a self-hosted registry or Git-based module sourcing for private code. Confirm which of these your teams actually use before you decide.
What does a fixed-scope Atlantis engagement cover?
A fixed-scope engagement covers the agreed deliverables, which typically include deploying Atlantis in your infrastructure, connecting your Git host and webhooks, writing atlantis.yaml for your repositories, configuring state backends and credentials, testing plan and apply flows, hardening the deployment, documenting the setup and handing it over. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask for the written scope to list which of these items are included.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Scalr vs Atlantis evaluation, we start by mapping which pull request workflows you actually run in Scalr, then build and hand over an Atlantis deployment that fits your environment.
How we scope
- We list the pull request plan and apply workflows, repositories and VCS providers that Atlantis would need to cover.
- We confirm which state backends, Terraform or OpenTofu versions and policy checks each repository depends on today.
- We document what Atlantis will not replace, such as state hosting, a module registry and a workspace UI, so the gaps are agreed up front.
How we build
- We deploy Atlantis in your infrastructure using the deployment method your platform team already runs, such as Kubernetes or Docker.
- We write atlantis.yaml files and set up conftest policy checks and locking behavior, then test them against non-production repositories.
- We run a parallel trial on selected pull requests and record plan output, apply results and any differences from current Scalr runs.
How we hand over
- You receive configuration, deployment manifests, policy files and runbooks covering lock handling and credential rotation.
- We walk your engineers through the pull request workflow, including how to recover from a stuck lock or failed apply.
- We agree the handover checklist and written acceptance criteria before the engagement closes.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades of Atlantis and its images, and continuous testing are available as a retainer.
- For a quote, ask for the written scope, the list of repositories included, and the support terms that apply after handover.
