Dora NodaOn February 6, 2026, Heroku's chief product officer published a short post titled "An Update on Heroku." The key sentence was buried in corporate padding: Heroku was transitioning to a "sustaining engineering model focused on stability, security, reliability, and support," with "an emphasis on maintaining quality and operational excellence rather than introducing new features." New Enterprise contracts would no longer be offered to new customers.
Translation: Heroku is in maintenance mode. Salesforce said the quiet part out loud — analysts at InfoWorld and The Register immediately read it as preparation for phasing the platform out — and the long Heroku long tail finally got the signal it had been dreading since the free tier died in 2022. The retrospectives arrived within days: Encore's destination analysis, a roundup of twelve post-mortems, Django-community farewells. The question stopped being whether to leave and became where to land so you never have to do this again.
This post answers that question concretely. Below you get three artifacts: a map of which workload shapes land best on Railway, Render, Fly.io, or a self-hosted box (grounded in the published 2026 migration analyses, not vibes); one reference workload priced on all five destinations at two usage levels, so you can see exactly where usage-metered billing crosses over fixed tiers; and a three-question decision tree keyed on dyno count, Postgres entanglement, and ops capacity. The short version is in the tables; the rest of the post substantiates every row.
The diaspora map: four shapes, four destinations
Heroku's concepts — dynos, Postgres add-ons, workers, config vars, pipelines — map cleanly onto every alternative, so migration effort is rarely the differentiator. The differentiator is fit. Encore's 2026 analysis put it crisply: fastest migration from Heroku goes to Render, global edge performance to Fly.io, modern developer experience with unlimited team seats to Railway. The fourth destination, the one every 2026 retrospective mentions and none of the vendors will, is a box you own running Coolify, Dokploy, or plain Kubernetes. Here is where each shape lands best, and the evidence behind each cell:
| Workload shape | Lands best on | Why (evidence) |
|---|---|---|
| Solo side project, sleeps OK | Railway or Render free/hobby floor | Cheapest always-on floor; Railway's $5 Hobby includes $5 of usage, Render's Starter is $7 always-on |
| Small team: web + worker + Postgres + Redis | Render | Fixed per-service tiers make the bill predictable; Postgres has a managed path from ~$6/mo; Encore names it the fastest Heroku migration |
| Latency-sensitive, multi-region | Fly.io | Machines run close to users with per-second billing; the only destination architected for edge first |
| Regulated, Enterprise-scale, or cost-at-scale | Self-hosted (Coolify/Dokploy/K8s) | No per-dyno rent at scale; Coolify (~57,000 GitHub stars) and Dokploy (~35,000) are the most-starred Heroku-shaped escape hatches as of mid-2026 |
Two honest caveats. First, "lands best" is prescriptive synthesis from vendor pricing pages, status/incident blogs, and the published migration guides — there is no census of ex-Heroku apps, so anyone claiming exact market shares is inventing them. Second, the map assumes a standard Twelve-Factor Heroku app (stateless web, background worker, Postgres, Redis). If your estate leans on Heroku-specific add-ons (Connect, Shield Private Spaces), your migration is an architecture project, not a destination choice — budget accordingly.
The money: one typical app, priced on all five
Take the canonical Heroku setup: one Standard-1X-class web process, one worker, one managed Postgres, one Redis. On Heroku today that is roughly $25 (web) + $25 (worker) + $50 (Standard-0 Postgres) + $15 (entry managed Redis) = ~$115/month. That is the number to beat. Here is the same shape everywhere else, at two usage levels — a quiet service idling most of the day, and the same app at roughly 3× sustained usage:
| Destination | Quiet (~idle) | Busy (~3× usage) | Billing character |
|---|---|---|---|
| Heroku (reference) | ~$13 (Eco $5 + Essential-0 Postgres $5 + Mini Redis $3; web sleeps) | ~$115 (Standard dynos + Standard-0 PG) | Fixed tiers; sleeping is the only discount |
| Render | ~$13 (one $7 Starter web + ~$6 basic Postgres) | ~$30–40 (web + worker Starters, ~$6 Postgres + storage, ~$10 Key Value) | Fixed per-service; usage barely moves the bill |
| Railway | ~$5–10 (metered RAM/CPU inside the $5 Hobby credit) | ~$40–60 (metered ~$10/GB RAM + ~$20/vCPU plus the plan fee) | Usage-metered per second; PR environments multiply it |
| Fly.io | ~$5–10 (a couple of small shared-CPU Machines, PAYG) | ~$25–45 (more/larger Machines + volumes; snapshots billable since Jan 2026) | Per-second PAYG; no free tier for new orgs since Oct 2024 |
| Self-hosted Hetzner box | ~$5 (single CX-class VPS) + your time | ~$10–25 (bigger VPS or two) + your time | Flat machine rent; the bill is pager duty |
Figures are estimates from each vendor's public pricing in 2026 — verify against your actual invoice shape before committing. But the pattern is robust, and it is the whole point of showing two columns: metered billing wins quiet and loses busy. At idle, Railway and Fly.io are the cheapest rented options because you pay for nearly nothing. At 3× sustained usage, the meter runs hot — Railway's per-GB RAM metering and Fly's per-Machine-second pricing both converge toward, and can pass, Render's flat tiers. Render's line is nearly horizontal: the quiet app and the busy app cost roughly the same because a Starter instance costs $7 whether it idles or sweats. That crossover — metered cheaper below it, fixed cheaper above it — is the single most important row in this post. If your traffic is spiky or mostly idle, rent the meter. If it is sustained, rent the tier. If it is sustained and growing, skip both rows and price the last one.
The self-hosted row needs its asterisk stated plainly: the machine is the cheapest line item and your time is the most expensive one. A VPS that runs the whole reference stack for the price of a coffee is real. So is the 2 a.m. page when unattended upgrades reboot the box mid-deploy. Coolify v4 (April 2026) and Dokploy have made the happy path genuinely Heroku-shaped — git push, automatic TLS, managed Postgres in a container — but "managed Postgres in a container on your VPS" is not the same product as a managed database with point-in-time recovery, and the gap shows up exactly once, at the worst moment. Count ops hours at your real hourly cost before declaring the $5 row the winner.
What each destination did in 2026 (and what it tells you)
Price is the first filter; trajectory is the second. You are picking a platform you will not have to migrate off again in two years, so each destination's 2026 record matters as much as its pricing page.
Railway: the outage record is the price of velocity. Railway published at least four incident reports in the first half of 2026: a February 11 outage caused by its own misconfigured automated abuse-enforcement terminating legitimate deployments; a February 18–21 stretch of DDoS plus upstream Cloudflare trouble; a May 19–20 platform-wide outage of roughly eight hours after Google Cloud suspended services on Railway's production account; and a July 2 US-East zone outage. To its credit, Railway writes unusually honest post-mortems, and the May incident's root cause — a dependency on a single upstream cloud account — is fixable and, by their account, being fixed.
But the pattern is what it is: a fast-moving team building on rented GCP capacity, where the blast radius of someone else's enforcement decision is your production. If you choose Railway, you are betting the post-mortems keep getting better faster than the incidents keep coming. For a side project that bet is free. For revenue infrastructure, price it like an SLA you do not have.
Fly.io: the slow squeeze of the hobbyist. Fly.io did not have a dramatic 2026 moment; it had a ratchet. Free allowances ended for new organizations back in October 2024 (legacy Hobby/Launch/Scale plans kept theirs, and Fly now lets legacy users convert to pay-as-you-go instantly — one way, no going back). Volume snapshots became billable on January 1, 2026. GPU Machines were marked deprecated, unavailable after August 1, 2026. Each change is defensible in isolation; together they describe a platform steadily repricing its cheapest users upward while keeping the headline "per-second billing" story.
Fly.io remains the best technical answer for multi-region latency, full stop. Just model the 2027 price of your Fly bill with the ratchet in mind, not the trial credit.
Render: boring is the feature. Render's 2026 story is the absence of one — no platform-wide outages in the record, no plan deprecations, no billing-model pivots. Fixed per-service tiers ($7 Starter web services, Postgres from ~$6 plus $0.30/GB storage) plus a free Hobby workspace and a ~$19–25/seat Pro tier is a model with obvious repricing headroom: the day growth stalls, per-service prices or the Pro seat are the levers, and there is no usage meter to hide behind. That is a risk, but it is a legible, forecastable risk — the bill next year is either the same or an announced number, never a surprise meter reading. For a team migrating off a platform that just demonstrated what "maintenance mode" does to roadmaps, legibility has real value.
Self-hosted: traction is real, and so is the pager. The star counts tell the demand story — Coolify around 57,000 stars, Dokploy in the 30,000s, CapRover around 15,000 as of mid-2026 — and Coolify's v4.0 (April 2026) closed much of the UX gap with rented PaaS. The supply story is unchanged: you are the SRE team, the backup strategy, and the incident response. The 2026-correct way to read self-hosting is not "free Heroku" but "fixed-cost Heroku with a labor line item" — unbeatable past a certain scale, irresponsible below a certain team size, with the threshold sitting roughly where the decision tree below puts it.
The decision tree: dynos × Postgres × ops capacity
Three questions, in order. Answer honestly; the tree only works if you do.
1. How many dyno-equivalents do you run? One or two processes (a web plus maybe a worker) means every destination is cheap and migration cost dominates — optimize for the fastest move, which is Render, with Railway a close second if your usage idles. Past roughly five always-on processes, fixed tiers and flat machine rent pull away from meters fast enough that Railway and Fly.io need explicit justification. Past a dozen, you should be pricing self-hosted seriously even if you ultimately stay rented.
2. How entangled is your Postgres (and Redis)? This is the branch that actually determines migration pain. Under ~1 GB with no extensions beyond pgvector/pgcrypto: pg_dump and restore onto any managed Postgres (Render's from ~$6/mo, or a self-run container) in an afternoon. Tens of GB with followers, scheduled backups, and Dataclips-style tooling: use the destination's managed import path and test restore-to-point-in-time before cutover, or the migration stalls here regardless of destination. Heavily entangled (Heroku Connect syncing to Salesforce, Private Spaces compliance scoping): stop comparing PaaS pricing — you have an architecture migration with a Salesforce dependency, and the destination choice is secondary to unwinding it.
3. How much ops capacity does the team have? Zero (solo dev, no on-call): stay rented — Railway if idle, Render if sustained, Fly.io if multi-region. Some (one person comfortable with Docker and backups): self-hosted becomes rational at the scale where its labor line item fits inside the meter savings, typically once the rented bill clears ~$100/mo. A real rotation: self-host whenever the five-year math favors it, because at that point the pager already exists and the rent is pure margin to someone else.
Follow the branches and you land on exactly one destination — that is the deliverable this post promised, and it doubles as your re-migration insurance: each leaf was chosen not just for today's bill but for the 2026 trajectory behind it.
Pick the last migration
Heroku earned eighteen years of loyalty by making deployment boring, then spent its final act demonstrating what happens when boring stops being maintained. The diaspora it triggered is genuinely good news: every destination above is a better deal than Heroku at most scales, the migration paths are well trodden, and the failure modes are documented in public post-mortems rather than hidden behind support tickets.
The one decision to avoid is drifting — staying on a sustaining-engineering platform out of inertia while the ecosystem, the talent pool, and eventually the security patches move on. Maintenance mode is not a cliff, it is a slow slope, and slopes are easy to ignore until migration becomes urgent instead of planned. Pick your leaf on the tree above, schedule the pg_dump, and make this migration the last one for a while.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your branch of the decision tree ends at "self-hosted," that is exactly the gap bex fills: Heroku-shaped deploys without the dyno rent and without the 2 a.m. pager belonging to you alone. Star the repo on GitHub or deploy your first app today.
