Terraform and OpenTofu pull requests in 2026: revisit Atlantis, OpenTaco and Stategraph before you run another apply from a laptop

Most infrastructure teams know this Friday evening. A developer runs terraform apply from a laptop because “it is a small change”. Nobody else saw the plan. Another engineer is holding the state lock from a half-finished run, so someone runs force-unlock without asking. The cloud keys used for the apply are long-lived and sitting in a ~/.aws/credentials file. On Monday, the reviewer of the pull request approves code that is already live, and nobody can say exactly which plan was applied.

Terraform and OpenTofu are not the problem here. What is missing is a shared, reviewable path from pull request to plan to apply. This post revisits three open-source tools that give you that path: Atlantis, OpenTaco (the project formerly called Digger) and Stategraph Orchestration (the product formerly called Terrateam). If you are still choosing between Terraform and OpenTofu themselves, read our earlier post on the fork first: https://revisit.tech/blog/opentofu-and-terraform-revisit-the-fork-before-you-pick-one/ .

The short version

  • Atlantis: Apache-2.0, CNCF Sandbox since 18 June 2024. A self-hosted server that runs plan and apply on its own host and comments the output on the pull request. Best fit when you accept running one more service and want the widest VCS support with no vendor in the middle.
  • OpenTaco (formerly Digger): MIT, with an ee/ directory under a separate commercial licence; the company is still Digger. A CLI runs inside your existing CI and a small orchestrator triggers the jobs. Best fit when your CI runners already hold cloud access and you do not want a second CI system.
  • Stategraph Orchestration (formerly Terrateam): MPL-2.0, but the Open Source edition allows 3 active users per installation per month, and Enterprise features are commercial. A server starts plans and applies on your GitHub Actions or GitLab CI runners. Best fit for large monorepos that want policy, cost and drift in one place, once you have read the edition limits.

What the job actually is

Before comparing tools, split “Terraform automation” into the questions that matter in a review.

  • Who runs the binary. A long-lived server you operate, or a job on CI runners you already have.
  • Where the cloud credentials live. On that server, in CI secrets, or better, in short-lived OIDC tokens issued to the runner. The answer decides your blast radius if the automation is compromised.
  • How locking works. Terraform and OpenTofu already lock the state file during a run. PR automation adds a second, longer lock: “this directory and workspace belong to this pull request until it is merged”. Without it, two pull requests can plan against the same state and the second plan becomes wrong as soon as the first is applied.
  • What happens to state. Most tools leave your existing backend untouched; some also sell their own state service.
  • How apply is approved. Apply before merge, apply after merge, required reviewers, CODEOWNERS, policy checks with OPA or Conftest, and who can override a failed check.
  • What happens later. Drift detection, audit trail, and upgrades.

A small Indian example: a Pune platform team of five supports a Bengaluru product organisation with about forty engineers. Infrastructure sits in one monorepo with dev, staging and prod folders, on AWS, with code on GitHub. Security wants no AWS keys on laptops and a second approver for prod. The platform team does not want another stateful service to babysit. Each tool below answers this team differently.

Atlantis: the server that started PR automation

History and licence. Atlantis was originally built at Hootsuite, as its own project blog explains, and the runatlantis/atlantis repository has been the home since 2018. It is licensed Apache-2.0 and was accepted into the CNCF at Sandbox level on 18 June 2024. The maintainers file lists people from different employers, and community meetings run through the Linux Foundation. There is no paid edition of Atlantis itself.

How it works. Atlantis is a Go application. Your Git host sends a webhook, Atlantis clones the repository, runs terraform plan (or OpenTofu) on its own host, and posts the output as a comment. Someone comments atlantis apply and Atlantis applies. When a plan runs, the directory and workspace are locked until the pull request is merged or closed, and other pull requests that touch them get a comment pointing to the lock holder. Apply before merge is the default, because a failed apply after merge needs a fresh pull request to fix.

Where it is strong.

  • Widest VCS list of the three: GitHub, GitLab, Gitea, Bitbucket Cloud and Server, and Azure DevOps, including self-hosted editions.
  • Terraform and OpenTofu are both supported through --default-tf-distribution. Terragrunt and CDKTF (now continued as CDK Terrain) work through custom workflows.
  • Server-side Conftest policy checks against the plan, with policy owners who can approve a failing check.
  • No external database is required for a single instance. For multiple replicas, the FAQ describes Redis for locking plus external plan storage on S3-compatible storage.
  • Drift detection now exists as an API behind an experiment flag. Atlantis does not ship a scheduler; you call the endpoint from cron or CI.

What to watch.

  • Atlantis holds the cloud credentials. Treat the server like a production deploy system, because it is one.
  • It must be reachable by your Git host. With github.com or gitlab.com, that means exposing it to the internet behind a webhook secret and a repo allowlist.
  • Read release notes before you upgrade. The latest release, v0.49.0 (25 October 2026, 7:17 AM IST), is marked breaking: the Docker images no longer bundle Terraform or OpenTofu, so you must set a default version, and the release fixes 12 security advisories, some of which change existing behaviour.

