igorzij

Thank you!! And fair point. To us it's in a sense a bet on a particular direction the industry is going to take. If we're right then infrastructure-as-code isn't going away, someone needs to write it, even for the managed services. Those still need to be connected with each other, there are VPCs, security groups, secrets - the "glue" connecting those services. We don't believe developers should care about that though. Specialisation tends to increase, not decrease with time. It's hard enough to make one's frontend or backend work in isolation. So our thinking is that the devops corner of the industry is very much a transitory state - post-problem but pre-product, somewhat like hardware was before the PC, or software development before operating systems. There are strong incentives to cleanly decouple devops from development by means of products - just like operating system engineering is decoupled from software engineering via layers upon layers of apis and tools that don't require any specialist intervention.

So we are trying to make progress in that direction - if managed cloud services were hardware, then we are building an operating system for developers to use that hardware with as little friction as possible.

Thanks so much for sharing the feedback!! This is super helpful, and we will work to address this.

That's a very good point. And it is also the very reason we wanted to build smth like this. The question we asked ourselves: why are people leaving PaaS platforms like Heroku?

The answer seems to be that people are starting with simple tools (beanstalk, heroku, GAE etc) but then quickly approaching their limits in terms of both features and cost - and move to "native" AWS / GCP / Azure. At this point they need to rebuild the infra from scratch, write all the IaC, etc. This is painful, slow and expensive. So it's either simplicity or extensibility, pick one.

We thought that someone must find a better way, it could just as well be us. The idea is to generate IaC in the background on top of a "real" cloud provider like AWS, making it seem to the user just as if they were using a PaaS. Until they want more - and at this point instead of moving to a different platform they can just extend TF however they like. No big one-off DevOps effort needed. Chances are that it can be done by the same person who built the backend, even if they never worked with AWS or Terraform before. Much smoother learning curve.

Also, many tech scaleups end up building "in-house herokus", often backed by Terraform. This was one of the motivations of us as founders, they had to do this more than once.

thanks!!

that was the intention actually but then we thought many people would use it on mobile and settled on clicks. would you prefer dnd interaction?

Hey HN crowd, founder here. The fact that we hit the frontpage somehow broke the new app signup flow. While we are fixing it, we are temporarily redirecting to app.digger.dev (the old UI). Will keep you posted here!

Same team behind it. But it's a completely new UI, much simplified and streamlined. From previous launches we learned that the UI was quite confusing, and rebuilt it from scratch. The old one can be found at app.digger.dev; this is dashboard.digger.dev

thanks!!! that's what we thought as well :) OpsFlow automatically generates IAM roles, security groups and stuff like that. And Terraform - which you can fully customize

Almost 2 years ago my cofounder and I started building Digger. It took us a year, and last summer we have finally shown it to the world. We launched Digger quite successfully on ProductHunt as well as here on HackerNews. But it wasn’t instant product-market fit we hoped for. More like, different people were using Digger for different reasons.

Then we launched a few follow-up products with more focused value propositions like UI (Lemon), or multi-cloud (Alicorn), or databases (Hippobase). We learned a lot from the early adopters (thank you!!). The biggest learning was that we were trying to solve too many problems at once, and that confused our users a great deal.

So we went back to the drawing board. We have radically simplified the UI, especially onboarding. We asked ourselves - what is the one thing our users care about most? And we started launching what we thought were features as separate products. Some of them flopped (remember Serverful?) - and so we killed the feature. Others succeeded, like one-click sample app setup (AWS Bootstrap) and most recently Terragen that automatically generates infrastructure-as-code.

And then we wondered: is there something in common with the products that were received warmly? Turns out, there is - speed. In hindsight it is obvious that speed matters a great deal. Because it is not uncommon to spend more time on setting up AWS infrastructure for your app than building the app itself.

Then we thought, what would the fastest developer experience with AWS infrastructure look like? Making each step as fast as possible seemed like a good start:

- the fastest way to get the code

- the fastest way to determine what infrastructure is needed

- the fastest way to provision that infrastructure on AWS

#1 can be solved by one-click Github repository connection, like in Vercel. It doesn’t get much faster than that

#3 can be solved by generating and running Terraform (this is what Terragen does)

#2 presents the biggest challenge. How do we know what kind of infrastructure is needed?

After a great deal of not making much progress we realised something: all the information is already in the code! Because if you show your app to a DevOps engineer they wouldn’t need to ask many questions, they would just see the code and instantly know whether it’s a front-end (then it would require an S3 bucket and a CDN) or a back-end or a lambda function. We can easily detect the language and the framework, Dockerfile, lambda handler, read package.json, things like that. Then we can feed it into the Terraform generator, then run terraform apply on our servers against user’s AWS account. This makes the entire flow completely seamless: connect your github repo → connect your AWS account → click “Deploy”. As simple as that.

And this is Flywheel. Give it a try!

oops - thanks! will fix.

I see your point clearly, and it's a good one. However, consider the following counterargument: the exact same thing could be said (and was said) extensively about low-level programming concepts such as registers, later pointers, memory allocation, etc. It was essential for every software engineer to master... until it wasn't. Same with lower-level OS fundamentals. Same thing earlier with pre-PC hardware.

We've come full circle with the present-day cloud providers like AWS. 15 years ago they started as simplification, but today they are boxes of 200+ specialised building blocks that are anything but trivial to put together. A human specialist has to be involved. But why? This complexity is completely artificial, its sole purpose is to keep their customers locked in. This must and will be solved with better tooling. That's what we are trying to make.

