Skip to main content

Heroku Is Frozen: What the 2026 Exit Guides Actually Recommend (and the Cost Row None of Them Prices)

9 min readDora NodaDora Noda
Share
On this page

On February 6, 2026, Heroku's CPO published "An Update on Heroku" and froze the platform that invented git-push deploys: sustaining-engineering mode, no new features, no new Enterprise contracts. Seven months later, the exit guides agree on the shortlist — Render, Railway, Fly.io, self-hosted Coolify — but disagree on who each one fits, and none of them prices the row that ends the meter entirely. This post reads the guides against each other, maps each exit to the Heroku workload shape it actually fits, and prices a typical dyno topology four ways, including on hardware you own.

Heroku is frozen, not dead​

Three facts from the February announcement drive every decision below. First, Heroku moved to a sustaining engineering model: security patches, stability fixes, and infrastructure maintenance only — no new feature development. Second, Enterprise Account contracts are no longer offered to new customers; existing Enterprise customers can renew, but Salesforce is not onboarding new ones. Third, nothing changes for existing customers on pricing or service: your dynos keep running, the add-on marketplace keeps working, and the platform keeps getting patched.

That combination is what makes this a slow-burn decision rather than a fire drill. Nobody's apps stopped working. But every team on Heroku is now running on a platform whose roadmap is defensive by declaration, and every renewal conversation happens against the knowledge that the vendor has redirected product investment elsewhere. The guides written since February all start from this same premise and then diverge on where to go.

What the exit guides agree on​

Read the Back4App, FlightFormation, and Encore guides side by side and the same four names survive every cut. The consensus shortlist:

ExitWhy the guides keep itGuides' one-line verdict
RenderClosest Heroku UX match: git push, buildpacks-to-Dockerfiles, managed Postgres, preview envsSimplest migration, stay managed
RailwayFastest git-push-to-URL loop, usage-based pricing, unlimited team seatsBest DX for teams running many services
Fly.ioLightweight VMs in 30+ regions with Anycast routing and private networkingThe pick when latency geography matters
Self-hosted (Coolify/Dokku)Open-source PaaS on your own VPS, flat-rate box replaces every meterLowest cash cost, you own the ops

Back4App's guide names the migration drivers explicitly: cost (the free tier died in November 2022 and never came back), limited control (AWS-only, US/EU Common Runtime unless you pay for Private Spaces), and operational limits (the 30-second router timeout, daily dyno restarts). FlightFormation — which, disclosure-style, sells Heroku autoscaling and would rather you stay — updated its guide in September 2026 with per-platform pros, cons, and pricing across a dozen options, and still lands on the same core four for Heroku-shaped workloads. Encore's guide is the most opinionated: Render for the fastest migration, Fly.io for global performance, Railway for larger teams, self-hosted for the lowest possible bill.

The honest subtext of all three: none of these is strictly better than Heroku at being Heroku. Each one wins on one axis and charges on another. So the useful question isn't "which is best" — it's "which fits the workload shape I actually run."

Which exit fits which Heroku workload​

Here is the read-across the guides imply but never tabulate — five Heroku workload shapes, each mapped to its best-fit exit:

Your Heroku shape todayBest-fit exitWhy
One web dyno + Postgres + a scheduler job (the classic Rails/Django side project, grown up)RenderConcepts map one-to-one: web service, managed Postgres, cron jobs, preview deploys. Lowest relearning cost.
Monorepo or microservices: many small services, review apps per PR, a team of 5+RailwayUsage-based pooling across services beats per-dyno math, unlimited seats remove the per-developer tax, and the DX is built for service sprawl.
Users on three continents, or WebSocket/edge-sensitive trafficFly.ioMulti-region VMs with automatic failover and private networking — the thing Heroku's two-region Common Runtime never offered without Private Spaces money.
Private Spaces, Shield dynos, compliance requirementsStay (for now) or BYOCNo exit guide will tell you this plainly: none of the metered three replicates the compliance posture. If you must leave, a bring-your-own-cloud option on your own VPC is the honest replacement, not a sideways meter.
Hobby / side project on Eco + Mini Postgres (~$10/mo)Stay, or Render StarterAt this scale the bill is a rounding error and every migration costs a weekend. Move only if you want off a frozen platform on principle.

Two rows deserve emphasis because the guides soft-pedal them. The compliance row: Private Spaces dynos run $125–$1,500/month precisely because they buy network isolation and region control; "just move to Render" is not a compliance migration plan. And the hobby row: nobody saves real money migrating a $10/month app, and saying so is part of honest advice.

The row none of them price: the same dynos on hardware you own​

Every guide prices the sideways moves. None prices the exit that ends metering: the same topology as containers on a flat-rate box. So here it is, for a typical team topology — 2 web dynos, 1 worker, managed Postgres, managed Redis — using published list prices at the time of writing:

