Show HN: Digger.dev – A PaaS that generates Terraform, in your AWS account

Hi HN! Igor here, co-founder of Digger.dev<p>The learning curve for AWS is steep; but the use of tools with great develeoper experience like Heroku and Vercel is limited to small projects. Teams end up choosing AWS or other big cloud providers, partly because of free credits, but mostly because they know that they&#x27;ll need something from them that a PaaS cannot provide.<p>And then there is a huge cloud-native ecosystem and infrastructure-as-code and Kubernetes and all that. If you want to do DevOps right then PaaS doesn&#x27;t seem to be a good option.<p>So its either move fast, or build a future-proof stack. We thought that&#x27;s wrong, and built Digger.dev<p>Digger.dev automatically generates infrastructure for your code in your AWS account (Terraform). So you can build on AWS without having to deal with its complexity.<p>You can launch in minutes – no need to build from scratch, or even think of infrastructure at all!<p>- Easy to use Web UI + powerful CLI<p>- Deploy webapps, serverless functions and databases: just connect GitHub repositories<p>- Multiple environments: replicate your entire stack in a few clicks. Dev &#x2F; staging &#x2F; production; short-lived for testing; per-customer<p>- Zero-configuration CI with GitOps: pick a branch for each environment and your services will be deployed on every git push<p>- Logs, environment variables, secrets, domains: never touch AWS again!

Congratulations on the launch! I personally think that any product that attempts to simplify the experience around AWS is a worthy endeavor - which is why there are a <i>lot</i> of companies popping up trying to tackle this.<p>I personally have a lot of interest in this space and used to work at AWS. Feel free to contact me at the email in my profile if I can ever be helpful.

I like the general concept of this product, but I feel like it either needs different marketing or more thought about who this product is for.<p>It seems like the product is either:<p>(a) A tool for indie or small dev teams to build infrastructure before they have learned the AWS stack.<p>(b) A tool for small DevOps teams to simplify managing and developing their Terraform developments.<p>The marketing of the site seems to be selling scenario (a), but the paid plans make it seem like you&#x27;ll only be making money in scenario (b).<p>If I imagine myself being in scenario (a), I can see becoming pretty disillusioned the second my first issue or wall popped up, since I am not going to be supported by AWS or the product. It seems someone in this scenario is way better served by choosing a managed hosting solution of some kind.<p>As someone personally in scenario (b), the idea of &quot;do more without understanding it&quot; is a very off-putting sales pitch. Terraform and AWS have way too many gotchas to fully abstract away all but the simplest of implementations. Sweeping those under the rug with abstractions is too much risk if the team doesn&#x27;t understand what&#x27;s happening. If the pitch was something more like &quot;speed up your teams Terraform development and management experience&quot;, it would be a lot more interesting.

I think the idea is a good one. It&#x27;s too hard to set up simple solutions in AWS and abstracting that away is valuable. But you need the freedom to dive into the details sometimes, so being Terraform based is smart.<p>But the onboarding flow is brutal IMO. The splash page doesn&#x27;t help me understand when I should reach for Digger - as a customer with an AWS account, I&#x27;ve obviously had to learn enough to be functional in AWS. I would like it if you described a common use case to help me understand when I should be considering Digger.<p>Once I actually try it out, it&#x27;s very sterile and I feel lost in Apps and Environments and the UI is mentioning commits for some reason. The docs focus a lot on what Digger is, but I&#x27;m really missing an onboarding guide that orients me with a step-by-step guide of how to set up my first environment.

How does this compare to <a href="https:&#x2F;&#x2F;github.com&#x2F;GoogleCloudPlatform&#x2F;terraformer" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;GoogleCloudPlatform&#x2F;terraformer</a> -- looks like it is more continuously updating and user friendly?

Getting 404s in your docs <a href="https:&#x2F;&#x2F;github.com&#x2F;diggerhq&#x2F;digger-examples&#x2F;tree&#x2F;master&#x2F;node-service" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;diggerhq&#x2F;digger-examples&#x2F;tree&#x2F;master&#x2F;node...</a> and this is empty? <a href="https:&#x2F;&#x2F;github.com&#x2F;diggerhq&#x2F;digger-examples&#x2F;tree&#x2F;master&#x2F;django-app" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;diggerhq&#x2F;digger-examples&#x2F;tree&#x2F;master&#x2F;djan...</a>

