HCP Terraform vs Atlantis: which fits your review workflow
Teams that already review infrastructure changes in pull requests and mainly want plans posted for review and applies gated by approval should look at Atlantis first. Teams that need a hosted run UI, a private registry and managed state in one place should look at a platform such as Terrakube, or keep HCP Terraform. The decision turns on whether you need a run UI, registry and managed state, or only pull request plans and applies. Atlantis runs terraform plan when a pull request webhook arrives, comments the output back, and runs apply when someone comments atlantis apply. It locks a directory or workspace until the pull request is merged or the lock is deleted, which is the control most review-driven teams are paying HCP Terraform for in the first place.
Before you choose, confirm three conditions. First, whether your version control system is one Atlantis supports, such as GitHub, GitLab, Gitea or Forgejo, Bitbucket, or Azure DevOps, as listed in the Atlantis requirements documentation. Second, whether you can run a state backend other than local state, because Atlantis does not keep state and will not commit it back to version control. Third, whether you need a registry, workspace UI or per-workspace variables managed in a web console. Atlantis provides none of these, so each one becomes work your team owns, whether that means atlantis.yaml for modules and workspaces or separate tooling for the registry. Ask any vendor or integrator quoting the move to show how each of these gaps is closed, and confirm the choice against your own environment before cancelling a paid plan.
Which option fits which team
This table maps common team situations to the better fit between HCP Terraform and Atlantis, with the reason tied to Atlantis requirements and the HCP Terraform model. Read each row against your own review workflow, state location and policy tooling, and treat a Terrakube or other run platform as the next option to check when a row points away from Atlantis.
| Team situation | Better fit | Reason |
|---|---|---|
| PR-driven plans with directory locking and plan output in comments | Atlantis | Atlantis runs terraform plan on pull request webhooks, comments the output, and locks a directory or workspace until the pull request is merged or the lock is deleted. |
| A hosted workspace UI and private registry for the whole organization | HCP Terraform | Atlantis has no registry, workspace UI or managed state, so modules and run history must come from other tools you operate. |
| Strict data residency that rules out sending state to a SaaS | Atlantis | Atlantis runs inside your infrastructure, but you must choose a remote state backend you control, since local state is not supported. |
| Reliance on Sentinel policy checks | HCP Terraform | Sentinel is native to HCP Terraform, so moving to Atlantis means translating policies and adding a separate check such as conftest. |
| Git host is GitHub, GitLab, Gitea, Forgejo, Bitbucket or Azure DevOps | Atlantis | Atlantis supports these hosts, so pull request review can stay on the platform your team already uses. |
| Need to run OpenTofu with a custom workflow | Atlantis | The Atlantis blog describes running the tofu binary through an init container and a custom workflow with ATLANTIS_TF_DOWNLOAD set to false, which requires platform engineering time. |
| Multiple Terraform versions across repositories | Atlantis | Atlantis supports different Terraform versions per repository or project, configured through an atlantis.yaml file. |
Capabilities compared side by side
This table compares HCP Terraform with Atlantis capability by capability, from pull request plan comments and locking to registry, state and identity. Read each row as what HCP Terraform provides, what Atlantis provides or leaves to your team, and what you must confirm in your own setup. Atlantis covers the pull request workflow well but is not a full replacement for a hosted run platform.
| Capability | HCP Terraform | Atlantis |
|---|---|---|
| Plan output on pull requests | Plan results are shown in the hosted run UI and can be linked to VCS pull requests through the VCS connection. | Runs terraform plan on pull request webhooks and posts the output as a comment on the pull request. |
| Apply on command | Runs are triggered from the UI, the CLI, the API or VCS events, with approval steps before apply. | Commenting atlantis apply on the pull request runs terraform apply and posts the output back. |
| Locking | Workspaces are locked during runs managed by the platform. | Locks a directory or workspace until the pull request is merged or the lock is deleted. Confirm how lock cleanup works for abandoned pull requests in your setup. |
| Hosted run UI | Provides a web interface for run history, logs, workspace status and approvals. | No workspace UI. You rely on pull request comments and the logs of the Atlantis service in your cluster or host. |
| Workspace management | Organizations, workspaces, teams and variables are managed in the platform. | Workspaces are defined in atlantis.yaml and the repository. Variables and team access must be managed through your Git host and your own secret tooling. |
| Module and provider registry | Includes a private registry for modules and providers. | No registry. Modules are referenced from Git or your own artifact store, and providers come from public registries. Confirm your module sourcing plan before migration. |
| Managed state storage | Stores state versions for each workspace and exposes them through the state versions API. | Does not store state. You must configure a remote backend such as S3 or GCS. Atlantis supports all Terraform state backend types except local state, so the backend is your responsibility to provision, back up and secure. |
| VCS support | Integrates with major VCS providers through its VCS connections. | Supports GitHub, GitLab, Gitea and compatible forks such as Forgejo, Bitbucket Cloud, Bitbucket Server and Azure DevOps. Confirm your exact Git host version and webhook setup. |
| Policy checks | Includes built-in policy checks in the platform run flow. | No built-in policy engine. Policy checks such as conftest on the plan must be added through custom workflows, and override approval must be designed by your team. |
| Identity and access | Uses HCP Terraform user accounts, teams and SSO options offered by the platform. | Access is governed by your Git host permissions and the Atlantis server configuration. Confirm how approvals and who may run apply are enforced in your environment. |
Where data lives and who controls it
Moving from HCP Terraform to Atlantis changes where plans, state and run logs sit, and who answers for them. Each card below covers one place where that responsibility moves, and what to confirm before you cut over.
Where state and run data sit
HCP Terraform stores workspace state, plan logs and run history on HashiCorp's hosted service. With Atlantis, the application runs in your infrastructure, but it keeps no permanent storage and does not commit state to version control. State therefore lives in the backend you choose, such as S3 or GCS, under your own accounts. Confirm which region and account hold each state file before you migrate.
Hosting models you can choose
Atlantis is deployed as a standalone application in your environment. Supported paths include a Kubernetes Helm chart, Kubernetes manifests, Kustomize, OpenShift, AWS Fargate, Google Kubernetes Engine, Docker and custom installs. The hosting choice decides which team patches the platform, where the webhook endpoint is exposed and which network the runners reach. Document that choice in your architecture record.
State backend ownership
With HCP Terraform, HashiCorp operates the state store, its encryption at rest and its versioning. With Atlantis, your team owns the backend, its access policy, its backup and its versioning settings. OpenTofu can also encrypt state and plan files client-side with key providers such as AWS KMS, GCP KMS or OpenBao, so keys can stay under your control. Ask who holds the key and how rotation is recorded.
Cloud credentials and secrets
HCP Terraform keeps workspace variables, including cloud credentials, in its own service. Atlantis reads credentials from the environment of the host it runs on, usually through a workload identity or a secrets manager you operate. Plans and applies run with those credentials, so scope them per repository or directory. Confirm that no credential is printed in plan comments on pull requests.
Logs, access and approvals
Pull request comments, Atlantis server logs and your Git host's audit trail become the record of who planned and applied each change. HCP Terraform keeps run history in its own console. With Atlantis, you decide how long server logs are retained, where they are shipped and who can comment apply. Verify that logs are centralized and that apply rights follow your change approval policy.
Compliance evidence and our role
Controls such as access reviews, log retention and key management must be shown to an assessor for regulated work. DeployOpen can plan, configure and document these controls and gather the evidence for an assessment. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm the scope with them early.
Why Atlantis requires a remote state backend
Atlantis needs a remote state backend for every workspace because it has no permanent storage of its own and does not commit state files back to version control. The Atlantis requirements documentation supports every Terraform backend type except local state, so the first decision in an HCP Terraform exit is which backend will hold state after the migration. Common choices are an S3 bucket or a Google Cloud Storage bucket, but the right answer depends on where your cloud accounts, access policies and recovery procedures already live. Confirm the backend choice with your platform team before any plan runs against production.
In HCP Terraform, state storage, versioning, locking and access control come bundled with the service. With Atlantis, your team owns each of those controls. You choose the bucket or container, set encryption and access policies, enable versioning so earlier states can be restored, define backup and retention rules, and confirm that the locking mechanism your backend provides works with Atlantis's directory and workspace locks. Write these ownership items into the migration plan as named tasks with an owner, because a missed backup or an overly broad read permission on state will not surface as an error.
State files often contain sensitive values such as database passwords and generated keys, so the backend is a high-value target. OpenTofu can narrow that exposure by encrypting state and plan files at rest with key providers including AWS KMS, GCP KMS and OpenBao, so the stored object is ciphertext unless the caller holds the right key. This does not replace bucket access controls, and encryption configuration must be tested with your Atlantis workflow before you rely on it. Ask your security team which key provider fits your key management policy, and verify that the Atlantis service account can decrypt state and plans but that engineers without a need cannot.
What each option costs to run and what drives it up
HCP Terraform bills paid tiers per managed resource, so the invoice follows how much infrastructure your workspaces manage. Seat counts matter less, which makes resource growth the main cost driver to model before you commit. The rates below are the list prices on the HashiCorp pricing page, and they are the starting point for any comparison.
- Essentials: listed at $0.10 per resource per month, the lowest paid rate on the pricing page.
- Standard: listed at $0.47 per resource per month.
- Premium: listed at $0.99 per resource per month, the highest paid rate listed.
- Enhanced Free tier: after the legacy Free plan ended on March 31, 2026, remaining organizations moved to up to 500 managed resources with unlimited users, so a team under that count pays no resource charge on the Free tier.
- Growth drivers: module designs that create many resources per workspace, the number of environments that duplicate the same resources and the number of workspaces all raise the managed resource total.
Ask HashiCorp to confirm in writing how managed resources are counted for your configurations, and model the count across every environment, not only production.
Terraform Enterprise is the self-managed edition of HCP Terraform, priced on custom terms. Its costs sit mostly in your own infrastructure and in staff time, and the license is quoted, so the first questions are what the quote covers and how it renews. Treat the license as one line among several rather than the whole cost.
- License: custom pricing set by HashiCorp, so get the scope, term, pricing basis and renewal terms in writing before comparing it with any open-source option.
- Hosting: compute, database, object storage and networking for the installation, billed by your cloud provider or data center.
- Operations: someone must patch, back up, upgrade and monitor the installation, which is recurring staff time that does not appear on the license quote.
- Upgrades and support: plan for the effort of each product upgrade, the support tier you need during an incident and any testing in a non-production installation first.
- Exit effort: moving state, workspaces and VCS connections off the installation takes effort that grows with the number of workspaces and integrations you run.
Ask the vendor to state the pricing basis used in the quote and what happens to the price if your managed resource count grows during the term.
Atlantis is licensed under Apache 2.0, so the software itself carries no license fee. Its recurring costs are the infrastructure that runs the Atlantis service and the state backend that holds Terraform state, both of which you provision and pay for in your own accounts. The Atlantis deployment documentation lists the hosting options that drive this part of the bill.
- Compute: Atlantis runs as a standalone application in your infrastructure, through options such as a Kubernetes Helm chart, AWS Fargate, Google Kubernetes Engine or Docker, each with its own node or task cost.
- State storage: Atlantis supports every Terraform state backend type except local state, so you pay for a remote backend such as object storage plus any locking and encryption services you choose.
- Networking and secrets: the service needs a reachable webhook endpoint, credentials for your version control host and cloud credentials for plans and applies, each of which needs management effort.
- Logging and backups: plan output, apply logs and backups of state add storage and retention costs that grow with the volume of pull requests.
- Upgrades: track releases such as v0.48.1 on the Atlantis releases page and budget time to test each upgrade in a non-production repository first.
Ask whether any quote covers sizing for your repository count, the state backend you select and the test environment needed before each upgrade.
Most Atlantis cost is people time, not software. Each pull request moves through plan, review and apply, and someone has to write the workflows, own the approvals and keep the platform running. These costs recur, and they grow with the number of repositories, projects and reviewers involved in infrastructure changes.
- Platform engineers: staff who install, configure, secure and maintain Atlantis, including the
atlantis.yamlfiles that define modules, workspaces and custom tfvars layouts. - Review cycles: reviewers read plan output in pull request comments before an apply, so review time per change scales with change volume and the approval rules you set.
- Custom workflows: running OpenTofu through a custom workflow, as described in the Atlantis OpenTofu blog post, adds design and test effort that a standard Terraform setup does not need.
- Setup and migration: one-time work covers the state move, the backend choice and repository configuration, and a fixed-scope engagement sets this work out in writing before it starts.
- On-call and incidents: a failed apply on a shared state backend needs a response path and someone who can delete a stuck lock, so the team needs a documented runbook.
Ask any quote to state the assumed repository count, who owns upgrades after handover and whether a retainer covers upgrades and continuous support.
How a move from HCP Terraform to Atlantis runs
This sequence takes each workspace's state and configuration out of HCP Terraform, places it on a backend Atlantis can use, and ends with pull request plans running from your own infrastructure. Each step produces a check you can confirm before the next one starts.
Inventory workspaces, state and dependencies
Platform or infrastructure owners list every HCP Terraform workspace, its Terraform version, its backend or cloud block settings, and which other configurations read its outputs. Record which workspaces use the terraform_remote_state data source, because those consumers need extra care when state moves. The step is complete when each workspace has a row in a shared inventory with an owner and a target repository and directory. Illustrative check: a workspace that only reads from another workspace's outputs is flagged before any state moves.
Export current state through the state versions API
Using a token with access to each workspace, the infrastructure team downloads the current state through the HCP Terraform state versions API, using the JSON download URL for states created by Terraform 1.3 or later. Store the exported files in a restricted location and keep a copy of the original state and configuration before any change. The step is complete when each exported file opens as valid JSON and its serial and resource count match what HCP Terraform reports for that workspace. Confirm the exact API calls against the state versions documentation before scripting them.
Provision and configure the state backend
The platform team chooses a remote backend that Atlantis supports, such as S3 or GCS, because Atlantis cannot use local state. They create the bucket, enable versioning, restrict access to the Atlantis service identity and configure locking according to the backend's documentation. Each workspace's exported state is then uploaded to its own key in the bucket. The step is complete when a test
terraform initandterraform planagainst an uploaded state show no unexpected changes from the HCP Terraform baseline.Write atlantis.yaml for modules, workspaces and tfvars
Engineers write an atlantis.yaml file in the repository that maps each project to its directory, Terraform workspace and variable files, and set per-project Terraform versions where they differ. Modules that need separate plans or custom tfvars layouts are declared explicitly, because Atlantis needs this file for those layouts. The step is complete when a draft pull request touching one project shows a plan comment for only that project and no plan for unrelated directories.
Move variables and VCS connections into Atlantis
Teams recreate HCP Terraform variables in the Atlantis environment, storing sensitive values in the secret store the deployment uses and not in atlantis.yaml or repository files. They configure the pull request webhook for the chosen source control system, set who may comment apply, and define approval rules that replace HCP Terraform team permissions. The step is complete when a webhook delivery succeeds, a test plan reads every required variable, and the approval rules are tested against a user without apply rights.
Switch to OpenTofu with a custom workflow
If the team is moving to OpenTofu at the same time, the platform team installs the tofu binary in an init container and defines a custom workflow in the Atlantis server configuration, with ATLANTIS_TF_DOWNLOAD set to false so Atlantis does not fetch Terraform. Because OpenTofu's migration guide advises a backup and a reversible test, the team runs a small change on one non-production project first. The step is complete when that project plans and applies with OpenTofu, and the state it wrote can still be read by the previous binary if a rollback is needed.
Test with a small change and retire HCP Terraform runs
The team opens a pull request that makes a small, reversible change in one project, runs plan, then apply through a comment, and checks the resulting state and resource attributes. Once each project passes this check, the team disables the HCP Terraform workspace's VCS triggers and runs, keeps the exported state archive under the organization's retention policy, and records the new ownership in the runbook. The step is complete when every workspace has one successful Atlantis run and its HCP Terraform run triggers are disabled.
Questions buyers ask before switching to Atlantis
What does switching from HCP Terraform to Atlantis cost in effort, and what drives it?
The switch is mostly internal effort, with infrastructure costs added on top. Atlantis itself is Apache 2.0 licensed, so there is no license fee, but you pay for the hosting it runs on, the state backend you choose, and the staff time to deploy, configure and operate it. The main drivers are the number of workspaces and root modules, how many of them need an atlantis.yaml file, how many repositories and version control systems are involved, and whether the team already runs Kubernetes or another container platform. Ask any vendor or partner for a quote that separates one-time setup (backend, workflows, pipeline integration, state moves) from recurring costs (hosting, storage, upgrades, on-call support). Confirm those line items against your own environment before comparing with your HCP Terraform renewal.
How long does a move from HCP Terraform to Atlantis take?
The duration depends mostly on how many workspaces you have, how tangled their dependencies are, and how many people must approve changes. A team with a few well-structured repositories can usually finish a pilot faster than one with many shared modules and cross-stack data sharing. Each workspace needs its state moved to a supported backend, its variables recreated, and its atlantis.yaml written before it is trusted with atlantis apply. Schedule time for a parallel run period where plans from Atlantis are compared with HCP Terraform output. The Atlantis release cadence does not drive the timeline, but the team's review capacity does. Agree on a timeline in writing with whoever runs the work, and confirm it against an inventory of your workspaces.
What skills and staff time does running Atlantis require?
Your team needs people who can deploy and operate a containerized service, manage cloud credentials, and configure a remote state backend with locking and access control. Someone must own the webhook integration with your pull request platform and the workflow definitions that control plan and apply behavior. Platform engineers, cloud engineers and at least one person who understands Terraform or OpenTofu modules are the usual mix. Ongoing work includes upgrading Atlantis, rotating credentials, reviewing the workflow when new modules or providers arrive, and responding to failed applies. Estimate the staff time by listing who will be on call for the pipeline, not by counting setup hours alone.
Can our own team do the migration without an implementation partner?
Yes, a capable platform team can do the migration in-house, especially if it has run Terraform in pull request workflows before. The work is well documented: back up state and code, move each workspace's state to an S3, GCS or other supported backend, write atlantis.yaml for modules and workspaces, and test with a small change. The risk is in the details: state moves that are not verified, locking that is not configured, and dependencies created by terraform_remote_state that need extra care. If your team lacks time or has not operated a self-hosted pipeline before, an implementation partner can take on part of the work under a written, fixed scope. DeployOpen implements, hardens, documents and supports self-hosted platforms in your own infrastructure, but it does not issue audit reports or certifications.
Does Atlantis replace the HCP Terraform run UI, workspace views and private registry?
No. Atlantis does not provide a hosted run UI, workspace dashboard, private module registry or managed state. Its interface is the pull request itself: plan output appears as comments, and you trigger atlantis apply by commenting on the pull request. Atlantis locks a directory or workspace until the pull request is merged or the lock is deleted, which covers concurrency for reviewed changes. Teams that rely on a workspace browser, run history across many stacks, or a private registry for modules need separate tooling for those, such as a module source in your own Git hosting or a registry product. If those features matter to your operators, compare Terrakube, which includes a private registry and run UI, before choosing Atlantis.
Does Atlantis work with OpenTofu, and what changes in the setup?
Yes, Atlantis documents running OpenTofu. An Atlantis blog post from May 2024 shows installing the tofu binary in an init container and using a custom workflow, with ATLANTIS_TF_DOWNLOAD set to false so Atlantis does not fetch its own Terraform binary. OpenTofu is MPL-2.0 licensed and describes itself as a drop-in replacement for Terraform that preserves existing workflows and configurations, though compatibility with future Terraform releases is not guaranteed. Confirm the OpenTofu version you pin against the release notes on the OpenTofu GitHub releases page, and test state encryption settings separately if you plan to use them.
How DeployOpen helps you evaluate and move to Atlantis
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For HCP Terraform vs Atlantis, we start with the written scope that decides whether pull request automation fits your review process, state backend and team layout.
How we scope
- Inventory which workspaces, pull request workflows and approval rules your team relies on today
- Confirm the state backend you will use, such as S3 or GCS, since Atlantis cannot use local state
- Agree the written scope, deliverables and timeline in advance, since most engagements are fixed-scope
How we build
- Deploy Atlantis in your infrastructure and connect it to your version control host
- Write the atlantis.yaml layout for modules, workspaces and custom tfvars files
- Configure a custom workflow to run OpenTofu, and test the lock and apply flow on a non-production repository
How we hand over
- Document the deployment, repository conventions, locking behavior and the runbook for failed applies
- Move each workspace's state with a verified backup, then compare plans before and after the cutover
- Walk your platform and security teams through access controls, credentials and audit logging
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Track Atlantis and OpenTofu releases and plan upgrades in a controlled change window
- Re-run security testing of the Atlantis deployment and its webhook endpoints when your setup changes