LayerHerokuRenderRailwayFly.ioOwned box (Hetzner-class VPS)
2× web (~1 GB RAM each)2× Standard-2X: $1002× Standard web: ~$38–50Pooled usage: ~$20–302× shared/dedicated VMs: ~$15–30Included in box
1× worker1× Standard-1X: $251× Starter worker: ~$7–25Pooled usage: ~$5–101× VM: ~$5–15Included in box
PostgresStandard-0: $50Managed Postgres: ~$6–19Built-in Postgres: ~$5–10Managed/self-hosted PG + volumes: ~$5–15Self-hosted in a container
RedisMini/Key-Value: ~$15Key Value: ~$10Plugin/service: ~$5Upstash/own Redis: ~$0–10Self-hosted in a container
Total~$190/mo~$60–105/mo~$35–55/mo~$25–70/mo~€4–12/mo + your ops time

The sideways moves cut the Heroku bill by roughly half to three-quarters. The owned box cuts the cash cost by 90%+ — and adds the one cost no table can price for you: whoever wakes up when the box misbehaves.

That honesty requires the sensitivity analysis — where the answer flips:

  • Below ~$25/month, the metered move wins outright. A hobby app on Eco + Mini Postgres costs less than the cheapest VPS worth running, before counting a single hour of ops. Self-hosting to save $8/month is a hobby, not a strategy.
  • Between ~$25 and ~$100/month, it's a judgment call. The cash savings are real but modest; the deciding factor is whether someone on the team already wants to own infrastructure. If yes, the box pays for itself in month one. If no, Railway or Render is the rational move.
  • Above ~$100–150/month of metered spend, the box wins on cash decisively — the crossover where one flat-rate machine replaces a metered stack, and every additional service after that rides free. The remaining question is purely operational: do you have (or want to build) the runbook for backups, TLS, upgrades, and on-call?

The guides don't show this row because most of them sell, recommend, or assume managed infrastructure. But "migrate sideways to another meter" is a strange definition of an exit from a platform whose core problem was never just price — it was dependence on a vendor that just demonstrated what happens to your roadmap when priorities shift.

What the migration actually touches​

Whichever exit you pick, the work inventory is the same shape. The guides agree on the checklist even when they disagree on the destination:

  • Buildpacks → images. Heroku's buildpacks auto-detected your stack; Render and Railway keep some of that magic, Fly.io and self-hosted want a Dockerfile. Writing the Dockerfile is the forcing function that makes your build reproducible anywhere — do it even if your destination doesn't require it.
  • Add-ons → managed or self-hosted replacements. Postgres and Redis have first-class equivalents everywhere; the long tail (logging, monitoring, email, search) is where migration estimates go wrong. Inventory every add-on before you commit to a destination.
  • Review apps and pipelines → preview environments. Render, Railway, and Fly.io all ship PR previews; self-hosted Coolify does too. The mechanism differs, the capability survives.
  • Scheduler and workers → cron + worker services. Straightforward everywhere, but verify cron semantics: Heroku Scheduler's 10-minute granularity and one-off dyno billing have no exact twin.
  • Private Spaces → VPC story. The only genuinely hard row. If you needed Spaces, your migration is a networking project with a deploy step, not a deploy project — budget accordingly.

FlightFormation's guide makes one contrarian point worth repeating: if your complaint is cost rather than the freeze, autoscaling your existing dynos may buy back more dollars per hour than any migration. Optimize-then-decide beats migrate-then-discover-you-didn't-need-to.

The freeze is the forcing function; the meter is the real question​

Heroku's sustaining mode didn't break anyone's app — it broke the assumption that staying put is the default. The guides' consensus is genuinely useful: Render for the closest Heroku shape, Railway for service-sprawl teams, Fly.io for global latency, self-hosting for the lowest bill. But the decision that matters isn't which meter to move to. It's whether your next platform bills you for every dyno-hour forever or runs on machines whose cost you already know.

Sources: Heroku "An Update on Heroku" (Feb 6, 2026) via Heroku blog; Back4App "Best Heroku Alternatives in 2026"; FlightFormation "Heroku Alternatives" guide (updated Sept 2026); Encore "Top Heroku Alternatives in 2026" and "Heroku Is Gone, Here's Where Developers Are Going"; DigitalOcean "Top 11 Heroku Alternatives" (2026); Heroku pricing page and dyno technical specifications (Dev Center); Techsy.io "Railway vs Render vs Fly.io: Benchmarks & Pricing (2026)".

Running the numbers on leaving Heroku for hardware you own? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Related articles

Check your move before you migrate

Free browser tools: check a render.yaml or your Render scripts against bex, or turn a Heroku app or docker-compose.yml into a draft render.yaml. Nothing you paste leaves your browser.

Open the migration tools