I would not say that they lied about the env vars. The stated line is still "env vars in apps were not compromised, but env vars in CI pipelines and review apps were". For some applications there may have been shared data in these vars - in our case (N=1) our CI pipeline and review apps had a dramatically smaller and less critical set of variables.

It still sucks that they are parceling out the information, but the claim that they outright lied is not true.

The lie was:

> We also wanted to address a question regarding impact to environment variables. While we confirmed that the threat actor had access to encrypted Heroku customer secrets stored in config var, the secrets are encrypted at rest and the threat actor did not access the encryption key necessary to decrypt config var secrets.

https://status.heroku.com/incidents/2413

Nowhere in that did it clarify it was speaking of app but not pipeline env vars. They had plenty of time to author that post too. Make sure you rotate those app env vars anyways as this somehow appears to be getting worse by the week.

I would like to move but there are really no good alternatives that are even close to Heroku.

YMMV, but I quite like Render for the sorts of things I'd have used Heroku for ~5 years ago.

Plenty of folks I respect absolutely love fly.io--I have less hands-on experience there, but they've got a fantastic crew, too.

Who are you using for a database provider? Render doesn’t have auto backups and HA Postgres right? Those are table stakes for me.

We've had a number of folks migrate over to Crunchy Bridge [1] from Heroku, the only main feature we're missing at this point is dataclips which is coming. We can also help with pretty much no downtime migration even for larger databases. And the team over here is pretty much same team that built the original Heroku Postgres.

[1] https://www.crunchydata.com/products/crunchy-bridge

Render has automatic Postgres backups, and you can also click a button to create new backup. We're working on HA (ETA late summer/early fall).

One thing that I have really come to like with Heroku is the pipeline. fly.io doesn't have one (I don't think?) and render isn't the same; it rebuilds for different stages and there's no concept of 'promoting' the same slug.

We're planning to release the notion of build promotion on Render late summer/early fall.

Well hopefully once it's gone the competition will be able to get more market share to build quality product. Heroku has been starving the entire ecosystem for years.

I don't have experience with any other PaaS's so I can't recommend one, but what you say is what I commonly hear.

So, just to be clear.

Your solution is: 1. move off to the competition who are offering a subpar service;

2. then wait until they eventually catch up in (how many years? who knows..);

3. then profit?

Heroku is around, because there is no other service that offers the ease and convenience. I looked at Fly.io and Render and they are nowhere close and mature to Heroku at the moment.

For example, here is Fly.io's "Solution" for Redis:

> Setting up Redis requires launching it as a separate app. ..

Or if you want something as commmon as Sidekiq.. have fun messing with configuraiton files: https://fly.io/docs/app-guides/multiple-processes/

Now let's compare this to the Heroku experience:

How to use Redis:

Step 1. Add a Redis addone

Step 2. There is no step 2.

How about Sidekiq?

Step 1. Add a worker

Step 2. Update your Procfile

Step 3. There is no step 3.

Fly.io tells me to "Just Use Bash"..

So while I kind of see where are you coming from, unfortunately all these alternatives fall short. Not to mention that Heroku has hundreds of integrations built-in.

I'm simply telling you Heroku is not a stable platform that you can trust. It's up to you to figure out what to do. I haven't offered any solutions.

Just because it's a slick product to get going doesn't mean that you can trust it to be a reliable and secure host—or be around for the long-term.

I think it's obvious an ecosystem without a Heroku will help the upstarts. I understand that doesn't help you get a new host today. I'm not telling you to just go to another PaaS and expect them to be the next Heroku in a couple of years—chances are they won't be.

This makes no sense. Heroku have had no competition because nobody has built a better product. They’ve not been starving anyone or anything. Given the biggest and most common complaint most lay against Heroku is that it’s too expensive, if anything the lack of innovation for years has created a huge window for a competitor. And yet here we are. Still.

tl;dr: Heroku is taking customers away that if competitors had it: they would be able to receive more capital

It's not unlike Google Search. Google Search has atrophied over the years but because it's still the best in the market, it's used by almost everyone. Competition is hard to build because it has to be better than Google Search in order to bother using it.

Heroku competitors have struggled in part because Heroku is a fully featured platform. It's relatively easy to build a platform that ticks a couple of boxes really well but building something that matches Heroku in feature parity is a daunting task. In order for competition to get there they need customers and funding, and funding is way easier to get the more customers come in through the door.

Once Heroku dies (perhaps already since this incident) we'll start to see real competition in this space because their competition will be getting used. The PaaS space needs that oxygen Heroku is taking up.

Heroku hasn’t been starving the ecosystem. They simply haven’t had real competition on their caliber of (zero-)devops.

Have you explored Aptible? https://www.aptible.com/heroku-alternative/

I agree although I literally just started using heroku again after many years. I haven't seen alternatives that support the idea of multiple buildpacks. Which seems sort of a must have for any non-js backend because a frontend js stack is going to exist no matter what.

All of Render's native environments include Node by default.

I read this when looking at migrating: "We are working on supporting migration of Heroku apps that use multiple buildpacks." -- https://render.com/docs/migrate-from-heroku#fnref-2

I guess I would need to place the extra node steps and python build steps into a single build file and then point the render.yaml at that custom script? I wanted to tell from the docs if it was possible before even starting on a prototype to demo it. Is there an example app that fulfills this. Thanks for your time.

Exactly, you can use any command or script to build your app, and you would select Python as the native Render environment and run your Node build as part of your build script. Here's a quick example: https://render.com/docs/deploy-django#create-a-build-script

We are looking to move to either fly.io or render. Leaning towards render currently but I haven’t spent a ton of time on the effort.

Why not fly.io?

Take a look at platform.sh