digger VS infracost

Currently, Github Actions is de-facto the only fully supported CI platform in Digger, we’ve been building it as a CI-agnostic tool (https://github.com/diggerhq/digger) from get go. We keep getting requests to support more CI systems on our community slack and over Github issues (https://github.com/diggerhq/digger/issues/81).

Unlike other automation tools for Terraform, Digger doesn’t run jobs on the server; instead it uses your CI (like Actions) as a compute backend. This is more secure and also much cheaper if you use your own runners in your CI.

But each CI and each VCS is ever so slightly different; and we are now at a crossroads - Should we build support for more CI platforms, or more features for GitHub Actions? We’d love any thoughts/inputs!

We just had a user submit an issue and a PR to revert the changes we made earlier that remove the option to disable telemetry. We feel like it’s a fair ask to share usage data with authors of an open-source tool that’s early in the making; but the user’s viewpoint is also perfectly understandable. Are we in the wrong here?

https://github.com/diggerhq/digger/issues/1179

Surely we aren’t the first open-source company to face this dilemma. We don’t want to alienate the community; but losing visibility of usage doesn’t sound great either. Give people the “more privacy” button and most are going to press it. Is there a happy medium?

Detecting and managing drift in Terraform is a multifaceted process. The use of Terraform commands such as terraform refresh and terraform plan plays a critical role in identifying drifts. Additionally, periodic monitoring of the infrastructure using these commands can aid in early detection and prevention of larger issues. Tools like Digger and Terraform Cloud offer dedicated drift detection and remediation mechanisms. These tools provide continuous monitoring and notifications, enabling teams to stay informed about the state of their infrastructure.

Star us on GitHub | Check out Docs | Blog | Slack

I would be extremely grateful if you could give us a star & share your thoughts in the comments section below https://github.com/diggerhq/digger

Check Digger's repo on GitHub

Digger is an Open Source Infrastructure as Code management tool that helps orchestrate IaC such as Terraform & OpenTofu within GitHub Actions. Digger reuses compute used for application code so that you don't overpay for 3rd party managed compute for IaC. This approach eliminates the duplication of CI/CD infrastructure such as compute, jobs, and logs, and reduces security concerns by keeping sensitive data within the CI job. Digger's integration with existing CI systems offers scalability by leveraging on-demand compute resources and enhances security by confining data within the existing CI environment.

Digger is an Open Source IaC management platform that allows you to orchestrate terraform/OpenTofu in your CI/CD system. It helps you resue async jobs infrastructure with compute, orchestration, logs, etc of your existing CI. Digger also has a pro version built on top of Digger’s community edition. Digger’s “bring your own compute” ensures that users have private runners by defualt and don’t have to pay for it additionally. Digger pro gives team leads, managers and IaC practitioners dashboards, Drift Detection, RBAC via OPA policies and concurrency so they can help guide the team.

We have this issue filed by a user and cannot quite decide internally what to do about it. It is clear that allowing everyone who comments to trigger apply is problematic. And we have this covered by the RBAC via OPA feature that allows users to set granular rego policies for who can do what. But it can also be viewed as an overkill to introduce the whole policy-as-code setup for a basic restriction like this.

‍Infracost is a cost estimation tool that generates cost estimates for Terraform projects, which is crucial for budget planning and cost optimization, especially in cloud environments where resource costs can vary significantly.

Infracost is a tool that provides cloud cost estimates for infrastructure managed by Terraform. It enables engineers to view and understand the financial impact of their infrastructure changes before they are applied. Infracost integrates directly into the workflow, offering cost breakdowns in various environments like the terminal, Visual Studio Code, or directly within pull requests. This feature allows for more informed decision-making regarding infrastructure modifications, promoting cost-awareness and budget management in the early stages of development. Infracost is particularly useful for teams looking to balance cloud resource utilization with budget constraints. Infracost Cloud is their SaaS product that builds on top of Infracost open source and works with CI/CD integrations. It gives team leads, managers and FinOps practitioners dashboards, guardrails, centralized cost policies and Jira integration so they can help guide the team (e.g. switch AWS GP2 volumes to GP3).

Inevitable end for every open source company since the free money ended. What bothers me is that wording is vague enough.

> HashiCorp considers a competitive offering to be a product or service provided to users or customers outside of your organization that has significant overlap with the capabilities of HashiCorp’s commercial products or services.

So, consider there is no cost estimate service and you built a thing that got popular (https://github.com/infracost/infracost). Then after 2 years Terraform Cloud catches up. What happens? Are you out of business?

I've started to work on Carbonifer, a tool that can estimate carbon emissions before deploying an infrastructure. A bit like infracost, this reads Terraform files and estimates carbon emissions if this plan is applied.

Infracost is an open-source project that helps us understand how and where we’re spending our money. It gives a detailed breakdown of actual infrastructure costs and calculates how changes impact them. Basically, Infracost is a git diff for billing.

Infracost: Estimativas de custos nos Pull Requests.

There is some discussion on the infracost issue tracker where it looks like this specific error is more common with tgenv

Cost:Infracost (estimation): https://github.com/infracost/infracostTerratag (tagging): https://github.com/env0/terratag (disclaimer, I am CEO at env0)

I use https://infracost.io 🤗