Digger

An honest look at the open-source orchestrator that puts Terraform automation back into your GitHub Actions — now rebranded as OpenTaco.

TL;DR

• What it is: Open-source (MIT) Terraform/OpenTofu orchestration tool that runs inside your existing CI (GitHub Actions, GitLab CI, etc.) instead of shipping a separate runner platform [1].
• Rebrand alert: As of November 7, 2025, the project was renamed from Digger to OpenTaco. The company is still Digger Inc., and the engine is the same — but docs are moving to docs.opentaco.dev [1].
• Stars: 4,886 on GitHub [2]. MIT licensed. Backend is minimal Go; state locks live in your own DynamoDB + S3 (or cloud equivalents) [1].
• Replaces: Atlantis (self-hosted), Terraform Cloud / HCP Terraform, Spacelift, Env0 — the category HashiCorp alumni named “TACOs” (Terraform Automation and Collaboration Operations) [1].
• Pricing: The scraped website had no pricing table, so I’m not going to invent one. The README only promises “unlimited runs and unlimited resources-under-management on all tiers” [1]. If you self-host the orchestrator, your cost is your own CI minutes plus a few dollars of DynamoDB + S3.
• Not for: Non-technical founders flying solo. You need someone on the team who already writes Terraform. If that’s not you, skip this review — or read it to understand what your DevOps hire will be picking.
• Good for: Teams already on GitHub Actions who want PR-commented terraform plan/apply, drift detection, OPA-based RBAC, and PR-level locking without paying per-resource fees to a SaaS.

---

What is Digger

Digger is a thin orchestrator for running Terraform and OpenTofu inside the CI system you already have. Instead of running Terraform jobs on a vendor’s runners (Terraform Cloud, Spacelift) or hosting a dedicated server (Atlantis), Digger splits itself in two [1]:

1. A CLI that runs inside a standard CI job, shells out to terraform, and reports results back.
2. An orchestrator — a minimal backend that listens for events like PR comments and triggers the right CI job. You can use Digger’s hosted orchestrator or self-host it.

State-level coordination (PR locks, plan cache) goes into DynamoDB + S3 on AWS, with equivalent services on GCP and Azure [1]. Nothing sensitive — not your state, not your plan output, not your cloud credentials — gets shipped to Digger’s servers in the self-hosted flow. The compute and the secrets stay inside your CI environment.

The GitHub repo sits at 4,886 stars, MIT-licensed, under diggerhq/digger [2]. The company behind it is Digger Inc., which as of November 7, 2025 announced the project rebrand to OpenTaco [1]. The positioning also shifted: before the rebrand, Digger was pitched as “best-in-class Terraform PR automation, an improvement on Atlantis.” After, it’s pitched as “the only piece of software you need to run Terraform or OpenTofu in production” [1]. Same engine, bigger ambition. Docs are now mirrored at docs.digger.dev and docs.opentaco.dev.

If “TACOs” is a new term: it’s the semi-ironic category name for tools like Terraform Cloud, Spacelift, and Atlantis — the layer that exists because raw Terraform + a shared state bucket + a team of engineers on the same code produces race conditions, missed drift, and the occasional production fire [1].

---

Why people choose it

Four honest reasons, based on what the README and the real-world write-ups actually describe:

1. No duplicate CI system. If you already pay for GitHub Actions minutes, paying Terraform Cloud for its own runners is paying twice for the same CPU. Digger runs the plan/apply inside your existing Actions workflow [1]. One CI, one billing line, one audit log.

2. Secrets don’t leave. With Terraform Cloud or Spacelift, your AWS keys, database passwords, and whatever else your Terraform touches have to be shared with a third-party. With Digger’s self-hosted orchestrator, jobs run in your CI and sensitive values stay there [1]. For regulated industries this is often the deciding factor.

3. Pull-request ergonomics comparable to Atlantis, without running Atlantis. Atlantis is a great tool, but you have to host the server, keep it patched, give it webhook ingress, and make sure it doesn’t become a single point of failure. Digger gets you the same atlantis plan / atlantis apply style PR-comment workflow without owning that server [1].

