# Digger: Terraform PR Automation That Runs Inside Your Existing CI

> Digger is an MIT-licensed IaC orchestration tool that runs Terraform in your own CI pipeline instead of a hosted runner. Here is how its CLI and orchestrator fit together, what the setup looks like, and where the approach stops being the right one.

**diggerhq/digger** — Digger is an open source IaC orchestration tool. Digger allows you to run IaC in your existing CI pipeline ⚡️  

- Repository: https://github.com/diggerhq/digger
- Website: https://digger.dev
- Stars: 5,045 · Forks: 611
- Language: Go
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/diggerhq-digger

## The problem Digger targets: two CI systems for one Terraform change

A pull request that changes infrastructure has to pass through two separate systems. The application code goes through your CI. The Terraform goes through a specialised CI, which the README calls a TACO and lists as Terraform Cloud, Spacelift and Atlantis. That second system brings its own compute, its own orchestration, its own log store and its own secret handling, and the README's framing is blunt about the cost: "Why have 2 CI systems?"

Digger's answer is to reuse the async job infrastructure you already pay for. The README states that jobs run in your CI, so cloud access secrets are not shared with a third party, and you are not paying for additional compute just to run Terraform. The audience is therefore specific: teams with an established CI pipeline, a Terraform or OpenTofu codebase, and a review process built on pull request comments. If your infrastructure changes are already gated by a hosted platform you are happy with, the pitch does not apply to you.

## Two components: a CLI in your CI and an orchestrator that triggers jobs

The README describes two main components. The CLI runs inside your CI and calls Terraform with the right arguments. The orchestrator is a minimal backend that triggers CI jobs in response to events such as PR comments, and it can also be self-hosted. The repository layout matches that split: cli/ and backend/ sit at the top level, with ui/, ee/, drift/ and libs/ alongside them, and the Go module is github.com/diggerhq/digger.

State that is not Terraform state also has a home. Digger stores PR-level locks and a plan cache in your cloud account, with DynamoDB and S3 named for AWS and equivalents on other providers. The README positions these locks as sitting on top of Terraform's native state locks, similar to Atlantis, to avoid race conditions across multiple PRs. That is the mechanism worth understanding before adoption: the lock lives one level above state, so two pull requests touching the same stack are serialised by Digger rather than by Terraform itself.

The feature list is broad: plan and apply in pull request comments, OPA support for RBAC, Terragrunt, workspaces, multiple Terraform versions, static analysis via Checkov, plan persistence and drift detection. The repository carries a drift/ directory and Dockerfiles named Dockerfile_drift and Dockerfile_bg_projects_refresh, which is consistent with drift detection being a first-class service rather than a flag.

## Installing Digger and running a first plan in GitHub Actions

The README does not contain a step-by-step install section. It points to getting-started guides for GitHub Actions with AWS and GitHub Actions with GCP, and the repository ships an action.yml at the top level, which is the entry point a workflow would reference. The commands below come from the README's own snippets for the backend side of a self-hosted deployment, not from a documented CLI install procedure.

If you run the backend yourself, the README gives the migration command and the local database URL. The migration step is applied with Atlas, and the local Postgres example disables SSL because the default Docker image does not present a certificate.

```bash
atlas migrate apply --url $DATABASE_URL --allow-dirty
```

```bash
export DATABASE_URL=postgres://postgres:root@localhost:5432/postgres?sslmode=disable
```

Telemetry is on by default. The README says Digger collects anonymised telemetry and that you can turn it off in either of two ways: setting telemetry: false in digger.yml, or setting the TELEMETRY environment variable to false.

```yaml
telemetry: false
```

For the CI side, the README points at the GitHub Actions plus AWS guide rather than reproducing the workflow. Expect to configure cloud credentials in the CI job itself, since that is the design: the secrets stay in your pipeline. After wiring the workflow and the orchestrator, the observable behaviour described in the README is plan and apply output appearing in pull request comments. The README does not document what a failed apply leaves behind, so verify that path in a sandbox project before pointing Digger at production state.

## Where the reuse-your-CI design becomes a constraint

The strongest claim in the README is also the source of its sharpest limitation. Because jobs run in your CI, Digger inherits your CI's concurrency limits, queue behaviour and runner image lifecycle. The README lists scalable compute as an advantage, noting that jobs can run in parallel, but that parallelism is bounded by whatever your CI account allows. A self-hosted runner pool sized for application builds now also carries Terraform plans.

Secret handling cuts both ways. Keeping cloud credentials in your CI means they are not shared with a third party, but it also means every person who can modify a workflow file in a pull request is closer to those credentials. Digger's OPA support for RBAC is the counterweight, and the README lists it as a feature rather than describing the policy model. If your threat model requires that policy evaluation be mandatory and auditable, read the OPA documentation before assuming the default configuration enforces it.

The lock and plan cache placement is a third constraint. Writing locks and plan cache into DynamoDB and S3 (or provider equivalents) means Digger needs write access to storage in your account, and that storage becomes part of your disaster-recovery surface. A team that wants Terraform plan artefacts to exist only for the duration of a CI run, with nothing persisted, is not the audience for this design.

