Heroku: What’s Next

In a move that surprised many of us — and one which I still can’t determine the business sense in making at all — Salesforce officially announced last week that Heroku will be moving into a “sustaining engineering model”. That’s essentially giant-software-corporation-speak for, “we’re putting this into maintenance mode”. The platform that taught a generation of developers to “push to deploy” has reached its investment limit from its owners 😕.

Now, before you jump straight to “abandon ship!!”, there are real questions we should think about when looking ahead. Heroku is still an excellent platform, runs very stably, and, to this day, has the smoothest DX for getting an application into production. For those of us with production apps currently running on Heroku, we need to be pragmatic about what this announcement means for our present, our future, and our time!

Salesforce’s announcement should ultimately drive a calm, collected conversation around both timing and execution. Heroku isn’t a sinking ship, it’s just done shipping new features.

Let’s Be Honest About Urgency

Urgency itself is a function of two inputs: having a thing to do and believing that you must do that thing soon. The sooner you believe you must do it, the more urgent it will feel. So allow me to reiterate the point I made above and mix in some urgency:

Heroku is not dying today, tomorrow, next month, or next year.

It is not urgent that you migrate away from Heroku.

The Salesforce announcement might serve to give you the first component of urgency: we’ll all have a ‘thing to do’ at some point: migrate to another platform. But it certainly does not give the second component (‘do that thing soon’). Heroku isn’t going anywhere. And, if you recall the late two-thousand-teens, this isn’t even the first time that Heroku will spend some years running without major feature improvements! We sincerely believe it’ll be a few years before there’s any real pressing need to migrate off Heroku if you’re already successfully running your production app there.

I don’t want to come off like a Heroku shill here, so let me clarify why I’m pushing back against the hype and panic. It has nothing to do with Heroku’s bottom line or expensive servers. It has to do with your team’s time spent shipping useful features that will grow the value of your app and/or business.

Even in the best of circumstances and setups, migrating platforms takes time. It requires testing, planning, mapping, and careful execution to ensure that you’re not dropping traffic or upsetting customers along the way. It’s work. All of this work has opportunity cost: you won’t be building and shipping the features and enhancements that your customers want. You won’t be improving your application or business. At the end of the day, your customers don’t care how or where you host your app. They just want it to work and provide them value!

Okay fine but give me an actual recommendation here?

Sure. Deep breath. Let the panic subside: most applications currently running on Heroku shouldn’t worry about migrating until next year (2027) at the earliest. If you have an enterprise contract, you should renew it in 2026.

You already chose Heroku, you’re already setup on Heroku, your app is already running fine on Heroku. You should try to capitalize on those gains as long as possible (especially if you have enterprise/discount pricing!). “Heroku isn’t going to get any new major features” doesn’t actually prevent you from realizing the value of your initial investment into “I want managed hosting I don’t have to worry about”. Moving to another PaaS would still satisfy the “I want managed hosting…” but the migration itself is an additional investment and cost that you simply don’t need to make yet. Take a deep breath and go build your app / business! That does reap value today.

😮‍💨

Looking at the Alternatives

Nonetheless, I know many readers are still going to queue up migrations in the coming months. Maybe that’s discomfort, simply having time available to migrate, or a bad taste in the mouth. I get it! Even as I wrote the paragraphs above I felt some of those same tensions. Honoring those thoughts (and knowing that the future will come eventually) it feels worthwhile to talk through some of the migration paths an existing Heroku app has ahead.

We’re going to evaluate each option in three primary lenses:

• Migration effort: how painful it would be to migrate a full production Heroku app to this new setup
• Ongoing operational load: how it feels (subjectively) to use over time — things like CLI, “hop into prod console”, control and tweakability, etc.
• Cost structure: how expensive is this new setup compared to Heroku, and how is it billed differently?

Then we’ll give our general take on each path outside of those three parameters. Today’s challengers:

• Render
• Fly.io
• Railway
• Run-it-Yourself Systems

But today’s look isn’t our one time “here’s the truth” post, it’s just a preview. We’ll give you our opinions here today based on our work integrating with most of these platforms and running various apps on them over the last three years, but we’re planning on going deeper in the coming months: Judoscale is going on tour. More on that below, but we’ll be moving our 3,000+RPS production app to each of these platforms to really feel out what it looks like for a production app that can’t go down!

Render: The Obvious Choice

If you asked me for a simple, single-sentence recommendation for most teams, it’s going to be Render. Many folks have described Render as, essentially, “the natural progression of Heroku” — perhaps what Heroku could’ve become had it never been acquired by Salesforce. I think this is mostly due to Render sharing many of the same philosophies as Heroku (fully managed PaaS, auto build detection, etc.) but just having been built fresh many years after Heroku: the Render devs had the chance to reimagine the Heroku UX from the ground up with plenty of Heroku experience to draw from.