4. OPA-based RBAC. Open Policy Agent integration means you can write policies like “only users in the platform group can apply to prod/* workspaces” and enforce them at the orchestrator level [1]. This is a step up from Atlantis’s simpler model and avoids paying for Terraform Cloud’s team-tier RBAC.

The tradeoffs are real too. Writing Terraform is still writing Terraform. Digger doesn’t give you a UI for non-engineers to click around. If you want that, look at Spacelift or HCP Terraform.

---

Features

Pulled straight from the README, not marketing copy [1]:

• Plan and apply from PR comments. Type digger plan on a pull request, the CI runs terraform plan, the output comes back as a PR comment. Same for apply.
• Private runners. No separate compute pool. Whatever GitHub Actions runners (or GitLab runners) you already have — that’s where Terraform runs.
• PR-level locks. On top of Terraform’s native state locks, Digger adds a PR-level lock so two open pull requests can’t both try to mutate the same workspace and race each other. This is the same model Atlantis uses.
• OPA policies. Role-based access control via Open Policy Agent.
• Terragrunt support. If you’re on Terragrunt, it works.
• Workspaces. Multiple Terraform workspaces per repo.
• Multiple Terraform versions. Different versions pinned per project.
• Static analysis via Checkov. Security/compliance scanning on plans.
• Plan persistence. Plans from the PR are cached and reused at apply time so you’re applying what you reviewed.
• Drift detection. Scheduled runs that compare real cloud state to what Terraform thinks exists.
• Apply-after-merge. Optional workflow where apply only runs after the PR is merged to main, rather than from a PR comment.
• Web UI. A hosted dashboard option if you want one. Not required.

What’s missing compared to Terraform Cloud: no built-in private module registry (you use your git repo instead), no native cost estimation UI (you can bolt on Infracost in the CI job yourself), no Sentinel — but OPA covers that ground with a more open ecosystem.

---

Pricing: SaaS vs self-hosted math

Honest disclosure: the website bodyText scraped empty, so I don’t have a current pricing page to cite [2]. The README says “unlimited runs and unlimited resources-under-management on all tiers” [1], which is the one hard claim I’ll stand behind. Anything more specific would be making numbers up.

What I can do is the comparison math, which is where most founders actually care:

• Terraform Cloud / HCP Terraform charges per resource under management. A team of five managing a moderately-sized AWS account can land in the four-figures-per-month range quickly.
• Spacelift charges per worker and per user, with similar total-cost-of-ownership.
• Atlantis is free and open-source, but you’re paying in sysadmin time: hosting the server, ingress, TLS, upgrades, backups of the locking DB.
• Digger self-hosted is free (MIT). Your only real costs are:
  • GitHub Actions minutes you’d probably be spending anyway.
  • A DynamoDB table and an S3 bucket — realistically under $5/month for most teams [1].
  • If you self-host the orchestrator: one small VM or a container on whatever you already run.

The “unlimited resources” claim in the README is the headline differentiator against Terraform Cloud [1]. If you’re staring at an HCP Terraform bill that scales with your infra, that matters.

For the hosted Digger orchestrator option, I cannot quote tier prices from the scrape. Check https://digger.dev directly before committing.

---

Deployment reality check

This is not a five-minute install. It’s not a two-hour install either, but it’s in that range if you know Terraform and GitHub Actions.

What you need before you start [1]:

• A working Terraform repo that already runs somewhere.
• GitHub Actions (or GitLab CI) already set up with secrets for your cloud provider.
• AWS account (or GCP/Azure) where Digger will create a DynamoDB table and S3 bucket for locks and plan cache.
• The Digger CLI installed as a step in your workflow YAML.
• A digger.yml config in the repo describing your projects/workspaces.

The official guides cover GitHub Actions + AWS and GitHub Actions + GCP [1]. A Japanese engineer’s writeup on Zenn.dev walks through a concrete setup with a working example repo and concludes they prefer Digger over both Terraform Cloud and Atlantis [4].

Gotchas to expect:

• First-time setup of the DynamoDB locks table requires IAM permissions. If your cloud account is locked down, you’ll spend time on IAM before you spend time on Digger.
• The PR-comment webhook requires the orchestrator to receive GitHub events. If you self-host the orchestrator behind a VPN, you need to expose a webhook endpoint — usually via a small public-facing proxy.
• Terragrunt users: it works, but configuration is more involved than vanilla Terraform. Budget extra time.
• If you use apply-after-merge, plan caching timing matters. Stale plans are a real failure mode across all TACOs, not just Digger.

Digger is used in production by Converge Bio, who wrote up their setup as “production-ready Terraform setup powered by Digger CI/CD” [3], and reportedly by Brevo’s data ops team [1]. Two Japanese engineering blogs on Qiita and Hatenablog cover real workflow examples [1]. That’s a reasonable but not overwhelming track record — roughly what you’d expect for a 4,886-star project [2].

---

Pros / Cons

Pros

• MIT license. Fork it, audit it, run it forever.
• No duplicate CI. Runs inside Actions/GitLab where your pipeline already lives [1].
• Secrets and state stay in your cloud. Nothing ships to a third-party in the self-hosted flow [1].
• PR-comment UX comparable to Atlantis, without hosting Atlantis [1].
• OPA-based policies are a real step up from Atlantis-style access control [1].
• “Unlimited resources-under-management” per the README — a direct jab at HCP Terraform’s pricing model [1].
• Active project — the rebrand to OpenTaco signals the company is doubling down, not winding down [1].

Cons

• The rebrand to OpenTaco in November 2025 means documentation, URLs, and search results are split between old and new names for the foreseeable future [1]. Annoying.
• Requires Terraform knowledge. Not a founder-friendly tool in the Zapier sense.
• Pricing unclear. Website scraped empty on current tier pricing — needs direct verification before committing [2].
• Smaller ecosystem than Terraform Cloud. Fewer integrations, smaller community than HashiCorp’s commercial offering.
• Self-hosting the orchestrator is technically optional but practically needed if you want everything in-cloud. That’s another small service to run.
• No native private module registry — you use git, which is fine but different from TFC.

---

Who should use this / who shouldn’t

Use Digger if:

• You have at least one engineer who writes Terraform or OpenTofu for a living.
• You’re already on GitHub Actions or GitLab CI and don’t want a second runner system.
• You’re currently paying HCP Terraform per-resource and the bill is getting uncomfortable.
• You’re running Atlantis but tired of babysitting the server.
• Compliance or paranoia (both legitimate) means secrets can’t leave your cloud.

Skip Digger if:

• You don’t have Terraform in your stack. This tool solves a problem you don’t have.
• You’re a non-technical founder without a DevOps person on the team. This is not a click-and-go SaaS. Hire the person first, then pick the tool.
• You need a polished UI for non-engineers to manage infrastructure. HCP Terraform or Spacelift still win on UX for that audience.
• Your Terraform codebase is three resources in one file. You don’t need a TACO yet — terraform apply from a laptop is fine.

---

Alternatives worth considering

• Atlantis — the original open-source PR-automation tool. Free, battle-tested, but you host the server.
• Terraform Cloud / HCP Terraform — HashiCorp’s SaaS. Polished, expensive, per-resource pricing.
• Spacelift — commercial TACO with strong policy tooling. Not open-source.
• Env0 — another commercial TACO, more UI-focused.
• Scalr — similar commercial play.
• Plain terraform apply from a CI job you write yourself — genuinely fine for small teams. Don’t pick a TACO before you need one.

---

Bottom line

Digger — soon known everywhere as OpenTaco — is the most credible open-source answer to “how do we run Terraform in a team without paying HCP Terraform per resource.” It runs in the CI you already have, keeps secrets in the cloud you already own, and gives you PR-comment workflows that feel like Atlantis without the server-hosting tax [1]. The rebrand in late 2025 is a near-term documentation headache but a positive long-term signal [1]. If you have a Terraform stack and a DevOps engineer, it’s worth a weekend of evaluation. If you don’t have either, no tool in this category will help you yet.

---

Sources

1. Digger GitHub README — https://github.com/diggerhq/digger — includes the November 7, 2025 OpenTaco rebrand announcement, full feature list, comparison to Atlantis and Terraform Cloud, state storage design, and real-world usage references.
2. Digger official website — https://digger.dev — 4,886 GitHub stars; pricing page was empty at time of scrape.
3. Converge Bio, “Production-ready Terraform setup powered by Digger CI/CD” — https://medium.com/@DiggerHQ — real-world production usage writeup.
4. Zenn.dev (Japanese), “I like Digger more than Terraform Cloud and Atlantis” — https://zenn.dev/kiwamizamurai/articles/48594bcad234fb — practitioner review with working example repo.