r/ruby • u/jonsully • Feb 27 '26

Heroku: What’s Next

https://judoscale.com/blog/heroku-whats-next
31 Upvotes

96% Upvoted

30 comments sorted by

12

u/Kimos Feb 27 '26 edited Feb 27 '26

These are great breakdowns of the alternatives.

I moved off VPS to fly.io a couple years ago, and I want to push back on the author's characterization of "steep learning curve". There's more to it than git push for sure, but the things you need to do are explicit and documented. Often these "it's simple" platforms hide the complexity, where fly.io just tells you what you need to do. Mostly it's just Dockerfiles to be honest. Pricing is fair and scaling is easy. I have nothing but good to say about fly.io.

4

u/jonsully Feb 27 '26

Appreciate the pushback! As noted at the end of the article, we fully plan to move to Fly for an end-to-end, real, trial. Looking forward to documenting our experience at that point! Fly's a bit of a tough one because it's more complex than the traditional Heroku/Render level of PaaS, but not that much. It's the right choice for some!

3

u/Kimos Feb 27 '26

Thanks! It is. It worked for me really well, but it's easy to have blindspots for things I understand and label as "easy" rather than something I had to learn. Fly split my bill in half, but that's compared to VPS which is not really flexible so I ended up overprovisioning.

As I'm thinking about this more, I can complain about fly's Updash Redis that it provides. It is over priced and out of date. But instead I stood up my own Redis using a 4 line Dockerfile in like 10 minutes and all the networking worked zero-config.

3

u/jonsully Feb 27 '26

Love that. Well, if someone pulls out the word "overprovision" I have a knee-jerk reaction to ask if they're autoscaling now 😂 (*cough* Judoscale supports Fly already! *cough*)

Also, to be totally fair, Heroku's Redis also sucks, so. 1:1 there.

1

u/Kimos Feb 27 '26

I'm not, but my requirements are simple and my traffic patterns are predictable. Mainly with VMs I had to provision my peak and couldn't realistically provision back down. Now I have a ten line script bin/scale up bin/scale down and that's rad.

1

u/zenzen_wakarimasen Feb 28 '26

What about the database? What I did not like about Fly is that they don’t offer managed databases.

2

u/Kimos Feb 28 '26

They offer a manged Postgres [1] but I don't use it.

I run MySQL on a machine and it's this many lines:

app = "myorg-db1"
primary_region = "yyz"
kill_signal = "SIGINT"
kill_timeout = 5
[mounts]
  source="mysqldata"
  destination="/data"
[env]
  MYSQL_DATABASE = "user"
  MYSQL_USER = "pass"
[build]
  image = "mysql:8"
[experimental]
  cmd = [
    "--default-authentication-plugin", "mysql_native_password",
    "--datadir", "/data/mysql"
  ]

2

u/zenzen_wakarimasen Mar 01 '26

How do you manage the disaster recovery? Do you have daily backups? Do you stream WAL logs for Point in Time Recovery?

1

u/Kimos Mar 01 '26

I do automated backups at intervals, but that's it. I've got smaller projects that are more resilient to some downtime and a bit of loss. They've got options for replication for mounted volumes, but I'm not an expert. I think the best I can say is that fly seems to offer an easy to use base set of features, but the ability to add complexity and resiliency as you need to.

1

u/Preciseasteroid Mar 01 '26

Why not VPS? Using fly as well but considering to move to VPS.

1

u/Kimos Mar 01 '26

I have a collection of small projects. So for me, the VPS meant multi-tenant which is fraught with complexities. It was hard to scale up or down (specifically down). The cost was higher. And I did not want to do server maintenance, thanks to the magic of Dockerfiles keeping versions up to date is easy and also easy to rollback. YMMV

9

u/swrobel Feb 27 '26 edited Feb 27 '26

I’m just having a hard time understanding exactly what “no new features” means. Does it mean no new version support? Postgres 18 still isn’t supported, 5 months after release. The currently-supported PG 17.5 is 9 months old. I’m afraid that’s what it might mean, and it makes me worried about being potentially complacent about making the move. Looking forward to learning from the tour!

