[Varqu]

As a CTO of a company which has a very similar situation - I can fully agree on that.

We already started looking into a possible migration to another cloud provider. The biggest decision point would be a similar developer experience as with git push heroku master.

[pawelkomarnicki]

I have some experience with AWS ElasticBeanstalk that I used to migrate to my Heroku apps at some point.

With their Amazon Linux 2 they use the Procfile and it feels VERY close to Heroku with deployments (it has its own quirks though, like they have those managed upgrades that are sometimes breaking the app for some reason, etc.) but I am pretty happy with how easy it is compared to the previous AWS EB platform.

The problem is only the cost, i.e., when you have to pay for everything it is a bit more pricey (and settings are pain, those VPCs and security groups and whatnot, not fun)

[matus_congrady]

Would you mind elaborating on what does the "similar developer experience as with git push heroku master" mean for you?

I'm a founder at https://stacktape.com, and we're trying to provide full power of AWS with a developer-friendly experience, similar to Heroku or serverless framework.

Even after doing a ton of research, I'm still not 100% sure which of the Heroku's features are the killer features that the competing PaaS platforms must replicate in order to have the "Heroku-like" experience.

[gregsadetsky]

I'm a long time user of Heroku, have built on top of it as a developer, CTO, etc.

My gut feeling from reading your homepage is that you're automating a lot of AWS service deployments on my behalf, but not "obfuscating" it that much from me either.

Your pricing talks about "Resources" which I assume are either AWS services or instances of those services. The free plan says that a REST api needs 40 resources which seems... like a lot? Is 40 good? bad? :-)

Heroku specifically allows you to think of your app == 1 dyno (depending on how much you scale it obviously), not 40 services.

I also note that the $290/month team plan talks about unlimited resources but doesn't specify their size/capacity. Heroku has sort of t-shirt sized tiers for dynos (and addons as well, like Postgres). What size of resources are you deploying on my behalf?

I do see the value of what you're doing, I'm just not getting a "as easy as Heroku" feeling. It seems potentially more powerful, but also raw-er i.e. this is automated AWS (that I might need to care for / understand), not... "git push heroku master" :-)

[matus_congrady]

Thanks a lot for the answer!

We have clarified what the "resources" are.

Every application (stack) deployed by Stacktape consists of multiple underlying AWS services (resources). For example a database instance, IAM role, auto-scaling policy, log group or a VPC subnet.

Stacktape does not limit the size/capacity (e.g. CPU, memory, GPU type or disk size) of the resources. You can use anything supported by AWS.

Also, the "git push heroku master" is similar to "stacktape deploy --stage production --region us-east-1".

The difference is that Stacktape can run on your system or on any CI/CD service and requires a (very simple) configuration.

I do understand that Stacktape might feel like it's not "as easy as Heroku". But what you trade in terms of simplicity, you get back 10 times in terms of control, flexibility and price reduction.

[Varqu]

Sure, what I would expect when deploying a new service / application:

1. Create a new app in the dashboard or command line (in Heroku it's basically a single step: choosing app name and region)

2. git push from my repository (it's a NodeJS app with React frontend)

3. The app builds automatically and gets deployed to prod