Finally, the README states that the project rebranded to OpenTaco from 7 November 2025, with the company still called Digger. Documentation links in the README already point at docs.opentaco.dev for at least one guide while others point at docs.digger.dev, so expect to consult both while the naming settles.

## Digger versus Atlantis: hosted server or your CI's compute

Atlantis is the obvious comparison because the README makes it directly. Atlantis runs as a server you host and maintain; Digger's README says you do not need to host and maintain a server, though it notes you can self-host the orchestrator with Helm. The practical difference is where the Terraform process executes. With Atlantis, the server is the execution environment. With Digger, the CI runner is, and the orchestrator's job is to trigger CI jobs in response to events.

That changes failure modes. An Atlantis outage stops applies because the server is the thing doing the work. A Digger orchestrator outage stops the triggering of jobs, while the CI platform itself remains the thing that runs them. It also changes the security boundary: the README argues Digger is secure by design because sensitive data stays in your CI, whereas a hosted server holds the credentials it needs to run Terraform.

The README lists further differences: RBAC and policies via OPA, drift detection, apply-after-merge workflows and a cloud-based web UI. Atlantis users evaluating a move should treat the OPA policy model and the plan persistence path as the two areas with the least detail in the README, and read the linked documentation before deciding.

## Maintenance, licensing and what a Digger upgrade actually costs

Digger is MIT licensed, which permits commercial use and modification, and the README describes the orchestrator as open source and self-hostable. The repository also contains an ee/ directory and a Dockerfile_backend_ee, which indicates an enterprise edition built from the same tree. The README does not state what is gated behind that edition, so if your deployment depends on a specific capability, confirm which build provides it. This is a description of the licence and repository layout, not legal advice.

On maintenance, the last push to the default branch develop was on 2026-09-21, and the most recent numbered release in the list is v0.6.151 from 2026-09-13. The version numbering suggests frequent patch releases rather than a slow cadence, and the presence of .release-please-manifest.json and a changelogs/ directory points to automated release notes. There is no long-term support branch described in the README.

Upgrade cost concentrates in the orchestrator and its database. The README documents migrations via Atlas, which means schema changes are versioned and applied rather than hand-run. A self-hosted deployment therefore carries a migration step on every upgrade, and the README's example uses --allow-dirty, a flag worth understanding before you run it against a production database. The CLI side is distributed as the action referenced by action.yml, so CI workflows pin whatever version that action resolves to.

## Conclusion

Digger fits teams already running GitHub Actions or a comparable CI who want Terraform plan and apply driven from pull request comments without handing cloud credentials to a hosted service, and who are willing to operate the orchestrator and its lock and plan storage. It is the wrong tool if you have no CI pipeline to reuse, if you need a fully managed control plane, or if you want plan output to live only inside the CI run: Digger writes PR-level locks and a plan cache into your own cloud account (DynamoDB plus S3 on AWS, equivalents on other providers), so that storage has to exist and be governed. Before adopting, verify the plan persistence path end to end, confirm which Terraform and OpenTofu versions your pipelines will pin, check that OPA policy evaluation covers the RBAC rules you actually enforce, and test the rollback story for a failed apply, which the README does not document.

## FAQ

### How do I use Digger with GitHub Actions?

The README points to a getting-started guide for GitHub Actions plus AWS and another for GitHub Actions plus GCP, and the repository ships an action.yml at the top level as the workflow entry point. Cloud credentials stay in the CI job, since jobs run in your CI rather than on a Digger runner.

### Does Digger run Terraform on its own servers?

No. The README states that the CLI runs inside your CI and calls Terraform with the right arguments, while the orchestrator is a minimal backend that triggers CI jobs in response to events such as PR comments. The README frames this as secure because cloud access secrets are not shared with a third party.

### How do I disable Digger telemetry?

The README says Digger collects anonymised telemetry and that you can disable it by setting telemetry: false in digger.yml or by setting the TELEMETRY environment variable to false.

### Where does Digger store PR locks and cached plans?

According to the README, Digger stores PR-level locks and plan cache in your own cloud account, naming DynamoDB plus S3 on AWS and equivalents on other cloud providers. Those locks sit on top of Terraform's native state locks to avoid race conditions across multiple PRs.

### Is Digger the same project as OpenTaco?

The README states that from 7 November 2025 the Digger project rebranded to OpenTaco, while the company remains Digger and the engine is the same. Some documentation links in the README point at docs.digger.dev and at least one points at docs.opentaco.dev.

## Sources

- [diggerhq/digger on GitHub](https://github.com/diggerhq/digger)
- [License: MIT](https://github.com/diggerhq/digger/blob/develop/LICENSE)
- [Project website](https://digger.dev)
- [README](https://github.com/diggerhq/digger/blob/develop/README.md)
- [Releases](https://github.com/diggerhq/digger/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/diggerhq-digger