OpenTaco (formerly Digger): Terraform jobs inside the CI you already run

History and licence. The diggerhq/digger repository dates from February 2023, and the project began with one idea: why run a second CI system just for Terraform. The README states that from 7 November 2025 the Digger project is called OpenTaco, while the company is still Digger. Expect digger.yml and other old names in the docs for a while. The repository root LICENSE is MIT. The ee/ directory, which holds parts of the backend, CLI and drift code, carries a separate Digger Enterprise licence that requires a paid subscription for production use. The GitLab and Bitbucket backend controllers, for example, sit inside ee/, so check what you deploy before assuming “MIT” covers it.

How it works. There are two parts. A CLI runs inside your CI job and calls Terraform, OpenTofu or Terragrunt with the right arguments. An orchestrator backend, hosted by Digger or self-hosted, receives GitHub webhooks and triggers those CI jobs. The documented path is a GitHub App plus a GitHub Actions workflow. PR-level locks sit on top of the native state lock and are stored in the backend database. A “backendless” mode still exists, with locks kept in DynamoDB, a GCS bucket or Azure Storage Tables, but the docs say it is slower and cannot queue clashing applies.

Where it is strong.

  • Cloud credentials stay in your CI, ideally as OIDC roles per project, and the docs include AWS, GCP and Azure OIDC guides. The README’s point is that cloud secrets are not shared with a third party.
  • No separate compute fleet; jobs run on your runners, in parallel.
  • Apply requirements, CODEOWNERS integration, apply on merge, Conftest policies, Checkov and Infracost are all documented.
  • Drift detection with Slack or GitHub Issues notifications, including a backendless variant on GitHub Actions.

What to watch.

  • The scope is growing. OpenTaco now also describes state management with an HCP Terraform-compatible interface, remote runs (marked Beta) that use E2B sandbox VMs, and RBAC for state. These are newer than the PR automation core. Adopt them separately and test them separately.
  • The self-hosted platform has several services (UI, orchestrator, drift, Statesman state service, token service, sidecar) and depends on WorkOS for sign-in. That is more moving parts than “just a GitHub Action”.
  • Public docs are written around GitHub. If you are on GitLab or Bitbucket, confirm support and licensing with Digger before you plan a migration.
  • The CLI collects anonymised telemetry by default; set telemetry: false to stop it.
  • The latest release is v0.6.155 (30 October 2026, 8:17 PM IST). The project is still on 0.x versions, so pin versions.

Stategraph Orchestration (formerly Terrateam): PR automation plus a state database on the side

History and licence. Terrateam began in 2021 as GitOps for Terraform with an OCaml engine, and the engine was open-sourced under MPL-2.0 in 2024, according to the company’s About page. The team then built Stategraph, a product that stores Terraform state as a dependency graph in PostgreSQL. The brand is now Stategraph. The old terrateamio/terrateam GitHub URL redirects to stategraph/stategraph, and Terrateam’s orchestration engine is now called Stategraph Orchestration. Existing setups keep working: the server still reads .terrateam/config.yml and runs .github/workflows/terrateam.yml when the new .stategraph/ names are missing, and the old terrat-oss and terrat-ee images map to new Stategraph images.

How it works. A PR event reaches the Orchestration server (Stategraph Cloud or self-hosted). The server starts a workflow on your GitHub Actions or GitLab CI runner, where the plan or apply runs, and posts the results back as comments and checks. Plans use your branch merged with the destination branch. Applies run on a stategraph apply comment or after merge. The directories and workspaces an apply changes are locked until the merge.

Where it is strong.

  • Credentials stay on your CI runners, not on the Stategraph server.
  • The Open Source edition includes OPA and Conftest policies, Checkov, Infracost cost estimates, stacks and dependency ordering, custom workflows, an audit trail, a console, and drift detection on one schedule per repository.
  • The widest tool list of the three in the docs: Terraform, OpenTofu, Terragrunt, Pulumi and CDKTF.
  • Tag-based configuration is designed for monorepos with many workspaces.

What to watch.

  • The Open Source user limit. The editions page says each GitHub or GitLab installation allows up to 3 active users per month. A fourth person’s plan or apply does not run. For a forty-engineer organisation, this alone means Enterprise or Stategraph Cloud.
  • RBAC, CODEOWNERS enforcement, approval gates, centralised configuration, multiple drift schedules and API tokens are Enterprise only. Turning them on in an Open Source server makes the configuration fail to load.
  • Infrastructure as a Database is a separate commercial product. Orchestration works with your existing state backend without it.
  • VCS support is GitHub and GitLab only.
  • Self-hosting needs PostgreSQL (15 or later per the migration guide).
  • Releases: the latest CLI and server release is 3.2.27 (6 November 2026, 7:43 PM IST), published in a separate stategraph/releases repository because, in its own words, the main Stategraph repository is private. The open-source repository publishes date-stamped builds; the newest at the time of writing was 20261106-1518-24e99ac (6 November 2026, 9:15 PM IST).

