Heroku Alternatives in 2026: Auditing the Render vs Railway vs Fly.io Rankings, Priced to the Dollar

Heroku spent 2026 making the decision for you: sustaining-engineering mode, no new enterprise contracts, and a free tier that has been gone since November 2022. The question is no longer whether post-Heroku teams should leave — it is where they land. One ranking that keeps getting passed around is raksiv/heroku-alternatives, an opinionated list that grades Render as the closest one-to-one Heroku replacement, Railway as the velocity pick, and Fly.io as the edge-native option.

Rankings are cheap; migrations are not. So I audited the list's claims for the big three the way a migrator would — buildpack compatibility, add-on parity, bill predictability — and priced the same pinned workload on all three, plus a flat-rate Hetzner box as the none-of-the-above baseline.

The verdict, up front:

The ranking under audit​

The list I audited is raksiv/heroku-alternatives at commit de0c391 (August 31, 2026): nine platforms, one comparison table, and a "best for / consider elsewhere if" note per entry. It also covers Suga, Vercel, Porter, Dokploy, Coolify, and Dokku, but this audit stays on the three platforms teams actually shortlist first, since those carry the strongest claims:

• Render — "closest one-to-one Heroku replacement": runtime detection or Dockerfile, automatic TLS, zero-downtime deploys, instances to 32 GB / 8 CPU, first-party managed Postgres with point-in-time recovery, published SOC 2 / ISO 27001.
• Railway — canvas-first composition, per-minute CPU/RAM billing, SSH into running containers.
• Fly.io — micro-VMs across dozens of regions, geographic distribution as a first-class primitive.

The list's own migration advice is sound and worth quoting: containerize the app first, move the database during a low-traffic window, audit years of accumulated config vars, decide the runtime model deliberately, and mirror your environments. Everything below assumes you take that advice. Now, claim by claim.

Claim-by-claim audit​

Render: does the 1:1 claim survive?​

Mostly yes. Push a repo and Render detects the runtime or reads your Dockerfile; managed TLS, health checks, and zero-downtime deploys all behave the way a Heroku team expects. The 32 GB / 8 CPU ceiling (Pro Ultra, $450/mo) genuinely exceeds anything Heroku's dyno grid offered, and managed Postgres with PITR plus published SOC 2, ISO 27001, and HIPAA-on-Scale compliance covers the two objections — data safety and procurement — that kill most migrations late.

Three catches, all billing-shaped. First, Render's April 2026 reprice put paid workspaces on a $25/mo Pro fee (legacy $19/user workspaces force-migrated August 1, 2026), so the meter starts before you run anything. Second, compute is metered and Postgres storage is billed separately ($0.30/GB/mo on top of ~$6/mo Basic compute), which makes the invoice harder to predict than the old flat dyno math. Third, the free tier is now an evaluation tier in the strictest sense: free Postgres expires after 30 days, and paid workspaces get 25 GB of bandwidth before the $0.15/GB overage bites.

Buildpack compatibility is the one hard break from Heroku: Render has no Heroku-buildpack path, only native runtimes and Dockerfiles. If your deploy still depends on a custom buildpack chain, the Dockerfile rewrite is part of the migration cost. Grade: A-.

Railway: does the velocity claim survive?​

Yes, with an asterisk on the bill. The canvas — services, databases, workers, and crons composed visually with networking and secrets wired between them — is the fastest credible path from Heroku I have seen, and SSH into running containers plus per-minute billing genuinely change how teams iterate. Hobby starts at a $5/mo minimum that includes $5 of usage; Pro is a $20 minimum with matching credit.

The catches are structural. Railway's Postgres runs as container templates, not first-party managed Postgres — experimental HA landed in March 2026, but if PITR-backed managed Postgres is your compliance story, this is a downgrade you must price (either operationally or via an external provider like Neon or Supabase). There is no edge WAF or L7 DDoS protection without bolting on a separate vendor. And the June 2025 incident, when Railway throttled then paused Trial and Hobby deploys to protect Pro capacity during a demand surge, is a reminder that the cheapest tier is also the most preemptible.

Buildpack-wise, Railway uses its own Nixpacks-based build system — no Heroku buildpacks, so custom buildpack chains need reworking, though standard runtimes mostly just work. Grade: B+.

Fly.io: does the edge claim survive?​

