Digger

Digger (rebranded to OpenTaco in late 2025) is an open source Infrastructure as Code orchestration tool that enables Terraform and OpenTofu automation directly within your existing CI/CD pipeline. Instead of routing infrastructure secrets and compute through a third-party TACOS platform, Digger runs IaC commands inside the same GitHub Actions or GitLab CI runners your team already trusts and manages.

At its core, Digger consists of a CLI that runs inside CI jobs and a lightweight orchestrator backend that triggers those jobs in response to pull request events. PR-level locks prevent race conditions across concurrent branches, while plan caching and OPA-based RBAC policies give teams fine-grained control over who can apply infrastructure changes and when.

The project supports Terraform, OpenTofu, Terragrunt, and multiple Terraform versions in the same monorepo. Cloud state backends (DynamoDB and S3 on AWS, equivalents on GCP and Azure) replace any need for Terraform Cloud’s remote state. Drift detection continuously monitors deployed infrastructure against IaC source of truth, and apply-after-merge workflows automate the final deployment step.

Digger’s architecture cleanly separates the orchestrator backend from the compute layer. The backend can be cloud-hosted via Digger’s SaaS offering or fully self-hosted via Docker Compose, Kubernetes Helm charts, or binary deployment. This gives teams the flexibility to stay open source while still benefiting from a managed control plane if desired.

What You Get

• PR-driven Terraform automation - Digger responds to GitHub, GitLab, or Bitbucket pull request comments (digger plan, digger apply) by triggering your CI pipeline to run the corresponding Terraform or OpenTofu command and posting the output back as a PR comment.
• Private runners with zero additional compute - Because Terraform runs execute inside your existing CI environment, there are no external workers to provision, pay for, or secure; your cloud credentials never leave your own runners.
• PR-level distributed locking - Locking is implemented on top of AWS DynamoDB, GCP, or Azure equivalents so concurrent PRs touching the same project are safely serialized without requiring a persistent server to hold lock state.
• OPA policy enforcement - Access, plan, apply, and drift policies are evaluated using Open Policy Agent, giving platform teams declarative control over who can trigger which IaC operation and under what conditions.
• Drift detection with remediation paths - Scheduled drift detection checks deployed infrastructure against the IaC source of truth and surfaces differences through Slack, GitHub Issues, or your existing PR/apply workflow.
• Multi-tool and multi-version IaC support - The same pipeline handles Terraform, OpenTofu, Terragrunt, and multiple tool versions in a single monorepo, with Checkov static analysis and plan persistence included.
• Self-hostable orchestrator backend - The backend that coordinates webhook events and job triggers can be deployed via Docker Compose, Kubernetes Helm chart, binary, or Railway, or used as Digger’s hosted SaaS with unlimited runs on all tiers.

Common Use Cases

• Production Terraform automation across multiple AWS accounts - Platform engineering teams use Digger to gate infrastructure changes behind PR reviews and OPA policies, applying changes only after approval, without granting external systems access to production credentials.
• Multi-environment GCP deployments with workspace isolation - Data engineering teams configure separate Terraform workspaces for dev, staging, and prod in different GCP projects, with Digger dispatching the correct workspace-aware CI job per PR.
• Replacing Atlantis without hosting a server - Security-focused teams migrate from Atlantis to eliminate the risk surface of a persistent webhook server, gaining the same PR-comment workflow while running jobs on GitHub-managed or self-hosted runners they already trust.
• Apply-after-merge automation for SaaS infrastructure - Product teams configure Digger to auto-apply Terraform on merge to the default branch, reducing manual apply steps while keeping plan output visible in the PR before it closes.
• Monorepo IaC with project-scoped locking - Monorepos containing dozens of Terraform modules use Digger’s project detection and per-project locks to run plans in parallel across unrelated modules while safely serializing concurrent changes to the same stack.
• Continuous drift monitoring for compliance - Compliance-driven organizations schedule regular drift detection across all projects to catch out-of-band changes made directly in cloud consoles and route remediation through the standard PR/apply workflow.

Under The Hood

