Show HN: Stacktape – Full power of AWS with Heroku-like experience (stacktape.com)
As a full-stack developer, I was looking for an easy way to deploy and host my applications for years.
I could go with Kubernetes and Terraform. But the complexity of running this in production can be overwhelming even for a team of dedicated DevOps specialists. Or I could go with Heroku. But I’m not willing to pay 5-10 times more for my infrastructure just because my app was easier to deploy. I could also choose Serverless framework. But If my use case requires more than Lambda functions, I need to read through 100s of pages of AWS documentation figuring out how to configure VPCs, Security groups, Route tables and more…
Until now, I could choose either "powerful" or "easy". Today, after 2.5 years of development, I’m happy to introduce another option.
Stacktape is a DevOps-free cloud framework that’s both powerful and easy at the same time. It allows you to develop, deploy and run applications on AWS. With 98% less configuration and without the need for DevOps or Cloud expertise.
Unlike with other solutions, you can deploy both serverless (AWS lambda-based) and more traditional (container-based) applications. Stacktape also supports 20+ infrastructure components, including SQL databases, Load balancers, MongoDB Atlas clusters, Batch-jobs, Kafka topics, Redis clusters & more.
Besides infrastructure management, Stacktape handles source code packaging, deployments, local/remote development, and much more. It also comes with a VScode extension and local development studio (GUI).
Stacktape is a IaaC tool. The configuration can be written in YAML, JSON, or Typescript. A typical production-grade REST API is ~30 lines of config (compared to ~600-800 lines of CloudFormation/Terraform). The deployment can be done using a CLI or a programmatic SDK.
Stacktape is a premium tool with a forever-free tier. I’ll be very happy if you give it a try and let me know what you think.
84 comments
[ 3.7 ms ] story [ 142 ms ] threadYAML validation and vscode extension is very cool. I hope it helps adoption.
That company spun off its technology into Docker and then shut down dotCloud, which I have always been sad about.
Thanks for building this!
One thing that we use a lot is Doppler for environment variable management, so some kind of official support for that would be hugely helpful.
We are able to sync from Doppler to AWS Secrets Manager, so maybe just Secrets Manager support would do it for us.
You can easily inject them to a container environment variable (at deploy time). You can also fetch these secrets at runtime (using aws sdk).
Do you need anything else? I'll be happy to explore your use-case and see what we can do.
Automatically generate the first yaml/config file from looking at my codebase? Heroku-like CLI that generates/updates the YAML file? Heroku gives me "redis" without me needing to learn anything about AWS/YAML-config shit.
One-Click starter file for 10-most popular apps...
- rails/postgres/redis
- create-react-app
- static site generator
- node/serverless
I will think about it. I do agree that we could do more here. I understand that you don't like writing YAML, but to be honest, it's not that complicated, especially if you use our VS code extension (it autocompletes and suggest all the properties, validates the config file, and give you on-hover documentation). Also, it's just few lines in most cases.
> One-Click starter file for 10-most popular apps...
We do have starters for Hello, we do have starters for: - (Typescript) Express.js API with Postgres - (Typescript) Lambda API with DynamoDb - (Typescript) Lambda API with MongoDb - (Typescript) Lambda API with MySQL - (Python) Flask API with Postgres - (Java) Spring Boot API with Postgres - (Ruby) Rails API with Postgres - Vite.js website (React/Vue/...) - this is a (better) CRA alternative - Gatsby.js website - Next.js website
We'll add more in the future. Redis will be the next on the list.
First thing we want to do is an interactive CLI "tour" that auto-detects the project type, asks a few basic questions, and generates the YAML for you. Should be released in ~1-2 weeks.
Second thing we are thinking about is a visual GUI. Will be harder, but doable. We can integrate it into the local development studio.
For example, the "HTTP API Gateway" resources has 0 required properties you need to configure.
We have sensible defaults for everything. We also try to automatically infer as many things as possible.
This and the fear of making a mistake with the most important configuration file of the application.
OP this is a clear opporutinty for Stacktape.
"Stripe is one of the most successful startups we've funded, and the problem they solved was an urgent one. If anyone could have sat back and waited for users, it was Stripe. But in fact they're famous within YC for aggressive early user acquisition.
..."At YC we use the term "Collison installation" for the technique they invented. More diffident founders ask "Will you try our beta?" and if the answer is yes, they say "Great, we'll send you a link." But the Collison brothers weren't going to wait. When anyone agreed to try Stripe they'd say "Right then, give me your laptop" and set them up on the spot."
Might be worth focussing on onboarding.
I think you've missed the point entirely. Just because _you_ do not find it complicated, doesnt mean others wont. This comes across dismissive, people dont want to use your flavor of YAML and have to install a VSCode extension to do so effectively. This alienates a bunch of people that dont use VSCode, and who would rather utilize a safely typed library that provides autocomplete out of the box regardless of which editor is being used. IaaC/S should move on from thousand long lined YAML files that shoe-horn in extensibility and composition in favor of using tools (programming languages) that support this out of the box. These libraries could output YAML files for the sake of compatibility.
We do support Aurora postgres databases natively: https://docs.stacktape.com/resources/relational-databases/#a...
You can trigger lambda functions by a "cron" job (https://docs.stacktape.com/resources/lambda-functions/#sched...)
The only problem is that you need to package your lambda function yourself, as we currently don't natively support 0-config builds for Golang. (we can help you zip it, upload it to a deployment bucket, and effectively cache it tho).
I always think I should really look into automating deployment of Rails apps into a VPS. All these services seem to make really good money and I bet very few stacks beat the absolute hell that is to deploy Rails.
Also, we're just now now working on an interactive CLI guide that auto-detects the project type, asks you a few questions, and generates the YAML for you.
Personally, I don't mind writing YAML at all, but we've heard a lot of people do. We'll do our best to make it easier.
Are you using a custom IaaC management tool for the deployments, or is it compiling down to something like Aws Cloudformation or Terraform Providers?
We also use CF infrastructure modules, CF custom resources and aws-sdk for certain features and integration.
We're also trying to smooth out some of the rough edges of Cloudformation (for example translating some of the crypting CF errors into a more developer-friendly errors).
Also, since CF can be pretty slow in some cases, we have a "fast deploy" mode that avoids CF and deploys (lambda functions and containers) way faster.
Asking because I see this as the #1 obstacle to getting buy-in in certain corporate environments. If we need a bit more flexibility, what does that look like?
Stacktape is built on top of AWS CloudFormation (it also uses CF infrastructure modules, CF custom resources and aws sdk).
To modify the generated Cloudformation, you can use overrides: https://docs.stacktape.com/configuration/overrides/
You can also add any CF resources to the template: https://docs.stacktape.com/resources/cloudformation-resource...
I didn't have a chance to read it myself tho.
But even past that, what does this give me beyond AWS CodePipelines? All comparisons on the site seem to be against "raw" AWS ("weeks to months" from code to deployment, really?).
But, hey, maybe I'm misunderstanding both this product and CodePipelines. Myself, I'm on Azure DevOps (which I guess is the same as "MS Azure" as opposed to "Google Azure"?), and there I can deploy my aspnetcore app to production in, like, 30s. Today.
So, what can I look forward to in 2023 with this product?
The incident happened right after we posted this 3 days ago. Not a great timing, I have to agree :)
> Myself, I'm on Azure DevOps, I can deploy my aspnetcore app to production in, like, 30s.
I'm not very familiar with MS Azure and the way you can deploy your apps there.
The goal of Stacktape is to allow you to deploy your apps in a production-grade fashion (the infrastructure is scalable, reliable, cost-effective, secure and the deployment process is repeatable, auditable, etc..). Not sure if your Azure setup does the same. But again, I can be wrong as I'm not familiar with it.
It's not the most requested feature, but I do agree that is solves a huge paint point.
Also, maybe some of you big data use-cases could be handled by a custom batch job? https://docs.stacktape.com/resources/batch-jobs/
[1]https://github.com/debarshibasak/awesome-paas
Stacktape is not exactly a "PaaS in your cloud".
Similarly to serverless framework, it works on the developer's machine (or on a CI/CD server). You don't have to "install it to your account".
Compared to those "PaaS in your cloud" tools, you don't lose control, flexibility or security. You have the the full power and control of AWS (and other 3rd party providers Stacktape supports).
Stacktape is also very transparent about what it does. You can extend it (using AWS CloudFormation) or modify the generated template.
It was immediately obvious to me it was a wrapper over AWS which abstracts the infra to a little higher level, simplifying the initial setup and maintenance.
Give me an opinionated default that works well for most situations that I can then build on top of, configure further, etc..
In ~2 weeks, we'll release a version with an interactive CLI "tour" that can generate the "sane-defaults" configuration for your application.
Or you can start by copying the configuration from one of our quickstart tutorials.
I’ve deployed a couple of things there and never used the YAML files, just the UI.
You have 2 choices:
- Use a "0-config" solution. You sacrifice control, efficiency and a lot more.
- You write configuration. In my opinion, the best language for configuration that humanity has come up with is YAML. Yes, it's not ideal, but it's expressive and (compared to alternatives), very readable. Compared to real programming languages, it lacks some of the goodies like autocompletion, validation, etc. Stacktape has a VScode extension for that. Also, you can write your config using Typescript: https://docs.stacktape.com/user-guides/writing-config-in-typ...
If you want a "quick-start" solution, we have a lot of those in our docs. Also, we are working on an interactive CLI "tour" that will "bootstrap" the configuration for you (with some sane defaults).
Edit: We are actively looking for a better and easier solution. If you have a suggestion, I will be very happy to discuss it.
1. It’s not YAML (which I agree is dreadful after about 10 LOC)
2. You’re not fighting it. Want to condition the config on something? Just code that up, no need to introduce custom options etc.
3. A basic setup is barely more work than filling up a YAML file, it might even look like basically key=value kind of file.
4. Easier to structure. A big config file in YAML can only ever be a single large file. In Python/code, if you grow a big and complex config, you split it like you would with any regular code.
It is of course less safe to parse a config file than it is to read a YAML one (I guess?) but if you’re then running user code anyway then it probably is no additional security risk.
Clearly, can replace Python with any other language.
An example of a cdk that isn’t tied to a cloud would be https://cdk8s.io/docs/latest/getting-started
CDK is literally writing Python code. You can organize your files and write out logic in all the ways you could possibly. CDK offers tremendous value in this regard but the downside being you won't be able to generate the same layout on Azure or Google but that's a given.
On one end of the spectrum you could have a hybrid of Azure/Google cloud products but with AWS as your main base, vice versa. However, usually in my personal experience, you rarely end up deploying a complete stack on both clouds. It's like take that product from Google or Azure and make it work with AWS, in such scenario you could simply do most of the stuff in CDK and then wire up separate products (but to each their own).
The only use case where I think might require Terraform to a large degree is if you make heavy use of VPC'd, full stack across multiple clouds (ex. agency or consulting firm) but for majority of cases I don't really leave AWS and neither is there an expectation to from clients and employers (they rather just stick to AWS for everything if possible)
tldr: Terraform and tools like what OP is offering, were used to scaffold infra on AWS but CDK came along and really made it unecessary—just learn Python or a backend developer to scaffold infra on AWS in Python.
- In my opinion, it's even easier to use than a CDK L3 construct.
- It supports local/remote development, source-code packaging, deployment artifact management, secret management, domain management and much more.
- Besides AWS resources, it supports other 3rd party services (like MongoDB Atlas clusters and Upstash Kafka/Redis).
- It has a local development studio - GUI (currently in private beta).
https://www.terraform.io/cdktf
Look, your landing page example is cute, but it's not fully production ready. And by the time you finish adding everything to make it fully production ready, you'll be back up to the 600 lines of configuration that you're currently demonizing.
Look, this shit is hard. I get it. I recently got mindfucked by the intricacies of single table design in DynamoDB, and the sheer complexity of doing that correctly, for the sole benefit of hiring fewer $200k/year engineers, plus the headache of trying to hire the right ones, plus their post-hire management overhead. And that's barely DevOps adjacent!
I'm not convinced that you can truly remove the complexity. The more features you throw on your PaaS, the more configuration options you expose. Eventually, the configuration for your PaaS gets complicated enough that you hire an engineer who knows the PaaS very well and they become your DevOps engineer. Then you realize that you didn't actually solve your problem, you just made it harder, because the PaaS never exposes everything you actually need, so either you need to wait for the PaaS to implement it, or you start to migrate off it.
Stacktape does support 90% of these already.
> but it's not fully production ready
Yes, I agree it's not production ready for every use-case out there. But I truly believe it is for a majority of them.
I also believe that it's more production-ready than an average application that goes into production.
> Then you realize that you didn't actually solve your problem, you just made it harder, because the PaaS never exposes everything you actually need.
Stacktape is not exactly a "PaaS". Stacktape is a cloud development framework. It was designed to be flexible and extensible. Everything is "exposed" by default. It works on top of AWS Cloudformation. You can extend the CF template using native AWS Cloudformation, or override anything that Stacktape generates.
So basically, Stacktape gets you to production very fast, but isn't an obstacle when you need to scale and go "lower level".
I get what you're saying, but please look a little closer at your messaging and your value proposition.
Your value proposition is "with Stacktape, you don't need to hire a DevOps engineer, we charge you not even 10% the cost of a DevOps engineer, therefore by buying Stacktape you will save money." But, apparently, eventually your customer might/will grow out of what Stacktape can offer, in which case your customer will hire a DevOps engineer anyway, and well at least they can take comfort that there won't be any vendor lock-in.
Which begs the question - how is a customer supposed to know when that point in time could or would be? You're not promising that they'll never need a DevOps engineer, because you'll help them migrate, and you're not promising the benefits of a PaaS, including full responsibility for the resources you create, because ultimately they just belong to the customer on their account and it's all their responsibility.
I don't think telling people "we help you spin up lots of stuff that you don't understand but you'll be responsible for it anyway if something goes wrong" is a compelling message. People who look at your pricing page, they're not going to compare your price to the price of a PaaS or a DevOps engineer, because you're not providing the value of a PaaS or a DevOps engineer, i.e. someone with the experience to take responsibility and fix things when and if they go wrong. Instead, they will compare it to the actual value they are getting, which is "is it worth it to me to pay $45/month to read these docs and maintain this shorter YAML, than it is to read these other docs and maintain this admittedly longer YAML?" Maybe there is a market like that, and if so, then I wish you the best of luck (I'm a DevOps engineer so I already understand that longer YAML so your solution doesn't give me value).
After working in this space for a couple years, I realized that unfortunately the market just doesn't exist. Small enough teams will typically hack their way through building an MVP and early versions. They don't need/want the complexity of kubernetes/terraform, most literally run their MVP on a couple of instances. On the other side, once you get big enough, you hire dedicated people to start solving these problems. The middle market in between the two is very small and you most likely will be beat by the services already built into AWS such as Amplify.
[1] https://github.com/debarshibasak/awesome-paas
I'm just now starting to realize the mistake I've made when coming up with the "Heroku-like experience" headline.
I meant it's similarly easy, not that it's PaaS.
Stacktape is a cloud development framework. It runs on the developer's machine (or on a CI/CD server). It's similar to Serverless framework, except it supports way more resources (containers, SQL databases, MongoDb Atlas clusters, Redis, Kafka, etc). And it also has some additional useful features on top.
> once you get big enough, you hire dedicated people
Stacktape is for these teams. Thanks to Stacktape, they can delay the hire by a year or 2. And they also need to hire fewer of them.
Good luck, product looks awesome!
As an aside, I do like how Terraform manages things, but have never enjoyed their configuration language. CDK for Terraform is something I'm watching closely.
My main complaint as an application developer these last few years is the amount of time I’ve had to spend wrangling infrastructure.
You realize Heroku has always run on AWS. Heroku is the “Heroku for AWS”.
Should’ve said “Heroku-like” instead of “Heroku for AWS”.
https://cloud.google.com/run
How does this compare with Convox?
I'd be interested in seeing Stacktape vs. Qovery, which seems a bit more closely related.