Atlantis vs Terrakube: when each runner fits your team
Choose Atlantis when your main goal is reviewable infrastructure changes inside the pull request workflow your engineers already use. Atlantis listens for pull request webhooks, runs terraform plan and comments the output back on the pull request, and runs apply only when someone comments atlantis apply. It locks a directory or workspace until the pull request is merged or the lock is deleted. Choose Terrakube when you run many workspaces, modules and providers for several business units and need a central collaboration layer with a private registry, remote backend, group-based permissions and a shared API. Both run inside your own infrastructure, and both are licensed under Apache 2.0, so license alone will not separate them.
The decision turns on four questions. First, which Git host do you use? Atlantis supports GitHub, GitLab, Gitea and compatible forks such as Forgejo, Bitbucket Cloud, Bitbucket Server and Azure DevOps, while Terrakube retrieves code from GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps. Confirm your exact host edition and version against each project's documentation before you shortlist. Second, which identity provider must govern access? Terrakube authenticates through Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML, and assigns permissions by group. Atlantis relies on your Git host and deployment controls for access, so confirm how approvals and apply rights will be enforced in your environment.
Third, do you need a private registry for Terraform modules and providers? Terrakube provides one, while Atlantis does not, so teams that already host modules elsewhere may not need the extra component. Fourth, do you want one place where runs, state and policy are visible across teams? If yes, Terrakube's extensions for OPA policy checks and Infracost estimates are a fit to evaluate. If your reviewers already work in pull requests and a per-directory lock is enough, Atlantis keeps the moving parts smaller. Whichever you pick, run a pilot against one representative stack and ask your partner to scope the Helm or Docker Compose installation, backups and upgrades in writing before work starts.
Which runner fits which scenario
This table maps common team situations to the runner that fits better and the condition that makes it so. Read each row against your Git host, identity setup and whether you want a pull request workflow or a remote workspace model. The main takeaway is that Atlantis suits teams whose work centers on pull requests, while Terrakube suits teams that need workspaces, a registry and centralized access control.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Small platform team on GitHub or GitLab, reviewing changes in pull requests | Atlantis | Atlantis runs terraform plan on pull request webhooks, posts the output as a comment, and locks a directory or workspace until the pull request is merged or the lock is deleted. This works best when the team already reviews infrastructure changes in pull requests. |
| Team on Forgejo or Gitea that wants plan and apply driven by comments | Atlantis | Atlantis supports Gitea and compatible forks such as Forgejo. Confirm the exact webhook and version behavior with your Git host before you commit. |
| Multi-team organization on Azure DevOps that needs group-based access and SAML sign-in | Terrakube | Terrakube integrates with Azure DevOps for code retrieval and uses Dex for identity providers including SAML, assigning workspace, module and VCS permissions by group. Atlantis's documented host list includes Azure DevOps, but its access model is driven by the pull request workflow rather than group assignments, so confirm how your identity requirements map to it. |
| Team that needs a private registry for internal Terraform modules and providers | Terrakube | Terrakube provides a private registry for modules and providers. Atlantis does not present a registry in the supplied facts, so plan a separate registry if you choose it. |
| Team already standardized on the OpenTofu CLI with a custom workflow | Either, depending on where runs should happen | Atlantis runs OpenTofu through a custom workflow, with the tofu binary installed in an init container and ATLANTIS_TF_DOWNLOAD set to false, per a May 2024 blog post. Terrakube supports the cloud block and the remote backend, so runs can start from the OpenTofu CLI. Choose Atlantis if the pull request is the control point, and Terrakube if the CLI is. |
| Team that wants runs started from the CLI with state held in a remote backend | Terrakube | Terrakube supports the remote backend and the cloud block, and the cloud block needs Terraform v1.1 or later. Earlier versions can use the remote backend, which also supports state migration. |
| Team with a state backend that is not local and no wish to commit state to Git | Atlantis | Atlantis supports all Terraform state backend types except local state, and does not commit state files back to version control. Confirm that your backend and OpenTofu version match your Atlantis configuration. |
| Team that needs policy checks and cost estimates in each run | Terrakube | Terrakube extensions add tools such as OPA policy checks and Infracost cost estimates to runs. With Atlantis, these checks are usually added through custom workflow steps, so confirm the effort with your team. |
How Atlantis and Terrakube are built and deployed
Atlantis and Terrakube both run in your own infrastructure, but they divide the work differently. One is a webhook-driven application that locks directories around pull requests, the other is a platform with its own API, registry and database. The cards below cover what each component means for upgrades, availability and ownership of the state backend.
Atlantis as a webhook-driven application
Atlantis runs as a standalone application in your infrastructure. It listens for pull request webhooks from your Git host, runs terraform plan and posts the output back to the pull request. Applies happen only when someone comments atlantis apply, and Atlantis holds a lock on the directory or workspace until the pull request is merged or the lock is deleted. Check how your team will clear stale locks, because a lock left behind blocks other changes to that directory.
Terrakube's API, workspaces and registry
Terrakube is a broader platform. Its API manages workspaces, a private registry for Terraform modules and providers, and a remote backend, and it can run from the Terraform or OpenTofu CLI through the cloud block or the remote backend. Because the platform holds workspace definitions, run history and registry content, you take on more components to operate than with Atlantis. Confirm which of these you need on day one, since the registry and CLI workflow are the main reasons to choose it.
Relational database under Terrakube
Terrakube stores its platform data in a relational database and supports any database that Liquibase supports, including PostgreSQL, MySQL, Oracle and SQL Server. Your team picks the database engine, so backup, restore and high availability follow the standards you already run for that engine. Ask who owns that database, how schema migrations are applied during upgrades and how you will restore workspace and run data after a failure. Atlantis has no equivalent database layer to manage.
Deployment packaging for each tool
Atlantis is documented for a Kubernetes Helm chart, Kubernetes manifests, Kustomize, OpenShift, AWS Fargate, Google Kubernetes Engine, Docker and custom installs, using the image ghcr.io/runatlantis/atlantis. Terrakube documents installation with a Helm chart or Docker Compose and testing with minikube. Choose the packaging your platform team already operates, and confirm that the chosen path matches your cluster policies, image mirroring and secrets handling.
Upgrades, availability and state ownership
With Atlantis, the state backend stays with you: Atlantis does not store state itself and does not commit state files to version control, so your chosen backend remains the system of record. With Terrakube, the platform holds run and workspace data, so backup, upgrade order and failover planning cover the Terrakube services and its database as well as the state backend. Ask each vendor or your implementation partner for the upgrade and rollback steps you should rehearse before production.
Atlantis vs Terrakube side by side on Git hosts, identity and governance
This table compares Atlantis and Terrakube on license, Git host support, state handling, locking, registries, identity, policy extensions and deployment. Read each row against your own Git host, identity provider and governance requirements, and confirm any capability not listed before you commit.
| Capability | Atlantis | Terrakube |
|---|---|---|
| License | Apache 2.0 | Apache 2.0 |
| Latest supplied version and date | v0.48.1, October 7, 2026 | 2.33.2, September 14, 2026 |
| Supported Git hosts | GitHub, GitLab, Gitea and compatible forks such as Forgejo, Bitbucket Cloud, Bitbucket Server, Azure DevOps | GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket, Azure DevOps |
| State backend support | All Terraform backend types except local state, since Atlantis keeps no permanent storage | Remote backend and cloud block; the remote backend also supports state migration |
| Terraform and OpenTofu handling | Supports all Terraform versions including 0.12, set per repository or project; OpenTofu documented via a custom workflow | Runs Terraform or OpenTofu; cloud block requires Terraform v1.1 or later, earlier versions use the remote backend |
| Workspace and locking model | Pull request comment workflow; locks a directory or workspace until merge or lock deletion | Workspaces managed in Terrakube; confirm lock behavior for your run pattern |
| Private module and provider registry | Not a built-in feature; confirm with your module source setup | Private registry for Terraform modules and providers |
| Identity integration | Relies on webhook secrets and Git host controls; confirm any further SSO options | Dex with Azure Active Directory, Amazon Cognito, GitHub and SAML |
| Group-based permissions | Controlled through Git host permissions and repository approvals; confirm workflow-level roles | Permissions on workspaces, modules and VCS connections assigned by group |
| Policy and cost extensions | Custom workflows can call your own tools; confirm native policy support | Extensions for OPA policy checks and Infracost cost estimates; API for custom integrations |
| Deployment methods | Helm chart, Kubernetes manifests, Kustomize, OpenShift, AWS Fargate, GKE, Docker, custom installs | Helm chart or Docker Compose; minikube documented for testing |
Licensing and editions for each runner
Atlantis is licensed under Apache 2.0, and the latest release in the supplied facts is v0.48.1, published October 7, 2026. The license carries no license fee for running the runner in your own infrastructure, so your recurring costs sit in the compute that hosts it, the Git host plan you already pay for, your state backend and the staff who operate it. The supplied facts do not document a paid edition or a commercial support tier. Ask the maintainers directly whether paid support exists, what it covers, how it is priced and whether a third party resells it.
- License scope: Apache 2.0 covers the Atlantis software. Your cloud accounts, state storage and Git host subscriptions are separate agreements.
- Release cadence: v0.48.1 is the release named in the supplied facts. Plan upgrades against the Atlantis GitHub releases page, because patch releases may carry fixes you need.
- Paid tier: none is documented in the supplied facts, so treat the open-source build as the only documented option until the maintainers say otherwise.
- Deployment image: the documented image is
ghcr.io/runatlantis/atlantis. Pin the tag you have tested so that a routine redeploy does not change your Terraform or OpenTofu behavior.
Before you commit, confirm the support path, the security advisory process and the upgrade policy for the image you run.
Terrakube is licensed under Apache 2.0 and describes itself as open-source IaC automation and collaboration software. The supplied facts show version 2.33.2, released September 14, 2026. Its documentation positions it as a replacement for closed-source tools such as Terraform Enterprise, Scalr or env0, so buyers comparing those products will look for equivalent features in a community build. The supplied facts do not document a paid edition or commercial support. Ask the maintainers whether support contracts exist and whether any capability depends on a commercial agreement.
- License scope: Apache 2.0 applies to the repository. The database, Kubernetes cluster or Docker host and the identity provider remain yours to license and run.
- Release reference: 2.33.2 is the version named in the supplied facts. Check the Terrakube GitHub releases page before each upgrade, because the Helm chart and Docker Compose paths both depend on the release you choose.
- Competitor pricing: Terraform Enterprise, Scalr and env0 are the products Terrakube's documentation names as alternatives. Their tiers and prices are outside the supplied facts, so request current quotes yourself before you compare.
- Database and identity costs: supported relational databases include PostgreSQL, MySQL, Oracle and SQL Server through Liquibase. Oracle and SQL Server licenses are typically separate commercial agreements, and Dex integrations with Azure Active Directory, Amazon Cognito, GitHub and SAML depend on your identity contracts.
Confirm the support terms in writing, whether any extension or integration carries separate terms and the upgrade path for your chosen database.
OpenTofu is licensed under the Mozilla Public License 2.0, according to its GitHub repository, and operates under the Linux Foundation's stewardship. The OpenTofu website says a group including Gruntwork, Spacelift and Harness created the project in response to HashiCorp's switch to the Business Source License. The CNCF accepted OpenTofu at the Sandbox maturity level on April 23, 2025, and the latest release in the supplied facts is v1.13.1, published October 1, 2026. Sandbox status describes the OpenTofu project. It does not certify Atlantis, Terrakube or any runner image that installs OpenTofu.
- MPL-2.0 scope: this is file-level copyleft. Changes you make to MPL-covered files must remain under MPL-2.0 when you distribute them, while separate files you write can carry their own terms.
- Foundation stewardship: the Linux Foundation context matters for questions about long-term governance and who decides the roadmap.
- CNCF Sandbox: the project was accepted on April 23, 2025 at Sandbox maturity. Read this as project status, not as an endorsement of either runner.
- Runner compatibility: Atlantis can run OpenTofu by installing the tofu binary in an init container with
ATLANTIS_TF_DOWNLOADset to false, as shown in a May 2024 Atlantis blog post. Terrakube supports both Terraform and OpenTofu. - Feature parity limit: the OpenTofu FAQ aims for parity with Terraform but does not guarantee compatibility with future Terraform releases, so pin versions in both runners.
Check which OpenTofu binary each runner executes, and test your configurations against that exact version.
What drives the running cost of each runner
Both Atlantis and Terrakube are self-hosted, so the license line is zero and the real cost sits in hosting, people, integration and tooling. The cards below separate one-time build work from recurring upkeep, and show what to ask for in a written quote before you compare totals.
Hosting the runner and its database
Atlantis is deployed as a standalone application in your infrastructure, and Terrakube needs a relational database that Liquibase supports, such as PostgreSQL, alongside its own services. Hosting is recurring: compute, database storage, backups and the high availability you choose. Atlantis has no permanent storage of its own, while Terrakube keeps run history and registry data, so its database and backup footprint usually grows with usage. Ask the quote to list each component, the environment it runs in, and who operates the database.
Staff time for upgrades and chart changes
Your platform team pays for version tracking, Helm chart or Kubernetes manifest changes, and testing of each upgrade. Atlantis releases move quickly (v0.48.1 shipped October 7, 2026), and Terrakube 2.33.2 shipped September 14, 2026, so upgrade cadence is a recurring line item. Terrakube's Helm and Docker Compose paths add a second deployment surface to maintain. Ask who owns upgrade testing, how many environments are covered, and whether the quote includes rollback planning.
Identity and Git host integration
Each runner needs its own connection to your Git host and identity provider. Atlantis supports GitHub, GitLab, Gitea, Forgejo, Bitbucket and Azure DevOps through webhooks. Terrakube uses Dex to connect identity providers and assigns workspace, module and VCS permissions by group, which means group mapping is a one-time design task that recurs whenever teams change. Price the webhook and token setup, the group model, and any SAML or Azure Active Directory configuration separately.
State backend and secret management
Atlantis supports every Terraform state backend except local state, so the state backend is usually already paid for by your platform. The recurring cost is credential handling: cloud roles or secrets that Atlantis and Terrakube need to plan and apply. OpenTofu's state encryption adds key provider choices, such as AWS KMS, GCP KMS, OpenBao or Azure Vault, each with its own key management overhead. Ask who manages key rotation, where runner credentials are stored and how break-glass access is granted.
Policy and extension tooling
Policy checks and cost estimates change the run budget. Terrakube extensions add tools such as OPA policy checks and Infracost cost estimates, and its API supports custom integrations, so those rules are built and maintained by your team. Atlantis reaches the same outcomes through its custom workflows, which means workflow YAML and any policy tool you wire in are maintained in your repositories. Ask the quote to separate initial rule authoring from ongoing rule changes, and to state which policy tool versions are covered.
External support and retainers
Neither product's license includes vendor support in the sources supplied, so support cost depends on who answers when a run fails. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. Ask whether the quote is one-time build, a recurring retainer, or both, and what response expectations are written into the scope.
Moving between Atlantis and Terrakube later
This sequence shows how a team moves its Terraform or OpenTofu runs from one runner to the other without losing state, and what must be rebuilt on the new side before any apply runs under it. It is written so the team can confirm each handoff before cutover.
Inventory every workflow and its state backend
Before changing anything, list each root module the current runner touches. For Atlantis, record each atlantis.yaml file and the projects, workspaces, Terraform or OpenTofu versions and custom tfvars layouts it defines. For Terrakube, export each workspace with its VCS connection, variables, module references and assigned groups. Record the state backend for every root module, since that decides whether state moves at all. The output is a single inventory sheet that a second engineer has checked against the live configuration. Confirm the backend list with the people who own each state file, because a missed module is the most common source of surprises.
Confirm state backend continuity
If a root module keeps the same remote backend after the move, its state stays where it is and no state migration is needed. Only the runner configuration changes. Atlantis supports every Terraform state backend type except local state, and it does not commit state files back to version control, so local state must be moved to a remote backend before any move. When the backend itself changes, back up the state and the code first, then follow the OpenTofu migration steps of backup, install, initialize and verify, and test with a small change. Done is a written record per module saying either that state is unchanged or that it was migrated and verified.
Back up state, code and runner configuration
Take a copy of every state file, the repositories containing the Terraform or OpenTofu code, and the runner configuration in use: atlantis.yaml files, workflow definitions, Terrakube workspace settings and variable sets. Store the copies outside the runner you are leaving, in storage with restricted access, because state can contain secrets. Keep the copies until the new runner has completed a full cycle of plans and at least one apply under production change control. Done means a restore has been tested on a non-production copy and the team can name who can read these backups.
Re-point webhooks and VCS connections
Atlantis listens for pull request webhooks from the Git host, so the webhook for each repository must be moved to the new runner's endpoint, or the old one disabled to avoid duplicate plans. Terrakube retrieves code through VCS connections to GitHub, GitLab, Bitbucket or Azure DevOps, so each connection must be created or re-authorized on the Terrakube side. Confirm the exact Git host support for your version with each vendor's documentation before relying on it. Done means a test pull request triggers exactly one plan on the new runner and none on the old one.
Rebuild locks, permissions and registry entries
Atlantis locks a directory or workspace until the pull request is merged or the lock is deleted, so pending locks should be cleared on the old runner before cutover and nothing should be left locked during the move. Terrakube assigns permissions on workspaces, modules and VCS connections by group, so each group mapping must be recreated and checked against the identity provider configured in Dex. Modules and providers published to the Terrakube private registry must be re-published, and any module references updated to point at the new registry. Done means each group can perform only the actions it held before, and the registry resolves every module in the inventory.
Run a parallel plan before cutover
For a period agreed in advance, run plans on the new runner against the same code and state as the old one, and compare the output for each root module. Differences usually point to a missing variable, a wrong Terraform or OpenTofu version, a provider version pin or an unmatched workspace name. Plans must not be applied from the new runner during this window. Done is a written comparison showing no unexplained changes for each module, reviewed by the platform owner and the team that operates the infrastructure.
Cut over and retire the old runner
Switch the webhooks, VCS connections and pipeline entry points to the new runner, then apply a small, low-risk change to one module to confirm the full path works end to end. Once that succeeds, widen the cutover module by module in the order from the inventory. Retire the old runner only after every module has completed at least one real change on the new side and the backups from the earlier step have been checked. Done means the old runner has no active webhooks, no open locks and no scheduled jobs, and the change record names the owner for each module.
Where Atlantis and Terrakube implementations usually run long
The longest part of either deployment is rarely installing the runner. It is connecting the runner to your Git host, your cloud accounts and your state, then deciding who may trigger what. For Atlantis, the first job is wiring pull request webhooks from GitHub, GitLab, Gitea or Forgejo, Bitbucket or Azure DevOps to the standalone service, and giving it a credential that can read repositories and post comments. Plan a separate, scoped credential per cloud account or subscription, stored in your secrets manager and injected at runtime rather than baked into the image. Confirm your state backend early, because Atlantis supports every Terraform state backend type except local state. The state encryption choice belongs in this same decision if you run OpenTofu, since OpenTofu encrypts state and plan files with key providers such as AWS KMS, GCP KMS, OpenBao or Azure Vault.
For Terrakube, the heavier lift is identity and workspace design. Authentication runs through Dex, which connects to providers such as Azure Active Directory, Amazon Cognito, GitHub or SAML, and permissions on workspaces, modules and VCS connections are granted by group. Map those groups to your access model before the first workspace is created, because retrofitting group boundaries across hundreds of workspaces is where teams lose time. Terrakube also needs a relational database that Liquibase supports, so the database and its backup regime become part of the install. Keep the remote backend and cloud block decision explicit: the cloud block requires Terraform v1.1 or later, and older versions have to use the remote backend.
Across both tools, the overruns tend to come from the same places. The first is terraform_remote_state dependencies: OpenTofu's migration guide warns that configurations sharing data this way typically need extra care, and in a runner, a plan on one directory can silently depend on an output that another pipeline has not yet applied. The second is mixed Terraform and OpenTofu versions across repositories, which Atlantis allows per repository or project but which still needs a version policy and a pinned atlantis.yaml. The third is access reviews: every group, webhook secret and cloud role needs an owner and a review date. Scope and timeline for any of this are agreed in writing before work starts, and the reader should ask for each item to be named in that scope.
Questions buyers ask before choosing or hiring help
How much effort does it take to run Atlantis compared with Terrakube?
Atlantis is the lighter service to run because it is a single standalone application that listens for pull request webhooks, runs plan and apply, and posts output back to the pull request. Terrakube is a larger collaboration platform with workspaces, a private registry, a remote backend, user and group permissions and extensions, and it is installed with a Helm chart or Docker Compose and backed by a relational database that Liquibase supports. The effort on each side depends on how many repositories, state backends, identity groups and VCS connections the team must manage, the Git host and the database the team already operates, and how many people will maintain the platform after launch. Ask each vendor or your partner to map those components against your environment before you compare totals.
Can a platform team deploy and operate either runner without outside help?
A platform team with Kubernetes or container experience and Terraform or OpenTofu knowledge can usually deploy Atlantis from the documented options, which include a Helm chart, Kustomize, Docker and custom installs. Terrakube also documents a Helm chart and Docker Compose, but operating it well means owning the database, the identity integration through Dex, workspace permissions and extensions, so the skills needed are broader. Whether your own team can carry this depends on your staffing, your on-call model and how much ongoing upgrade work you want to keep in-house. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and it offers ongoing support as a retainer if you prefer not to carry that work alone.
What drives how long a migration between Atlantis and Terrakube takes?
The main drivers are how many configurations, workspaces and state files are in scope, whether pipelines depend on pull request comments or on CLI runs, and how the existing runner handles locking and approvals. Moving to Terrakube usually means reworking the remote backend or cloud block settings, re-creating workspaces and permissions by group, and reconnecting VCS. Moving to Atlantis usually means writing an atlantis.yaml file for modules, workspaces and tfvars layouts and checking that each state backend type works, since Atlantis does not support local state. Any configuration that uses the terraform_remote_state data source needs extra care, as OpenTofu's migration guidance notes. Ask for a written inventory before agreeing on scope, because that inventory sets the work.
Does Atlantis work with OpenTofu, and what does the May 2024 blog post show?
Yes, Atlantis can run OpenTofu, and the Atlantis blog post from May 2024 shows how. It describes installing the tofu binary in an init container, setting ATLANTIS_TF_DOWNLOAD to false and using a custom workflow so Atlantis calls OpenTofu instead of Terraform. Treat that post as a documented pattern rather than a guarantee for your version, because your workflow, provider versions and state backend determine what works. Confirm the exact Atlantis and OpenTofu versions you plan to run, test a plan and apply on a non-production repository, and check the OpenTofu version behavior that matters to your modules before you rely on the pattern in production.
Does Terrakube's Dex integration fit an existing identity provider?
It fits if your identity provider is one Dex supports and your group model maps cleanly to Terrakube permissions. Terrakube uses Dex for authentication with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML, and it assigns permissions on workspaces, modules and VCS connections by group. Check that your identity provider exposes the group claims Terrakube needs, that group membership changes flow through without manual steps, and how offboarding removes access to workspaces and state. Atlantis does not provide this layer of identity-based workspace permissions in the same way, so its access control is closer to what your Git host and pull request review rules enforce. Confirm the exact Dex connector and claim setup with the Terrakube maintainers and your identity team.
What would an implementation partner need from our team before quoting?
A partner needs a written scope to quote against, so prepare the list of Git hosts and repositories, the Terraform or OpenTofu versions in use, the state backends, the cloud accounts or clusters that will run plans, and the identity provider and group structure. It also needs the existing approval and change process, the audit evidence your compliance team expects, the target hosting environment, and who will own the platform after handover. The quote then follows from that scope, and DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers.
What should we confirm with each maintainer before committing?
Confirm the current release policy and the versions you will run. Atlantis is Apache 2.0 licensed and v0.48.1 was released on October 7, 2026, so ask which release line the maintainers expect you to follow and how security fixes reach you. Terrakube is Apache 2.0 licensed and 2.33.2 was released on September 14, 2026, so ask about its upgrade path, database migration steps and extension compatibility. For both, confirm supported Git host integrations for your specific edition, documented backup and restore steps, the contributor and release cadence, and whether the project has a commercial support channel. Put the answers in writing and check them against your own environment before signing.
Which runner suits a team that wants strict approvals on every change?
Atlantis suits teams that want every plan and apply tied to a pull request, with output posted for review and directory or workspace locks held until the pull request merges or the lock is removed. Terrakube suits teams that need group-based permissions across workspaces, a private registry for modules and providers, and a remote backend or cloud block that works from the CLI. Atlantis relies on your Git host's review rules for approval, while Terrakube adds its own permission model on top of your VCS. Confirm how your audit requirements map to each model, and document where approval evidence is stored before you choose.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Atlantis vs Terrakube, we start with the written scope that decides which runner fits your Git host, state backend, identity provider and team layout, then build and hand over the chosen platform in your environment.
How we scope
- Map which Git host, Terraform or OpenTofu versions and state backends your teams use today
- Agree in writing whether Atlantis pull request workflows or Terrakube workspaces fit your change process
- Define identity integration, group permissions and the directories or workspaces in scope
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts
How we build
- Deploy the chosen runner in your cloud account, data center or air-gapped network
- Configure Git host webhooks, state backends and locking behavior against your repositories
- Test plan and apply flows on non-production workspaces before any production change
- Run security testing on the runner, its credentials and its access to cloud accounts
How we hand over
- Document the architecture, configuration files, permission model and approval steps
- Provide runbooks for upgrades, backups of the runner's data and recovery procedures
- Walk your platform and security teams through the setup and the evidence it produces
- Confirm with your vendor and environment which features your edition and version include
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer
- Track new Atlantis or Terrakube releases and plan upgrades against your change windows
- Review access, group mappings and extension usage as your teams and providers change
- Quotes follow from the written scope, so ask for the components each option requires