Migration effort. Any migration is going to take effort, but things are pretty smooth here. Heroku to Render is a well-trod path at this point and Render’s own team offers migration assistance for those coming from Heroku. The mental model is broadly the same and you’ll feel at home within a few minutes of logging into the Render dashboard. The only gotcha to keep in mind is around buildpacks and system dependencies. Render does supply some base-level buildpacks that should cover most apps, but if your app requires specific system dependencies beyond their included set, you may need to build out a Dockerfile. Where on Heroku buildpacks themselves can be composable, Render’s approach is simply, “stay on the rails or bring your own Dockerfile” (more here).

Ongoing operational load. Again here, this one’s going to feel just like Heroku. They handle the infrastructure, you just merge to main. Metrics and web dashboard UI are all friendly and available, logs can be pushed wherever you need, manual rollbacks are simple and accessible, there’s a broad CLI for control if you prefer that style, you can take your favorite autoscaler with you… the list goes on. Essentially everything you love about Heroku exists in Render in parallel or enhanced form.

Cost structure. Of all that platforms and paths we’ll look at today, Render’s cost structure and setup matches Heroku’s the most. Like Heroku, their pricing revolves around pre-set, per-month pricing depending on which instance types (e.g. “dyno type”) you need. Unlike Heroku, they’re actually clear about how many vCPU cores you’re paying to hold (🎉). In terms of real cost, our rough estimate is that, depending on the composition of your app and resources you need, you’ll likely save 20-30% off your current Heroku bill for similar resources on Render.

Our general takeaway on Render is that it’s the right choice for the grand majority of currently-on-Heroku apps. It’s a near-seamless transition, the billing operates the same, the operational overhead for engineers learning the new platform is very low, and most apps will be able to get up-and-running within a day.

Fly.io: A Little More Complicated, A Little More Interesting

Still mostly on the high-level-PaaS layer, Fly.io was built to accomplish a different goal. Fly’s whole thing is distributing your app geographically so that your users will always hit an application server close-by, and doing so with “Fly machines” — micro VM’s with much smaller footprints than full-on Docker containers. Fly is also heavily optimized for its powerful CLI and config tooling. Fly is tremendously flexible and configurable, but comes with the cost of complexity: a steep learning curve!

Migration effort. Like Render, Fly has written guides specifically for those migrating from Heroku, including framework specific guides in many cases (Rails, Django, FastAPI, Flask, etc.) to help explain nuances. And these guides are certainly helpful, but there’s no getting around the paradigm shift: Fly is a fundamentally different platform from Heroku and doesn’t operate quite the same. There is going to be a learning lift as you get familiar with its UI tooling and flyctl CLI tool — the latter of which you absolutely will want to become highly familiar with.

Ongoing operational load. Like other PaaS’s, Fly can absolutely be configured to do the simple deploy-on-main thing and includes built in metrics dashboards, logging basics, and standard machine health checks, but you’ll find a lot of utility in flyctl. Restarting instances, changing environment variables, spinning up secondary production instances… all simple flyctl commands once you learn them! If you’re not already a heavy terminal user, dive on in. Fly exposes more primitives and control around lower-level constructs than most PaaS’s (think: direct VM controls, volumes, storage, regions, etc) and most of that is controlled via flyctl. So there’s more flexibility, but again, a steeper learning curve. Oh, also, you can still take your favorite autoscaler with you!

Cost structure. Fly walks a sort of middle-ground between resource tier-based pricing and metered usage, which makes it easy to jump around to difference scale sizes, tweak your RAM levels, and scale vertically as needed. Prices are per second of machine runtime, extra RAM can be added wherever you want (very cool), and Fly offers everyone a (massive) 40% discount when you opt to pre-reserve compute time — no enterprise contract required. If that sounds like a lot of levers to pull and tweak, that’s because it is. Again, Fly’s schtick here is configurability.

My take: if you’re the kind of person that was driving an automatic Honda Civic and already felt for years like you just wanted more of a car-person’s kind of car, then it’s probably true that Heroku’s recent announcement didn’t change anything for you — your Civic is still a Civic. But it’s understandable that Salesforce has, in some way or another, shaken you into realizing your dream. If you’re after that ‘69 Big Block Mustang with a four-barrel carb that you can tune juuuuust right… then Fly might be for you. This metaphor may have gone too far. Fly is complex. There are neat value-adds with that complexity, but it comes at the cost of complexity — there’s more to learn, more to understand, and more to manage.

Railway: Not Exactly Our Way

