CI/CD for Terraform is tricky. To make life easier, specialised CI systems aka TACOS exist - Terraform Cloud, Spacelift, Atlantis, etc.
But why have 2 CI systems? Why not reuse the async jobs infrastructure with compute, orchestration, logs, etc of your existing CI?
Digger runs terraform natively in your CI. This is:
- Secure, because cloud access secrets aren't shared with a third-party
- Cost-effective, because you are not paying for additional compute just to run your terraform
- Terraform plan and apply in pull request comments
- Private runners - thanks to the fact that there are no separate runners! Your existing CI's compute environment is used
- Open Policy Agent (OPA) support for RBAC
- PR-level locks (on top of Terraform native state locks, similar to Atlantis) to avoid race conditions across multiple PRs
- Terragrunt, Workspaces, multiple Terraform versions, static analysis via Checkov, plan persistence, ...
- Drift detection
Digger has 2 main components:
- CLI that runs inside your CI and calls terraform with the right arguments
- Orchestrator - a minimal backend (that can also be self-hosted) that triggers CI jobs in response to events such as PR comments
Digger also stores PR-level locks and plan cache in your cloud account (DynamoDB + S3 on AWS, equivalents in other cloud providers)
We love contributions. Check out our contributing guide to get started.
Not sure where to get started? You can:
- Book a free, non-pressure pairing session / code walkthrough with one of our teammates!
- Join our Slack, and ask us any questions there.
Digger collects anonymized telemetry. See usage.go for detail. You can disable telemetry collection either by setting telemetry: false
in digger.yml, or by setting the TELEMETRY
env variable to false
.
atlas migrate apply --url $DATABASE_URL