such a great point, we'll do that!

that's a great point indeed - we have Terragrunt support on the roadmap but didn't manage to ship yet. What kind of stuff if you don't mind sharing?

Oh wow it didn't occur to us to check facepalm

Haven't thought of that actually... Thanks!!

Fair point indeed. They way we built it is that it actually generates and applies Terraform in your AWS account and synchronises it with your Github. The idea is to eliminate all devops-y steps from the flow so that the user who knows nothing about AWS or Terraform can use it.

Both - it first generates Terraform and run it on our servers to configure your AWS account (a bit like CI but for infra). And you can connect a dedicated GitHub repo for infrastructure that will get Terraform synced into. So after you make changes to your stack (for example, add a service or a database, or update an env variable) Terraform will get updated and pushed to that repository.

The latter, yes. The former is a feature on the roadmap. Our idea is to make it as easy as possible for the user to take advantage of IaC without having to learn it. Remove the entry barrier, give a nice UI that would make it super easy to do the basic stuff, which is like 90% of what's needed on a day-to-day basis. For the remaining 10% the user has full control over underlying Terraform. So you can customise only the parts that need to be custom; that's much easier than starting from scratch.

This is an amazing project you have there! We have a very similar philosophy - but taking it one step further. We believe that developers do not and should not care about things like VPCs, security groups, etc. We believe that the current state of infrastructure-as-code is akin to that of assembly language. Low-level and not truly reusable - because using Terraform modules still requires understanding of low-level concepts. What we are trying to build is essentially a compiler of "human" concepts into Terraform. But because even simply running Terraform is a daunting task to un-initiated developers, we also need to make this part easy. Hence we run it on our servers. This way the user is completely shielded from complexity without losing the ability to go low-level and customise whatever they like.

A database or a queue or things like Redis. S3 buckets we don't count, as well as any other stuff that you add to Terraform yourself. So you can have as many S3 buckets as you want.

We haven't yet put much attention into pricing. As a matter of fact the paywall is broken atm (don't tell anyone about it!) so technically nothing stops you from having more than one service or resource or whatever :)

Because it actually runs the Terraform on Terragen servers to solve the state conflict problem. You can think of it like "CI for infrastructure". Or a "compiler+runtime" that outputs Terraform instead of binary / bytecode. Higher-level concepts like dependencies between services are translated into Terraform and applied. So there is robust state management + extensibility, all of it with an easy to use UI.

That's quite cool!

Yes GCP and Azure support is on the roadmap. But we're a 6-person startup so trying to narrow down, for now it AWS only

Thanks so much for your kind words! This means a lot to us.

Almost exactly a year ago we have launched Digger. Since then thousands of developers started using it, and our mission remains to build the best developer platform ever.

But we are often asked - why so many products that look so similar? After Digger we have also launched Lemon, Alicorn and most recently AWS Bootstrap to name a few. The answer is simple: we want every feature of Digger to be best-in-class. So we are making a product out of it and launch it and perfect it if people need it, or kill the feature if there is not enough demand.

Terraform generation is one of the most powerful features of the platform. Not only your AWS account is taken care of - you also get the underlying code that is fully customisable. So you are not limited by the UI and can literally build whatever you want as long as AWS supports it. It's easy with Terragen:

1. Connect your AWS account

2. Connect a GitHub repository for your infrastructure code

3. Terragen will push generated Terraform there

4. Then you can add more apps and services - and Terraform will get automatically updated!

5. And you can use the digger_overrides folder to add your own custom terraform

We believe that the only way to make a truly great platform is to listen to the users and ship things they need. Tell us what you think!

PS - we have also launched on ProductHunt today: https://www.producthunt.com/posts/terraform-generator-by-dig...

Hi all, I'm one of the founders. Our initial product was Digger.dev - a platform that makes AWS easy by automatically generating and infra-as-code (Terraform) and managing your AWS account through it.

Then we noticed that our most excited users are moving from Heroku; after speaking with them we realised that it's a hard decision, almost a leap of faith - because moving is always hard.

So we've built a user experience tailored for Heroku migration - pick your backend, pick your frontend, database yes / no; then connect your AWS account and your infrastructure will get configured automatically. Then you can add your connect Github repositories to move your app seamlessly.

Tell us what you think!

Hey HN, I'm one of the founders of AWS Bootstrap. We have been obsessed with solving AWS complexity for quite a while. We feel that there is something fundamentally wrong with the current state of things in developer platforms.

On the one hand, there are nice simple tools like Heroku or Vercel. But you quickly outgrow them. On the other hand, there's AWS / Azure / GCP. Super powerful, you can build whatever you want; and free for startups thanks to generous free credits. But they are so complex (AWS particularly so) that it quickly becomes a time sink.

So we wanted to create a zero-ops experience on top of AWS. With AWS Bootstrap you can get the best of both worlds - quick setup + full power of AWS still accessible. Under the hood it uses Terraform that is fully customisable.

Hi HN, Igor here, one of Digger.dev founders. We are an early-stage startup ourselves and keen to help other founders with AWS complexity. We are building a tool that automatically configures your AWS account for your code. Running these office hours help us learn more about the stacks people are building on AWS, and knowing that helps us make our product better. So win-win

And here's our PH launch: https://www.producthunt.com/posts/cookies-by-digger

Hello HN,

80% of infra projects use the same terraform to deploy. Cookies is an open source generator for terraform. It supports containers, webapps and functions. You can check it out on https://cookies.digger.dev