HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
diggerhq
digger
Go2023–2024
diggerhq / digger

digger

Digger is an open source IaC orchestration tool. Digger allows you to run IaC in your existing CI pipeline ⚡️

5Distinct people
12Mentions
0Explicit recommenders
5.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Digger is an open source IaC orchestration tool. Digger allows you to run IaC in your existing CI pipeline ⚡️

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month12 dated mentions

Observed mentions: 2023-03-21 19:41:28 UTC to 2024-06-24 16:53:01 UTC.

0122023-03-01 00:00:00 UTC to 2023-04-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsMar 20232023-04-01 00:00:00 UTC to 2023-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-05-01 00:00:00 UTC to 2023-06-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2023-06-01 00:00:00 UTC to 2023-07-01 00:00:00 UTC (exclusive): 2 mentions; 2 submissions, 0 comments2023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-09-01 00:00:00 UTC to 2023-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsOct 20232023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2024-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-02-01 00:00:00 UTC to 2024-03-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2024-03-01 00:00:00 UTC to 2024-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-01 00:00:00 UTC to 2024-05-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2024-05-01 00:00:00 UTC to 2024-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-01 00:00:00 UTC to 2024-07-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJun 2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Mar 20232023-03-01 00:00:00 UTC2023-04-01 00:00:00 UTC211
Apr 20232023-04-01 00:00:00 UTC2023-05-01 00:00:00 UTC000
May 20232023-05-01 00:00:00 UTC2023-06-01 00:00:00 UTC110
Jun 20232023-06-01 00:00:00 UTC2023-07-01 00:00:00 UTC220
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC211
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC202
Sep 20232023-09-01 00:00:00 UTC2023-10-01 00:00:00 UTC000
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC000
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC000
Dec 20232023-12-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
Jan 20242024-01-01 00:00:00 UTC2024-02-01 00:00:00 UTC000
Feb 20242024-02-01 00:00:00 UTC2024-03-01 00:00:00 UTC110
Mar 20242024-03-01 00:00:00 UTC2024-04-01 00:00:00 UTC000
Apr 20242024-04-01 00:00:00 UTC2024-05-01 00:00:00 UTC110
May 20242024-05-01 00:00:00 UTC2024-06-01 00:00:00 UTC000
Jun 20242024-06-01 00:00:00 UTC2024-07-01 00:00:00 UTC110

What Hacker News says

12 sources
iacguy·Jun 24, 2024Submission

Ask HN: How do we price the enterprise edition of our open source product?

Pricing an open source project is tricky. Especially so because the traditional COSS strategy of the last 10 years used by the likes of Mongo DB, Hashicorp and others, has received flak for the “BUSL rug-pull”. It is our firm belief that Digger will continue to be Open Source, and we have built the product around gitlab’s buyer based open core model [1] from day 1. The enterprise edition features around collaboration and governance would be what people would pay for, with the features around automation being free. This however, presents somewhat of a chicken-egg challenge in the early stages. Being a super small team, while the community edition brings us user love, the features in the enterprise edition brings us revenue, and for sustainable continuance of the product for both CE and EE features, we need to prioritise the requests and fe
Read the rest
atures of users that are willing to pay. We have slowly started figuring out the features that people would pay for and we are working hard to onboard our enterprise customers. But a question we repeatedly get asked is: how are you thinking about pricing? Why is it not transparent? The simple answer is that we are still figuring it out. The complex answer, is detailed in our current thesis below: We think that where Digger wins amongst its existing user base is that most “middle tier” features amongst competitors can be used for free either via self hosting the community edition or via using the free automation tier. Digger’s collaboration tier also presents a significant advantage vs competition in that it doesn’t charge “self hosting” tax, and allows users to self host the features available in the collaboration tier at no additional cost. Now coming to the governance tier, Digger allows users to consume the features in this tier via their preferred means, and also has a bunch of governance features such as SSO, Audit trails, log forwarding and private VCS support which are often hard enterprise requirements. We’d love the community’s feedback on this. Both regarding the feature split and on the actual pricing. We've also created a github issue regarding this: https://github.com/diggerhq/digger/issues/1589 [1]: https://handbook.opencoreventures.com/open-core-business-model/#764604b5c6db4107bb…
1 points · Open discussion
igorzij·Apr 3, 2024Submission

Ask HN: Should we build support for more CI platforms, or features for Actions?

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!
4 points · Open discussion
igorzij·Feb 19, 2024Submission

