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
Features
- Terraform plan and apply in pull request comments
- Any VCS - Github, Gitlab, Azure Repos, etc
- Any CI - Github Actions, Gitlab, Azure DevOps, etc
- Any cloud provider - AWS, GCP, Azure
- 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 - coming soon
- Cost estimation - coming soon
Getting Started
How it works
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)
Contributing
We love contributions. Check out our contributing guide to get started.
Not sure where to get started? You can:
Resources
- Docs for comprehensive documentation and guides
- Slack for discussion with the community and Infisical team.
- GitHub for code, issues, and pull request
- Medium for terraform automation and collaboration insights, articles, tutorials, and updates.
- Roadmap for planned features.
- Digger API beta