Introducing Digger v4.0

Launching Digger Pro & a brief note on our iterative journey so far

We have been building Digger for over 2 years with multiple iterations in between. Today we are launching Digger v4.0 - An Open Source GitOps tool for Terraform.

A brief history of our journey:

🚜 Digger Classic (v1.0)

Initial focus was to build a “heroku experience in your AWS”.

We wanted to handle everything from infrastructure, CI, monitoring, logs, domains support etc. There were several design issues in this version:

The split from services to environments confused users a lot

Several types of deployments (infrastructure, software) confused customers, they didn’t know when infrastructure is needed versus a software deployment

The concept of “environment target” for the whole infrastructure had its limitations especially for customisation of existing infrastructure.

This led to the birth of Axe,

🪓 AXE (v2.0)

With AXE project we wanted to improve some UX points by focusing more on “apps” which are individuals pieces that developer would want to deploy.

The main idea was to have the ability to capture whole environment was missing in this model, it was something that was appreciated in classic (albeit confusing)

While infrastructure generation was more flexible in this model, there were still pieces which didn’t fit such as creation of VPC and other common cross-app resources. This could have been solved with more thought and notion of app connectivity.

Biggest problem was reliability. Since we were taking on responsibility of creating infrastructure and building and deploying successfully, our success rate for users was not high. This affected our ability to attract more users and grow the product

This subsequently led to the birth of v3.0, Trowel,

🧑‍🌾 Trowel (v3.0)

In this version we limited our scope further to generating and provisioning infrastructure-as-code. The idea was to introduce a “build step” for Terraform - the user describes the infrastructure they want in a high-level config file, that is then compiled into Terraform. Or perhaps a “framework” to abstract away the implementation details, similar to Ruby on Rails.

We no longer touched application deployment, meaning that we could focus on the core proposition infrastructure generation and customizability. This however, did not seem to interest end users we were speaking to. The challenging part was not so much writing the terraform code but rather making sure it’s provisioned correctly. The framework idea still looks promising, we haven't fully explored it yet; but even with a perfect framework in place that produces Terraform, you'd still need something to take the output and make sure the changes are reflected in the target cloud account. This was the one missing piece in the toolchain we decided to further “zoom into”.

🧑‍🌾 Digger (v4.0)

Digger is an open-source alternative to Terraform Cloud. It makes it easy to run terraform plan and apply in the CI / CD platform you already have, such as Github Actions.

A class of CI/CD products for Terraform exists (Spacelift, Terraform Cloud, Atlantis) but they are more like separate full-stack CI systems. We think that having 2 CI systems for that doesn't make sense. The infrastructure of asynchronous jobs, logs etc can and should be reused. Stretching the "assembly language" parallel, this is a bit like the CPU for a yet-to-be-created "cloud PC".

So it boils down to making it possible to run Terraform in existing CI systems. This is what Digger does.

Some of the features include:

• Any cloud: AWS, GCP, Azure
• Any CI: GitHub Actions, Gitlab, Azure DevOps
• PR-level LocksPlan / apply preview in comments
• Plan Persistence
• Workspaces support
• Terragrunt support
• PRO (Beta): Open Policy Agent & Conftest
• PRO (Beta): Drift detection (via Driftctl)
• PRO (Beta): Cost Estimates (via Infracost)

Do give it a try and let us know what you think. Here is a link to the contribution guide, if you are interested.

PS - We launched on Product Hunt today, please do check it out. Link here.