Need a partner to plan and run the move?
This page helps you decide where each workload should go. If you want a senior team to do the migration — including the web estate in front of it — see Website migration.
Read this first: every other list is a sales page
Search for Heroku alternatives and you’ll get a dozen articles, almost all of them published by a platform that appears at number one on its own list. That’s not a conspiracy, it’s just how content marketing works — but it means the genuinely useful question never gets asked: what kind of workload do you actually have, and where does that specific thing belong?
We move estates off Heroku as part of larger replatforms, and we don’t sell hosting. So this page sorts by workload rather than by vendor, names what each move costs, and ends with the moves we’d talk you out of.
What actually changed at Heroku
On 6 February 2026, Heroku’s SVP and general manager published an update announcing a transition to a “sustaining engineering model.” In plain terms:
- Heroku is not shutting down. It remains a supported, production platform. The roadmap is now defensive — security patches, stability fixes, infrastructure maintenance — rather than new capability.
- Heroku Enterprise is end of sale to new customers. Existing contracts continue to be honoured and can renew. New customers paying by card in the dashboard are unaffected: same pricing, same billing, same service.
- Apps, pipelines, teams, and add-ons keep working. Nothing about day-to-day usage changed on the announcement date.
- No end-of-life date has been announced. Anyone telling you there’s a deadline is inferring one from how Salesforce has wound other products down.
The strategic read matters more than the operational one. Fir — the Kubernetes-based next generation that succeeds Cedar, built on Cloud Native Buildpacks — reached general availability only inside Private Spaces, which are part of the tier now closed to new customers. So the modern runtime is gated behind the product line that stopped selling, while the classic Cedar runtime is the one most teams are actually on. That’s the signal worth acting on: not “it’s breaking tomorrow,” but “this platform will not gain the thing you need in three years.”
Do you have to move?
Often, no — and it’s worth saying that out loud on a page like this.
If you run a handful of Cedar dynos, pay by card, the bill is proportionate and the app is stable, then “sustaining engineering” describes a platform that does exactly what it did last year. Migrating consumes engineering capacity you could spend on something that produces value. Put it on the roadmap, not in this quarter.
The cases where we would move now: you’re on an Enterprise contract and building anything new (you’re on a product line that no longer sells, with a runtime you can’t grow into); your bill has crept into the hundreds per month for capacity you could buy more cheaply elsewhere; you need a capability the platform is no longer going to add; or you’re already doing a replatform of the web estate, in which case the marginal cost of moving the services behind it is at its lowest it will ever be.
Where the workloads actually land
The mistake almost every alternatives list encourages is picking one destination for everything. A typical Heroku account is holding at least two different kinds of thing, and they belong in different places.
The web front end → a front-end platform
If Heroku is serving a marketing site, a documentation site, or the public web estate, that workload doesn’t belong on a Heroku-shaped platform at all — not on Heroku and not on its successors. It belongs on a front-end deployment platform, where per-branch preview URLs, CDN-first delivery, and framework machinery (incremental regeneration, image optimisation) are platform defaults rather than things you build.
That’s Vercel for Next.js estates, Netlify for multi-framework ones, and Cloudflare where bandwidth is the dominant cost line. This is the highest-value part of the move and the part the vendor listicles never mention, because they’re selling the other half.
The app itself → Render, or Fly.io
Long-running web services, background workers, cron jobs, and a managed Postgres are what Heroku was actually good at, and they need a real destination.
Render is the closest thing to a like-for-like move. Same Git-push model, comparable managed add-ons, managed Postgres, private networking, and pricing by instance rather than by usage — which means bills move when you change the architecture, not when traffic spikes. Most teams leaving Heroku for a conventional app land here, and the migration is closer to mechanical than to a rewrite. Render’s own presence at the top of every “Heroku alternatives” list is self-interested and also, for this workload, roughly correct.
Fly.io is a different architecture wearing similar clothes. It runs Firecracker machines close to users, bills pay-as-you-go with no mandatory subscription, and rewards apps designed for multiple regions. In North America and Europe egress runs about $0.02/GB, rising to around $0.12/GB in Africa and India, and inbound transfer is free. If you genuinely need multi-region latency, it’s the better fit. If you don’t, you’re taking on a distributed-systems problem in exchange for nothing — and note that beyond community support, plans start at $29/month and reach $2,500/month and up for the top tier, which is a line worth checking before you commit a production app.
Teams with cloud contracts → your own cloud
If your organisation already has committed AWS, Azure, or GCP spend, an approved account, and a platform team, then the honest answer is that a managed platform is a second bill for something your existing contract covers. Containerised Heroku apps map onto ECS/Fargate, Azure Container Apps, or Cloud Run with a day’s work, and managed Postgres exists in all three.
This is the right call when data residency, procurement, or spend commitments are driving the decision — and the wrong one when nobody on your side wants to own the pipeline. That trade is worked through in full on bring your own cloud.
What each move actually costs
| Move | What it costs you | What you gain |
|---|---|---|
| Front end → Vercel / Netlify / Cloudflare | A separate platform and invoice from the app tier; a build pipeline rewrite for the web repo | Preview URLs as the review workflow, CDN delivery, framework features as defaults |
| App → Render | Environment and add-on remapping; instance sizing you now choose deliberately | Predictable per-instance billing, managed Postgres, an active roadmap |
| App → Fly.io | Region and networking design; support tiers priced separately from compute | Multi-region latency, fine-grained pay-as-you-go compute |
| Everything → your own cloud | Pipeline, CDN, patching and on-call as a standing commitment | One vendor, one security review, delivery inside your own tenancy |
| Stay on Heroku | A platform that will not gain capability; Fir gated behind a closed tier | Zero migration cost this year, and no announced deadline |
For reference on the baseline you’re leaving: Heroku’s Cedar dynos run from $5 for Eco and $7 for Basic through $25–$50 for Standard tiers to $250–$1,500 for Performance, with Fir’s General Purpose sizes starting around $25 and reaching $1,200 for the largest, and Postgres Essential plans from $5. Price your actual dyno formation before assuming a move saves money — for small formations it often doesn’t, and the reason to move is capability, not cost.
What to skip
- Don’t pick a destination from a ranked list. The list’s author is on it. Sort by workload shape first; the shortlist writes itself and it’s usually shorter than ten.
- Don’t move to Kubernetes because it feels like the grown-up answer. If you’re on Heroku, you deliberately chose not to own an orchestrator. Adopting one during a forced migration means learning two things at once, and the cluster becomes a permanent staffing commitment.
- Don’t treat Fir as the safe landing. It’s the newer runtime, but it arrived inside the product line that stopped selling. Moving Cedar to Fir means adopting Cloud Native Buildpacks and re-testing everything — the same work as leaving, without the benefit.
- Don’t put the marketing site wherever the app goes. The single most common outcome we clean up: the public estate ends up on a backend platform, and every campaign page now waits on a deploy nobody can preview.
- Don’t split one application across three providers to chase the best price on each. The saving is small, and cross-provider latency, egress, and on-call ambiguity are not.
- Don’t start with a lift-and-shift if a replatform is already funded. If the web estate is being rebuilt anyway, moving the services at the same time is the cheapest it will ever be.
The Bejamas take
Heroku in sustaining engineering is a planning problem, not an emergency. The platform still runs, existing contracts still renew, and nobody has announced a date — so the right posture is a considered split rather than a rushed lift-and-shift onto whichever vendor ranked itself first.
In practice we’ve found the split is almost always the same: the public web estate goes to a front-end platform where marketers can publish and stakeholders can review, the services behind it go to Render or into the client’s own cloud, and the database goes wherever the services went. The value isn’t in the destination, it’s in stopping one platform from carrying two jobs it was never good at doing together.
If you’re weighing this up as part of a wider replatform, an audit is where we price both halves properly — your dyno formation, your traffic, and your team’s capacity — and give you the split with the trade-offs written down.