AWS is powerful, but hard to configure. With AWS Bootstrap you can set up a full-stack application on AWS in minutes. Just pick your favourite frameworks, connect your AWS account, and deploy!
Hey makers, one of the founders here. We noticed that lots of startups struggle with AWS complexity: it's powerful, it can even be free (with credits), but it's a time sink. Why cannot we do better? And so AWS Bootstrap was born.
With AWS Bootstrap you can set up a full-stack application in your AWS account just as easily as you would do it on Heroku. Zero devops burden.
✅ Frontend: React, Vue, Angular, Next.js, Nuxt.js, Svelte
✅ Backend: Nodejs / Express, Flask, Django, Rails
✅ Databases: Postgres, Mysql, Mongodb, Dynamodb
✅ Git push to deploy (CI / CD out of the box)
✅ Monitoring & alerting
Hope you like it! We'd love to get your feedback
This seems pretty slick - however having end users plugin their AWS Access & Secret keys is not optimal. After authenticating with Github, would love to see you all help end user deploy a cloudformation template on user's side to create a cross account role, generate an external ID and you use this to securely connect with descoped perms.
IE: https://aws.amazon.com/blogs/apn...
@som00re Thank you for the feedback! An amazing feature request indeed! Definitely going on the top of our roadmap to offer this as a connection option .. keyless is the future ;)
Report
@igorzij my man why do you keep launching the same products?
Is this the worst-conceived A/B test of all-time or is it a ruse to steal my AWS keys?
Am I missing something?
awsbootstrap.io turns into digger.dev upon login. same goes for hippo base, lemon etc. its bizarre. makes sense to do this once if you're trying to rebrand, but at this point it smells like a scam
Why would I give AWS Keys to an org that is popping up a new shell company every month?
@sawyer great points - not a shell company though. The approach is called "acquisition products". It is progressively better versions of the same product tailored for one specific use case.
We are building a developer platform that we believe is far superior to Heroku and the likes because it manages your AWS account through Terraform. But it turns out you can't make a fully featured "universal" platform to rival mature PaaS as a seed-stage startup of 6 people (which we are). It's just impossible, too big a product. So we need a narrow use case.
How do we know what people care about most? One way is to launch narrowly focused acquisition products and learn from user feedback. Specific example with this one: we have realised that the key-based AWS account connection is suboptimal, huge dropoff. People don't like that. So the next product we launch is going to fix this. But we were only able to learn this after we moved repo connection to later stages, which was the previous roadblock.
Report
@igorzij Thanks for the thoughtful response! I learned something new.
Report
@igorzij how does the ensemble of products you've launched compare to coolify.io? (aside from the open-source aspect)
@sawyer coolify is nice - however the big problem with this type of "Heroku in your AWS account" approach is that it's a black box. Other similar products include Porter, Cloud66, Atomized, Zeet, Runx, FlightControl, Encore, Tinystacks and a couple others. With a black box platform in your AWS account you are still limited by what the platform provides. Anything outside their features - and you are on your own dealing with AWS. That tends to inevitably happen quite soon, and so teams end up doing DevOps on AWS anyways, eventually moving over completely.
Digger on the other hand assembles your stack out of AWS building blocks in the exact same way a DevOps engineer would. It generates Terraform, which you can customise if needed. So there is no need to have a DevOps engineer in a small team, and a large team needs way less of them.
Digger.dev
Digger.dev
Digger.dev
Digger.dev
Digger.dev
Digger.dev
Survey Loop
Digger.dev
AWSify by Digger
Digger.dev