Terrakube vs Atlantis: Platform vs PR Automation

Atlantis and Terrakube both run Terraform for a team instead of from laptops, and both are open source under Apache-2.0. They solve different-sized problems. Atlantis is pull request automation: it listens for webhooks, runs plan and apply, and posts the output back as a comment. Terrakube is a full platform: organizations and workspaces, remote state, a private registry, a web UI, team permissions and policy checks, with Terraform or OpenTofu underneath. Facts below come from each project's GitHub repository and documentation, checked October 23, 2026 (Atlantis on GitHub, Atlantis docs, Terrakube on GitHub, Terrakube docs).

Quick answer

Sources: GitHub repositories and release pages for both projects, Atlantis deployment, Atlantis locking, Atlantis server configuration, CNCF project page, Terrakube team management, checked October 23, 2026.

Verdict: pick Atlantis if your team lives in pull requests, already has a state backend it trusts (S3, GCS, Azure Blob) and only wants plans and applies to run from one place with a lock. Pick Terrakube if you want the HCP Terraform model: state, workspaces, a registry, a UI and team permissions in one system, without paying per resource. Atlantis is the smaller tool to run. Terrakube replaces more of the stack, so it also has more parts.

How each one works

Atlantis is a single Go binary. You give it credentials for your Git host and your cloud, register a webhook, and set a repository allowlist ("Atlantis requires you to specify an allowlist of repositories it will accept webhooks from"). When someone opens a pull request that touches Terraform files, Atlantis runs terraform plan and comments the result. A reviewer approves, someone comments atlantis apply, and Atlantis applies and comments again. The pull request is the record of what changed and who approved it.

Terrakube is a set of services: an API, a UI, an executor that runs jobs, a registry, a database and object storage, with Dex for login. Infrastructure lives in organizations and workspaces. A run can start from the UI, from a commit through a connected VCS provider, or from your terminal: point a cloud block at the Terrakube hostname, run terraform login, and terraform plan runs remotely with output streamed back (Terrakube CLI-driven workflow).

Atlantis is configured per repository with an atlantis.yaml file. This one, from the repo-level config docs, plans project1 in the staging workspace whenever its files or the shared modules change:

version: 3
projects:
   - dir: project1
     workspace: staging
     autoplan:
        when_modified: ["../modules/**/*.tf", "*.tf*", ".terraform.lock.hcl"]

Terrakube is configured in the code that uses it. This sends a workspace's runs and state to a Terrakube instance:

terraform {
  cloud {
    hostname     = "terrakube-api.example.com"
    organization = "your-org"
    workspaces {
      name = "your-workspace"
    }
  }
}

State and locking

This is the biggest difference. Atlantis does not store Terraform state. It runs terraform init against whatever backend your code declares, so you still choose, secure and back up that backend yourself. Atlantis keeps its own data small: "Atlantis has no external database" and "Atlantis stores Terraform plan files on disk", which is why the docs suggest a persistent disk (deployment docs).

Its lock is a workflow lock, not a state lock. Running plan locks the directory and workspace until the pull request is merged or closed or the plan is deleted, so two pull requests cannot work on the same state at once. The docs are explicit that this sits above Terraform's own locking: "Atlantis does not conflict with Terraform State Locking" (Atlantis locking).

Terrakube is the backend. State lives in the platform, users with the right permission can view it in the UI,, and it is standard Terraform state. You do not need a separate S3 bucket and lock table per project.

Registry, UI and permissions

Atlantis has no module or provider registry. Teams that need private modules usually reference Git tags or run a separate registry. Terrakube includes a private registry for both modules and providers (Terrakube private registry).

Atlantis has a small web UI, used for locks and for the global apply lock button. Day to day, the pull request is the interface. Terrakube's UI lists organizations, workspaces, runs, logs, variables, state and registry entries.

Access control in Atlantis comes mostly from your Git host. Apply requirements can demand that a pull request is approved by someone other than the author, mergeable, or not diverged from the base branch (command requirements). Terrakube has its own model: teams named after groups in your identity provider, with preset roles (Admin, Write, Plan, Read) or custom permissions such as Apply Runs, Manage Modules or Manage State, granted at organization, project or workspace level (team management).

Policy as code

Both use Rego. Atlantis runs Conftest against the plan when the server starts with --enable-policy-checks, and a failing policy blocks the apply until it is fixed or "approved by top-level owner(s) of policies or the owner(s) of the policy set in question" (Atlantis policy checking). That owner approval flow, inside the pull request, is a strength.

Terrakube runs Open Policy Agent as a step in a job template, after the plan and before the apply. A failing check fails the job (Terrakube OPA docs). It is more flexible, since a template can run any tool, but you write the step yourself. More in Terrakube OPA policies.

Maintenance status

Both projects are active. Atlantis has about 9,300 GitHub stars, published 17 stable releases in the last 12 months and was accepted into the CNCF as a Sandbox project on June 18, 2024 (CNCF). Terrakube is smaller, at about 980 stars, with 18 stable releases in the same period. Both shipped a release on October 21, 2026. Terrakube's repository moved from the AzBuilder organization to terrakube-io, and old links redirect.

Which to pick

Pick Atlantis if you want review-driven applies with the smallest footprint, your state backends are already sorted, and you have no need for a registry or a UI.

Pick Terrakube if you are replacing HCP Terraform or Terraform Enterprise, want state, runs, registry and permissions in one place, or want people outside the pull request flow to see and run workspaces.

The cost of Terrakube is operations: more services to install, upgrade and back up. That is the part Kevra Infra takes on. It runs the same open-source Terrakube as a hosted service at a flat monthly price, starting at USD 39 per month. See hosted Terrakube for what that includes, or self-hosting Terrakube with Helm if you would rather run it.

Related: open-source Terraform automation tools, Terrakube vs Spacelift, HCP Terraform alternatives.

FAQ

Does Atlantis store Terraform state?

No. Atlantis runs Terraform against the backend your code declares, such as S3 or Azure Blob storage. It keeps only plan files on disk and has no external database (Atlantis deployment docs).

Is Atlantis still maintained?

Yes. It published 17 stable releases in the 12 months to October 23, 2026, the latest being v0.48.2 on October 21, 2026, and it has been a CNCF Sandbox project since June 18, 2024.

Does Terrakube comment plans on pull requests like Atlantis?

Yes, since Terrakube 2.31. A workspace can post its plan on each pull request, re-run it when someone comments terrakube plan, and, if you also enable it, apply on a terrakube apply comment. Both options are off by default and live in the workspace webhook settings (2.31.0, 2.33.0). The difference is emphasis: Atlantis is built around pull request comments, while in Terrakube they are one option next to the UI, API and CLI.

Do Atlantis and Terrakube support OpenTofu?

Yes. Atlantis selects it with --default-tf-distribution opentofu, and Terrakube runs Terraform or OpenTofu. See Terrakube with OpenTofu.

Which one has a private module registry?

Terrakube, for both modules and providers. Atlantis has none.

Are both open source?

Yes. Both are licensed under Apache-2.0.

Terrakube is a trademark of its owners. Kevra is not affiliated with, endorsed by or sponsored by the Terrakube project. Kevra Infra runs the open-source Terrakube project (Apache-2.0) as a managed service.