Ask HN: Should open-source projects allow disabling telemetry?

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?
27 points · Open discussion
To copy the comment from Reddit https://old.reddit.com/r/Terraform/comments/15o9mzt/openterr... > Funny enough, our own product (Digger, an open-source CI runner for Terraform) is not using Terraform (or any other Hashicorp's code) under the hood. Oh yes you are: https://github.com/diggerhq/digger/blob/develop/pkg/core/ter... You're on thin ice if you want to argue whether forking a terraform process constitutes "hosting" or "embedding" terraform.
In OpenTerraform – an MPL fork of Terraform after HashiCorp's license change
We are in some sense a competitor too, alongside Spacelift, Env0, Scalr and a few others. Our product is built differently though, Digger is orchestrating terraform jobs in your existing CI instead of taking over the whole CI stack and effectively duplicating it just to run terraform. We built it this way almost by accident; our original product was very different (think "heroku-like UI for AWS" that generated and ran terraform on the server) and this is how we arrived at what Digger is now. Luckily we don't seem to be affected by the licensing change as we neither embed nor distribute any of hashicorp's code (it's on the user to set up the right version of it in say GH Actions). https://github.com/diggerhq/digger Anyways, fully agree that if you have a great product, you don't need to make such moves. We designed our product the way we d
Read the rest
id purely out of technical considerations - it didn't seem to make any sense to duplicate the CI stack. But it looks like this whole idea behind Terraform Cloud of having an "infra-specific CI" was driven exclusively by commercial interest. You can charge per minute! You can charge even more per resource! Now it's catching up with Hashi; so they have to make such defensive moves. If the product made sense technically, if it was designed the way someone would design it with no commercial considerations whatsoever, they wouldn't have to make such moves.
In OpenTerraform – an MPL fork of Terraform after HashiCorp's license change

Show HN: Digger, an OS Alternative to Terraform Enterprise Now Has RBAC via OPA

Digger's (https://github.com/diggerhq/digger) Open Policy Agent (OPA) integration for role based access control that we shipped last week extends Digger's existing capabilities by enabling you to define custom policies for fine-grained control over who can do what within your infrastructure. This feature was highly requested by users as it makes it easier to enforce compliance requirements, implement security best practices, and maintain a well-governed infrastructure environment with granular control. Please do share your feedback!
2 points · Open discussion

Ask HN: Folks who use Atlantis for Terraform Self Service – what pains you?

We are building an Open Source GitOps tool for Terraform (https://github.com/diggerhq/digger) and are looking for what’s missing. We also read & asked around. We found the following pain points already, curious for more: 1. In Atlantis,anyone who can run a plan, can exfiltrate your root credentials(https://www.youtube.com/watch?v=H9KvPe09f5A). This was talked about by others (https://alex.kaskaso.li/post/terraform-plan-rce) and was highlighted at the Defcon 2021 conference(https://www.youtube.com/watch?v=3ODhxYY9-9U). (CloudPosse) 2. “Atlantis shows plan output, if it's too long it splits it to different comments in the PR which is not horrible, just need to get used to it.” (User feedback) 3. Anyone that stumbles upon your Atlantis instance can disable apply commands, i.e. stopping production infrastructure changes. This isn’t obvious a
Read the rest
t all, and it would be a real head scratcher to work out why Atlantis suddenly stopped working! (Loveholidays blog - https://tech.loveholidays.com/enforcing-best-practice-on-self-serve-infrastructure…) 4. “Atlantis does not have Drift Detection.” (Multiple users) 5. “The OPA support in atlantis is very basic.” (Multiple users) As CloudPosse themselves explain (https://cloudposse.com/faqs/why-do-you-recommend-spacelift/) - “Atlantis was the first project to define a GitOps workflow for Terraform, but it's been left in the dust compared to newer alternatives.” The problem though is that none of the newer alternatives are Open Source, and this is what we want to change. Would be super grateful for any thoughts/insights and pain points you have faced.
2 points · Open discussion
Why are we doing this? We built digger to enable teams to be able to run terraform plan/apply within their existing CI. The tool is entirely open-source and we are looking for feedback and contributions. This would also help us spread the word amongst terraform cloud users. All you have to do is use the quick start guide in our github repo below, and after you've used it or tested it, send me (utpal) a slack (link below) message of your email and I can send the gift card over! Only constraint is that you are an active Terraform Cloud/ Spacelift/ Atlantis/ Env0 user and understand the problem space. Thanks all - genuinely appreciate your feedback and contributions! LINKS Github repo - https://github.com/diggerhq/digger Slack -https://join.slack.com/t/diggertalk/shared_invite/zt-1atmgf1...
In We'll pay you $25 to use our Open Source Terraform Cloud Alternative

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.