[riskycodes]

We pay Heroku thousands of dollars a month for our Staging and Production environments, and one of the reasons we chose them is that we can spin up a toy widget or proof of concept in seconds for free: we probably do a few of those a day, play around with them for a few days or weeks, and then kill them.

Now that these toys aren't free, I would guess likely to move them to AWS or GCP (since they're likely to be cheaper), and at that point we might as well migrate the rest of our stuff as well. It's not just goodwill that Heroku generated from this, it's actual revenue.

[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

[inerte]

I only pay $16 dollars for a web and a Postgres dynos, but I have a free redis connected to my production instance.

My staging environment, which I use very occasionally to double-check major changes, is all free dynos.

I know, I know... but they offered, and I took it. Now if I have to pay for Redis that will be $31 per month - so more expensive, for less functionality, unless I double it to $62.

Just seems meh to go from $16 to $62 and not get anything in return.

[jensneuse]

We'd like to provide exactly this. Git push to deploy, free Serverless backend including SQLite-based storage. Please have a look and sign up for the private beta if you're interested: https://wundergraph.com/cloud-early-access