If you are actually multi-region, yes — nothing else at this price makes "run this container close to the user" a one-line config. Micro-VMs with Anycast routing, fly.toml-declared regions, and managed Postgres round out a platform that is closer to a programmable edge cloud than to Heroku.

If you are single-region behind a single database, the list's own caveat applies: much of Fly's distinctive value evaporates, and you are left with the steepest learning curve of the three — fly.toml semantics, Machine sizing, volume management — for an app that would have been simpler on Render. Pricing is usage-based across CPU, RAM, volumes ($0.15/GB), and bandwidth (100 GB free, then $0.02/GB in North America and Europe), which rewards small footprints: an always-on shared-1x 256 MB Machine runs about $1.94/mo. But the free tier as Heroku teams remember it is gone — retired in October 2024 — and IPv4 beyond the first address is $2/mo each, the kind of line item that surprises exactly once.

On buildpacks, Fly.io is the most Heroku-flavored of the three: Dockerfile-first, but with documented Heroku-buildpack support as a secondary build path. Grade: B for the typical single-region migrator, A- if multi-region latency is the actual requirement.

Same workload, four bills​

Estimates below are the author's, computed from public pricing pages in September 2026 — verify against each vendor's calculator before budgeting. The pinned reference workload:

• Web: 1 shared vCPU / 512 MB, always-on (~730 h/mo)
• Worker: 0.5 vCPU / 512 MB, always-on
• Postgres: 10 GB with PITR where offered
• Redis/KV: ~1 GB
• Egress: 100 GB/mo

Two things jump out. First, Fly.io wins this workload on price by a distance — but read the grade, not just the bill: you are trading dollars for fly.toml fluency and self-assembled data durability. Second, the Hetzner box looks mid-pack here only because this workload is small; the box barely notices it, and the next five services are free.

Sensitivity matters more than any single total. In an idle month, Fly.io's auto-stop/auto-start collapses compute toward zero while Render's workspace fee and Railway's minimums do not move — usage billing wins. In a 500 GB egress month, the ranking inverts: Render's overage adds roughly $71, Railway bills beyond its allowance, Fly.io adds about $8, and Hetzner does not move at all. If your traffic graph has spikes, price the spike month, not the average month.

The honest Hetzner accounting is box price plus the Cluster API ops burden: you run Postgres, PITR, backups, and upgrades yourself. That is a real cost — on-call load and platform-engineering hours — which is why the baseline grades B+ on value rather than topping the table. But it is a fixed cost that amortizes across every workload you add, while metered bills scale with each one.

The migration checklist​

Whatever you pick, the Heroku exit itself follows one pattern:

1. Containerize first. A Dockerfile is accepted everywhere and survives your next migration too. Only Fly.io offers a buildpack bridge; everywhere else, custom buildpack chains get rewritten now.
2. Move Postgres deliberately. Dump, restore, and cut over in a low-traffic window — and decide up front whether you need true managed PITR (Render, or an external provider paired with Railway/Fly.io/Hetzner).
3. Audit config vars. Years of Heroku config accumulate secrets nobody remembers. Migration is the cheapest time to delete them.
4. Map the add-ons. Redis, schedulers, logging drains, and error tracking each need a named replacement — the add-on ecosystem is the part of Heroku with no single equivalent anywhere.
5. Mirror environments. Recreate dev, staging, and production as isolated projects/environments on day one, not as an afterthought.
6. Rehearse the cutover. Dual-point DNS, verify, then switch. Zero-downtime deploys on the new platform do not automatically make the migration zero-downtime.

Who should pick what​

• Pick Render if you want the Heroku loop back with bigger instances and a compliance packet — and your traffic is steady enough that a $25 workspace fee plus metered extras stays predictable.
• Pick Railway if deploy velocity and canvas-level visibility matter more than managed Postgres, and your workloads are bursty enough that per-minute billing beats flat rates.
• Pick Fly.io if your users are global and latency is a feature; skip it if you are single-region and would rather not become fluent in Machine sizing.
• Pick the Hetzner baseline if you have platform-engineering capacity and a growing service count — the flat box turns every additional workload from a new bill into a rounding error.

The broader lesson from auditing the list: every "best for" claim survived in its home territory and failed exactly where the list's own "consider elsewhere if" said it would. Read those caveats as the actual ranking. And if the Hetzner row tempted you but the ops burden did not, that gap — Heroku-grade deploy UX on infrastructure you own — is precisely what the self-hostable, git-push PaaS generation is being built to close.

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.