&gt; The problem with infrastructure-as-code today (Terraform, CloudFormation, CDK, Pulumi, etc) is that it is not reusable. That is because implementation, configuration and interface are mixed up together.<p>I find this statement from the documentation[0] unfair, given that the &quot;target&quot; concept this introduces seems to be mainly based on Terraform modules to _reuse code and expose an interface_. Terraform has its problems, but this doesn&#x27;t seem to be right.<p>At best, this seems to be a curated set of Terraform modules and a managed CD pipeline execution SaaS. I get that it is supposed to simplify things, but it is lacking documentation for what it will do to an AWS account (you&#x27;ll still pay for it, after all) and even provides documentation on how to drop &quot;raw&quot; Terraform into it. Why not go with Terraform directly then instead of sending your AWS credentials to a SaaS?<p>[0] <a href="https:&#x2F;&#x2F;learn.digger.dev&#x2F;overview&#x2F;how-it-works.html#technical-design" rel="nofollow">https:&#x2F;&#x2F;learn.digger.dev&#x2F;overview&#x2F;how-it-works.html#technica...</a>

This looks interesting. All the best for your release!<p>I have a few small feedback items:<p>- The AWS Account ID is not very well blanked out in your documentation. I can easily see what the actual digits are (under the red scratched out parts). - I realise English is not your first language, but there are many typos and mistakes in the documentation. Once you get a bit further on, it&#x27;ll be worth sending it to someone to do an edit pass to clean it up a little :) - Some of the AWS terms are incorrectly written in documentation. For example &#x27;SecureSecret&#x27; instead of &#x27;SecureString&#x27;. - On the subject of secrets, would a better option not be to store a Secret using AWS Secrets Manager with the value you need to acquire? Also, I know you mention that the secret value is used and never stored, but how do we know that? If you have access to the secret via ARN and IAM policy, then in theory if your SaaS was compromised, the secret is still retrievable from the customer&#x27;s account. How about using something like Vault to store secrets?

If I have a company, and we use your service to generate our AWS infrastructure. If there is a bug in your service that causes a misconfigured <i>something</i> that causes downtime to my company, leaking pii&#x2F;customer info, etc. How much liability are you taking on? Can we sue you?

Not really related to this tool, but Terraform: We are hiding a few services behind a vpc and they are therefore not reachable by Terraform Cloud without the Business plan which is required to get an agent we can install within the vpc. I cannot use ip restrictions because HashiCorp doesn&#x27;t expose their ip&#x27;s. I filled out their contact form 7 days ago and they haven&#x27;t returned yet. It&#x27;s likely just a matter of waiting a bit longer, but being this dependent on one organization for our entire infrastructure is starting to get a bit frightening, especially if it&#x27;s going to take months before their sales department get the time to reach out.

Really interesting proposition, it took us more than a month to properly set up AWS

Cool project! I&#x27;m building something similar at <a href="https:&#x2F;&#x2F;apppack.io" rel="nofollow">https:&#x2F;&#x2F;apppack.io</a>. It&#x27;s not terraform based, but also helps setup, manage, and orchestrate AWS resources for devs.<p>Using AWS managed services is a huge win for maintainability. A lot of host-your-own PaaS tools are spinning up EC2 instances that you&#x27;re then responsible for maintaining&#x2F;patching&#x2F;securing.

looks promising!<p>how does it compare to convox[0]? (never used it, but I think it’s similar?)<p>[0] <a href="https:&#x2F;&#x2F;convox.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;convox.com&#x2F;</a>

With respect, if you’re based on Terraform, then you’re not taking advantage of any of the special features of AWS, and you could use any cloud provider.<p>Conversely, if you do take advantage of any special features of AWS, then you can’t use Terraform.<p>So, why should I use your tool on AWS versus any other provider?

Looks great, congratulations on the launch! I see GCP &amp; Azure support listed only under enterprise, does that mean that the Standard plan only applies to AWS right? Nevertheless, good job. Wish you all the best!

This is super cool.<p>Quick question - would you do compliance infrastructure?<p>E.g PCI DSS, iso 27001, HIPAA, etc ?<p>There is also AWS config to check the configuration. But I would pay for a tool that creates it in the first place in an AWS-Config compatible manner.

I looked at this when you went live on PH. I have very little experience in this field and it seems like this is an easy way to take advantage of Terraform for someone like me.

How does it know what terraform to generate? Say I create a new Phoenix project with a postgres database Repo.<p>Does Digger infer all the terraform necessary from a Dockerfile?

Just would like to note that if you use something like this do your own security audits and keep your own repositories or this could be an easy attack vector

I like terraform as a tool but in AWS I would much rather see this using Cloud Formation since that is native to the platform.

Great! I also just read about this on a Serverless newsletter.

Could this be used to host Drupal and WordPress sites?

So you built an abstraction layer for an abstraction layer for an abstraction layer?