Architecture Digger is structured as two cooperating components: a Go CLI that runs inside CI workers and a Go backend service that acts as the orchestration layer. The backend receives VCS webhook events via Gin HTTP handlers, validates and parses them, then dispatches GitHub Actions workflow events (or equivalent) back into the user’s own CI environment. PR-level locks and plan artifacts are stored in user-controlled cloud storage (DynamoDB and S3 on AWS, Cloud Storage on GCP, Blob Storage on Azure), so the backend itself remains stateless between requests. A separate enterprise edition backend and a growing OpenTaco layer extend the open core with additional VCS providers, RBAC, and a web UI, housed in the same monorepo under ee/ and taco/. The separation between orchestration logic in the backend and execution logic in the CLI is a deliberate design choice that eliminates the need for outbound connectivity from the backend to user infrastructure, reducing the attack surface materially.

Tech Stack The primary language is Go, comprising over 74% of the codebase, with the Gin web framework powering the backend HTTP layer and slog used throughout for structured logging. The CLI and backend share library code through a libs/ monorepo module covering locking, scheduling, policy evaluation, CI provider abstractions, and plan storage. Policy enforcement uses the Open Policy Agent Go library evaluated inline. The enterprise UI is built with TypeScript and React, exposed as a Next.js application. Database migrations are managed with Atlas against PostgreSQL. The project ships as Docker images with Helm charts for Kubernetes and a fly.toml for Fly.io deployments. GitHub’s official Go SDK (google/go-github) handles all GitHub API interactions, and AWS SDK v2, GCP, and Azure SDKs provide cloud-provider locking and storage backends.

Code Quality The test suite is modest in scope — approximately 35 test files concentrated in libs/ covering locking, scheduling, policy, and JSON models, with limited coverage in the CLI and backend layers. The testify library is used consistently for assertions. Code follows idiomatic Go conventions with structured error returns, consistent naming, and slog-based observability. The backend controller layer is well-organized around a dependency-injected DiggerController struct, though several controller files directly instantiate services rather than accepting interfaces. The libs/ layer demonstrates cleaner interface-based design, with NoOp implementations of locks, policy checkers, and CI services enabling unit testing without external dependencies. CI runs on GitHub Actions with matrix builds and linting.

What Makes It Unique Digger’s core differentiator is architectural: by treating the CI pipeline itself as the execution environment rather than operating its own runner fleet, it eliminates the operational and security costs that define managed TACOS platforms. Cloud credentials are never transmitted to a third-party service; they live only in the CI environment where they were already configured. The PR-level locking scheme built on user-owned cloud storage means lock state survives backend restarts without any distributed consensus mechanism. The OPA policy integration brings Rego-based declarative policy evaluation to IaC access control without requiring a standalone OPA server. As of late 2025, the project is expanding into a broader vision under the OpenTaco name — moving beyond PR automation toward a full self-hostable alternative to Terraform Cloud with state management, RBAC, and remote execution as distinct composable layers.

Self-Hosting

Digger is released under the MIT License, which is one of the most permissive open source licenses available. You are free to use, modify, distribute, and run Digger commercially without restriction. There are no copyleft obligations, meaning you are not required to open source modifications you make to the codebase. The MIT terms apply equally to the core CLI and the community edition backend. The enterprise edition (under ee/) and the hosted Digger SaaS are separate commercial offerings with their own terms, but the open core is unrestricted.

Self-hosting the Digger backend requires running a Go service connected to a PostgreSQL database. Deployment options include Docker Compose for straightforward single-server setups, Helm charts for Kubernetes, a pre-built binary, or Railway one-click deployment. You are responsible for provisioning and maintaining the PostgreSQL database, configuring a GitHub App with the appropriate webhook URLs and permissions, managing TLS termination, and keeping the backend updated as new releases ship (typically several times per month). The backend itself is stateless between requests — lock state lives in your cloud storage account and job output in your CI logs — so horizontal scaling and restarts are operationally simple. The primary operational burden is the GitHub App setup and PostgreSQL management rather than the service runtime itself.

Digger’s cloud-hosted offering removes all of that operational burden: GitHub App setup is handled through a wizard, the backend is managed and updated automatically, and all tiers include unlimited runs and unlimited resources under management. The cloud tier adds a web UI (currently in beta under the OpenTaco rebrand), managed plan storage, Slack notifications for drift, and commercial support. Teams self-hosting the community edition give up the managed UI, automatic upgrades, and direct support channels, but retain full control over their data and infrastructure access patterns. For teams already comfortable managing a small Go service and PostgreSQL, the self-hosted path is straightforward; for teams that want zero operational overhead on the IaC tooling layer, the hosted offering is the practical alternative.