Side by side

  • Where plan, apply and credentials live. Atlantis: on the Atlantis server. OpenTaco and Stategraph: on your CI runners, ideally with OIDC.
  • What you operate. Atlantis: one Go service with a disk, or several replicas with Redis and S3. OpenTaco: hosted backend, or a self-hosted set of services with PostgreSQL, object storage and WorkOS. Stategraph: hosted service, or a self-hosted server with PostgreSQL.
  • VCS. Atlantis: GitHub, GitLab, Gitea, Bitbucket Cloud and Server, Azure DevOps. OpenTaco: GitHub documented; other VCS code is in the enterprise directory. Stategraph: GitHub and GitLab.
  • IaC tools. Atlantis: Terraform, OpenTofu, plus Terragrunt and CDKTF through custom workflows. OpenTaco: Terraform, OpenTofu, Terragrunt, with a Pulumi option in digger.yml. Stategraph: Terraform, OpenTofu, Terragrunt, Pulumi, CDKTF.
  • Locking. All three add a directory and workspace lock per pull request on top of the native state lock.
  • Policy. Atlantis: Conftest. OpenTaco: OPA and Conftest, plus Checkov. Stategraph: OPA, Conftest and Checkov, plus cost thresholds.
  • Drift. Atlantis: experimental API, bring your own scheduler. OpenTaco: built in, with Slack and GitHub Issues. Stategraph: one schedule per repository in Open Source, more in Enterprise.
  • Paid line. Atlantis: none. OpenTaco: ee/ licence and hosted plans. Stategraph: 3-user Open Source limit, then Enterprise or Cloud.

How to choose

  • Choose Atlantis when you are on Bitbucket, Azure DevOps or Gitea, when you want pure Apache-2.0 under neutral governance, or when your CI runners are not allowed to hold cloud credentials but a hardened server in your own network is.
  • Choose OpenTaco when you are on GitHub, your Actions runners already use OIDC roles, and you want PR automation without a separate compute fleet. Start with PR automation only, and keep your existing state backend.
  • Choose Stategraph Orchestration when you have a large monorepo with many workspaces, want cost and policy checks in the same pull request, use Pulumi or Terragrunt heavily, and either have three or fewer active users or a budget for Enterprise or Cloud.

For the Pune team above, OpenTaco or Stategraph fits the “no keys on laptops, no new stateful service” rule. Atlantis fits only if they accept running a server. The 3-user limit is the real decider between the other two.

Common mistakes

  • Giving the automation one admin role for every environment. Use a separate role per environment, and a read-only role for plans if your tool supports it.
  • Allowing apply from a pull request opened from a fork, or from any commenter. Set apply requirements: approved, mergeable, and up to date.
  • Leaving local applies possible “for emergencies” with no audit. If you keep a break-glass path, log it and review it.
  • Calling a tool “free” without reading the licence of each component you deploy.

Start this week

  1. List every place where apply runs today: laptops, CI jobs, bastion hosts.
  2. Move cloud access for CI to OIDC, so no static keys are needed.
  3. Pick one non-production directory and try one tool there. Get plan comments working before you allow any apply.
  4. Add one policy that blocks a dangerous change, for example deleting a database or opening port 22 to the internet.
  5. Turn on apply requirements, then remove human write access to the prod state bucket.
  6. Set up a weekly drift check and decide who looks at the result.

A short checklist

  • Every apply is linked to a pull request and a plan.
  • No long-lived cloud keys on laptops or in CI secrets.
  • PR-level locks and native state locks are both on.
  • At least one policy check runs before apply.
  • prod needs a second approver.
  • Drift is checked on a schedule.
  • You know the licence and paid limits of every component you deploy.
  • The tool version is pinned; upgrades follow the release notes.

No hands-on drill

No hands-on drill was run for this post. Everything above comes from the official repositories, licence files, release pages and documentation listed below, checked on 8 November 2026. Try any of these tools on a non-production directory before you trust it with prod.

Closing

Running apply from a laptop is a habit worth unlearning. Learn where each tool runs the binary and keeps the credentials, unlearn the idea that the state lock is enough, re-learn how your team approves a change, practise on one dev folder, and apply the same path to every environment.

Sources

comments powered by Disqus

Releted Posts

Kubernetes multi-tenancy in 2026: revisit vCluster, Capsule and Kamaji before you hand another team its own cluster

Sooner or later a platform team gets the same request again. A product squad wants “its own cluster” because it needs to install an operator with cluster-scoped CRDs, a data team wants admin rights to try a new scheduler, and a customer-facing team asks for hard isolation because an auditor said so.

Read more

Data quality in 2026: revisit Great Expectations, Soda Core and Elementary before you trust another dashboard number

When a dashboard loads and the chart looks clean, many teams treat the number as truth. The next habit is worse: if finance, sales and product argue about different figures, somebody opens a spreadsheet and “fixes” the number by hand for the meeting.

Read more

Kubernetes cost visibility in 2026: revisit OpenCost, Kubecost and Robusta KRR before you buy another FinOps tool or add another node

When the cloud bill jumps, many teams reach for one of two habits. The first is to add another node because some pods are Pending and nobody wants an outage.

Read more