We’re not out to bash any hosting providers, especially ones that we support autoscaling on, but we also need to be honest: our experience with Railway has been pretty lackluster. All other bells and whistles aside, we had the worst actual system performance on Railway. Not because of dependent services or database latencies or anything like that, we just found our real, pure compute performance to be worse on Railway than any other platform. It was just plain slower.

We can’t tell you why that’s the case, and at the same time, we love that Railway’s schtick is running their own metal in datacenters rather than reselling metal they rent from the big three. That’s awesome! But we suspect that economies of scale are a relevant factor here.

Overall, we would not recommend Railway at this time. We love the mission and the goal, but we had a less-than-great-time. For the sake of being positive-outlook community members, we’ll simply leave it at that!

Oh, and we do still plan on taking another full crack at Railway when we go on tour — see more below.

The More HIY Stuff!

We live in a wonderful time of options! There are so many great options in the Host-it-Yourself world, in many flavors, and at many levels of even hosting-it-yourself. The bring-your-own VPS tooling like Dokku, HatchBox, Coolify, and CapRover offer lightweight PaaS-like experiences with great flexibility, each with their own distinct tradeoffs and workflows. Going even more complex, container orchestrators (e.g. they coordinate the Kubernetes for you) like Northflank, Porter, and Qovery can allow you to “bring your own cloud” (be it your own metal, rented Hetzner boxes, or AWS API keys, etc.) while still handling most of the complexities of Kubernetes cluster orchestration for you. And, of course, the big world of AWS itself — “Hop onto ECS Fargate!” or “Elastic Beanstalk, baby!” among other choices. There’s truly never been so many ways to run the “Heroku experience” yourself!

Honestly, there are a dizzying number of ways to make the technologies at this level of hosting control work. For the sake of this article not turning into a book, we’re going to mostly leave them unmentioned here. The reality is that if you’ve been a happy Heroku customer, you shouldn’t go looking down this path. I know that’s a strong statement that might make a few of the “come to the DIY-side!” folks upset, but it’s a pragmatic truth. These are two wholly different worlds with different levels of time and skill involved. Going ‘down’ a single layer in the hosting stack (as we perceive it) and getting into Fly’s ecosystem is already going to add overhead to your workflow as you need to learn to understand and handle their config complexity. Going all the way down to the HIY tooling is only going to add more ops time (or people!) to your app’s needs. If you’re happy with your PaaS-level at Heroku, stay up there!

The Real Answer

Let’s zoom out and take a deep breath. I still fully stand by my original sentiment above: Heroku isn’t going anywhere and will remain stable for years to come. There’s no urgency to move, and doing so will only detract from the hours you could be spending on your product itself at this point. Moving takes work. We can’t ignore that reality amidst the hype here.

Then, of course, conceding to those who are for sure going to move soon out of principle, spite, or otherwise disdain for Salesforce (which… I get), we covered some options. Render is the clearest, clean-cut, easy choice. Fly is more complex but more complicated. Railway isn’t recommended at the moment. Host-it-yourself and bring-your-own-cloud solutions are way more effort than a Heroku team should look at.

So…. move to Render and call it a day? Not exactly.

As your resident auto-scaling experts for the last decade, who have integrated deeply with and provide autoscaling services for nearly all of the platforms previously mentioned, we have some opinions.

But our opinions are from last year (or prior). And they’re based on integration work with Judoscale. And, who knows, they might just be wrong. So we’re going to do something that we haven’t seen done before: we’re going on tour.

Judoscale On Tour

As much as I wish that meant a music tour around the US with our kazoos, we actually hatched up a better idea. Judoscale is a 24/7 real-time reactive production application. We receive well over 3,000 RPS every moment of every day. Our downtime is exceedingly rare (generally only when Cloudflare or Heroku themselves have issues), but then, it darn well should be! We’re an auto-scaler! We need to be online, regardless of traffic load, so that we can reactively scale our clients’ applications correctly and appropriately any time of day.

Sounds like the perfect app to move to each of these platforms / services to test some things out.

To be clear: our “going on tour” means that we’re going to migrate the Judoscale production application, including all traffic, DNS, configs, background workers, etc, to each of Heroku’s competitors, one at a time, and document every step along the way for you all.

So, again, our real recommendation here is simply to hang tight on Heroku. We’re going to take the plunge for you (many times over) and move our real-time, high traffic application ourselves. We’re going to find the rough edges. We’re going to feel the performance bottlenecks. We’re going to foot the literal bill and feel the DX each of these new platforms provides compared to ol’ purple.

If that sounds exciting to you, make sure you subscribe to our newsletter below. We’ll start with a full breakdown of all the things we love and use on Heroku, which will set forth our rubric for how to evaluate other platforms.