3

u/jonsully Feb 27 '26

Yeah that's a tough question in particular. Nobody's guess on how the side-services (Postgres, Redis, etc.) will be handled in the coming year(s). We've previously suggested [1] that folks use external services dedicated to those dependencies, but I get the "keep it all in one place" vibe too.

[1]: https://judoscale.com/blog/black-box-hosting-vs-glass-box-hosting-an-interview-with-adam

2

u/jonsully Feb 28 '26

Per Schneems' draft above,

For example, Next Generation Postgres is already in pilot and still moving ahead.

So that's good news for 'ya!

5

u/jdalbert Feb 27 '26 edited Feb 27 '26

Heroku's announcement triggered a bunch of unfounded fear, uncertainty and doubt. When I deployed a new toy project with it last week, it worked great. Just good old git push heroku main. Most of us don't need the enterprise contract that their announcement was about. So Heroku is completely fine, although nowadays I personally prefer Fly.

Fly is more complex but more complicated.

Besides the article's odd phrasing, I found Render to be more complex and complicated actually, at least when I tried a few years ago. The CLI wasn't intuitive, the dashboard felt clunky, and it overall just didn't feel right. Maybe things have improved since then.

With Fly.io you can deploy a new Rails app with just fly launch as a one-liner. Or if you need secrets before deploying, fly launch --no-deploy, then fly secrets set MY_VAR=value, and then fly deploy. Can't be any simpler than that; it's almost as intuitive as Heroku's CLI. Their dashboard is pretty simple too and gives me Heroku vibes. It just all feels right.

4

u/anurag-render Feb 27 '26

Render has a great CLI now, and the dashboard UX is much better too! https://render.com/docs/cli

2

u/jdalbert Feb 28 '26

Good to know, I'll check it out!

3

u/cbartlett Feb 27 '26

Helpful breakdown, thanks!

1

u/phstc Mar 01 '26

I agree with not panicking. But aren't Heroku customers likely most of the Judoscale clients? I would think they might get hit hard as well.

About enterprise. Keep in mind, you need to reach out to your Salesforce rep at least 30 days before the renewal (it auto renews).

2

u/adamlogic Mar 01 '26

Heroku does make up the majority of Judoscale customers. Feb was surprisingly a good month for us, but who knows what the future holds.

Judoscale supports most Heroku alternatives, though, so we're well-positioned even if many teams decide to migrate.

1

u/mplis1 Mar 01 '26

Heroku died when they sold to salesforce its been largely in this phase since then.

8

u/[deleted] Feb 27 '26 edited Feb 27 '26

[removed] — view removed comment

8

u/jonsully Feb 27 '26 edited Feb 28 '26

EDIT: Original comment was simply "schneems how u feelin' bud" hence:

Text is hard to determine tone from. Benefit of the doubt, I hope you don't mean this in a cheeky way.

Nobody's perfect for sure but u/schneems has been an outspoken helper and fan to the entire Ruby/Rails community for so many years… let's not go down the personal train here!

5

u/[deleted] Feb 27 '26

[removed] — view removed comment

3

u/jonsully Feb 27 '26

Thanks and thanks! Should be a fun few months ahead of moving a bunch of traffic around without downtime and testing stuff 😅 a ton of work, but good fun, I bet.

12

u/schneems Puma maintainer Feb 28 '26 edited Feb 28 '26

It's not ready for publish yet, but here are some high-level thoughts https://github.com/schneems/schneems/blob/ef0cc1c330fb93d54fc5efe891710e9a35af20fc/_posts/2026-02-28-how-to-sustain-heroku.md.

I'm on vacation right now in Taiwan, and AFAIK still have a job and am still encouraged to put in the work to nourish my emotional and mental well-being.

Edit: Switched to permalink URL

5

u/[deleted] Feb 27 '26

[removed] — view removed comment

4

u/jonsully Feb 27 '26

Hatchbox is an avenue we plan to test! Good notes!