Heroku Is Gone: What the Railway-vs-Render Bill Split Really Costs in 2026

On February 6, 2026, Salesforce moved Heroku into what it called a "sustaining engineering model": stability, security, reliability, and support — but no new features, and no new Enterprise contracts. Two days later, Encore published the obituary-cum-migration-guide the whole ecosystem had been waiting for: "Heroku Is Gone, Here's Where Developers Are Going." Its verdict was blunt — the biggest shift is toward infrastructure ownership, but for teams that still want a managed platform, the two finalists are Railway and Render.

So here is the question every ex-Heroku team is actually asking: same dyno workload, two destinations — what does the monthly bill look like on each, and how does either compare to just owning the box? We repriced a typical Heroku topology line by line. The bottom line first:

Railway wins the sticker-price contest by a third. Render costs more but reads like Heroku with the serial numbers filed off. And the owned box is less than a third of either — with a catch we will price honestly below. The rest of this post shows the receipts: where teams actually landed, the worked math behind that table, what makes each bill move, and why "predictable" means something different on each platform.

Where ex-Heroku teams actually landed​

There is no census of Heroku refugees — nobody surveyed all of them. But the directional evidence from 2026 is consistent, and it points at four landing zones rather than one.

Render absorbed the teams that wanted Heroku with a new logo. Encore's guide calls Render "the most direct Heroku replacement" and names it the fastest migration from Heroku: dynos map to Render web services, Heroku Postgres maps to Render Postgres, buildpacks and config vars carry over. Render itself leaned into the moment with a Heroku migration guide, a Render-vs-Heroku comparison page, and up to $10K in migration credits for production moves. When a platform pays you to switch, it is telling you who it thinks is shopping.

Railway absorbed the teams that wanted per-second metering and a canvas. Railway's pitch is the inverse of Render's: no instance sizes to pick, just CPU, RAM, disk, and egress metered per second, composed on a project canvas with databases, workers, and crons wired together. The per-minute billing and generous per-service ceilings (up to 1,000 vCPU on Pro) made it the pick for spiky workloads that would idle on fixed dynos.

Own-cloud tooling absorbed the teams done with renting platforms. Encore's own answer — and the guide's headline recommendation — is infrastructure ownership: declare infrastructure in TypeScript or Go and deploy into your own AWS or GCP account, Heroku-style git push included. Groupon runs this pattern at scale. It is the "never be orphaned by a sustaining-mode announcement again" option, at the cost of owning a cloud account.

Self-hosting absorbed the teams done with per-unit metering entirely. Migration writeups from 2026 show the rest of the spread: Linode plus Kamal, Sealos for complex microservice estates, and the single-box fleet of Coolify, Dokploy, CapRover, and Dokku for teams whose topology fits on one machine. The common thread is a fixed hardware bill replacing every meter at once.

Our recompute below focuses on the two managed finalists — Railway and Render — with the owned box as the third column, because that is the decision most small teams are actually making.

What "Heroku is gone" actually means​

The facts, stripped of eulogy. Heroku launched in 2007, Salesforce bought it for $212 million in 2010, and the free tier died in November 2022. The February 2026 announcement formalized years of slowing investment: the platform keeps running for existing customers, but active development has stopped and new customers cannot buy Enterprise contracts. Analysts read it as managed decline; DigitalOcean's migration content calls it "corporate jargon for no new features and no forward roadmap."

The reason migration guides all sound calm about the mechanics is that Heroku's concepts — dynos, Postgres, workers, config vars, pipelines, review apps — map cleanly onto every alternative. Nobody is rewriting their app. The migration is a destination choice, which is exactly why the destination bills deserve a worked comparison instead of vibes.

The reference workload​

To reprice fairly, fix the workload first. Our reference is the modal small production Heroku topology: two Standard-2x web dynos, one Standard-1x worker, and a Standard-0 class Postgres with about 10 GB of data and roughly 100 GB of monthly egress. In Heroku money that is about $50 per 2x dyno, $25 for the worker, and $50 for the database — ~$175/month baseline.

Two notes on representativeness. First, this is deliberately boring: no autoscaling heroics, no multi-region story, just the web/worker/Postgres trio that most Heroku invoices describe. Second, the Postgres tier dominates every destination's bill, as it does in real life — compute is the part vendors love to discount, while managed Postgres is where the margin hides. Any comparison that prices compute and waves off the database is lying by omission.

The worked recompute: Railway vs Render​

Railway. Railway Pro is $20/month per workspace including $20 of usage credit, and everything else meters per second: $20 per vCPU/month, $10 per GB of RAM/month, $0.15 per GB-month of volume storage, $0.05 per GB of egress. Map the topology: two web services at roughly 1 vCPU and 1 GB each, a worker at 0.5 vCPU and 0.5 GB, Postgres at about 0.5 vCPU, 1 GB, and a 10 GB volume.

That is 3 vCPU ($60), 3.5 GB of RAM ($35), 10 GB of volume ($1.50), and 100 GB of egress ($5) — $101.50 of usage. Subtract the $20 included credit, add back the $20 workspace fee, and the invoice lands at ~$102/month. Note the shape of that number: every line scales with what you actually ran. Stop a service and its meter stops the same second.

Render. Render Pro is $25/month per workspace plus compute: a Standard instance (1 vCPU, 2 GB) is $25/month, a Starter (0.5 vCPU, 512 MB) is $7/month, Postgres Pro-4gb is $55/month with 1 GB of storage included and extra SSD at $0.30/GB, and bandwidth includes 25 GB before $0.15/GB overage. Map the same topology: two Standard web services ($50), one Starter worker ($7), Postgres Pro-4gb ($55) plus 9 GB of extra storage ($3), and 75 GB of egress overage at $0.15 ($11.25).

Total: $25 + $50 + $7 + $55 + $3 + $11.25 = ~$151/month. The shape is different from Railway's: two-thirds of the bill is fixed the day you pick instance sizes, and the only line that can surprise you is egress.

The delta. Railway at ~$102 vs Render at ~$151 on identical topology — a ~$49/month, ~32% gap, driven mostly by Render's fixed instance steps and its 3x egress rate. Against the ~$175 Heroku baseline, both destinations save money: Railway saves ~42%, Render ~14%. The migration pays for itself on compute alone; the database is what keeps either bill above $100.

What moves each bill​

Sticker prices lie by hiding sensitivity, so here is what actually moves each invoice — because this is where "predictable" splits into two meanings.

Egress is the biggest wedge. At our 100 GB assumption the gap is $5 (Railway) vs $11.25 (Render). Push the workload to 500 GB — a plausible month for an app serving images or an API with chatty clients — and Railway adds $25 while Render adds $71.25. Render's $0.15/GB is 3x Railway's $0.05/GB, and its 25 GB included allowance is exhausted by week one of anything real. If your Heroku app never thought about egress because it was bundled, Render is where that education arrives — metered, monthly, and priced like a hyperscaler.

Idle and preview environments cut the other way. Railway meters per second, so stopped services cost nothing and preview environments only bill while they run — but every replica, preview, and forgotten staging service adds metered lines that a fixed-instance platform would have folded into size choices you already made. Render's compute is provisioned per service per instance and prorated to the second: stopping a service stops its charge, yet while it runs you pay the instance step whether it serves one request or one million. Neither vendor offers true spend caps — Railway has usage-limit alerts and hard workspace limits, Render has no account spending-limit feature at all — so "predictable" on Railway means "the meter never sleeps but never overcharges," while on Render it means "fixed until egress ruins the month."

Postgres is the floor nobody escapes. Railway's database rides the same per-second meter as everything else; Render's starts at $55 for the smallest Pro tier. Teams repricing Heroku Standard-0 ($50) should expect the database line to stay roughly flat on either destination — the savings all come from compute. Anyone promising a $20/month production bill is pricing the web tier and hoping you forget the database.

The third column: the same topology on owned hardware​

Now the column the migration guides skip. A Hetzner AX41-class dedicated box — Ryzen 5, 64 GB of RAM, 2x512 GB NVMe — rents for roughly €37–57/month depending on configuration, call it ~$49 flat. That single machine holds the entire reference topology several times over: the web tier, the worker, and Postgres in containers with room for staging, monitoring, and a second app. Egress is effectively a non-issue at this scale next to the generous included traffic of a dedicated box. The monthly delta vs Railway is another ~50% off; vs Heroku, ~72%.

The honest price of that column is operations. Somebody provisions the machine, runs the Kubernetes or Cluster API fleet on it, patches the OS, backs up Postgres, rotates TLS certificates, and gets paged when the NVMe fills at 3 a.m. For a team with platform instincts, that is a weekend of automation plus occasional maintenance — and the bill never moves no matter how much egress grows or how many preview environments spin up. For a team of three with no ops appetite, it is the most expensive "cheap" option on the page, because the currency is weekends, not dollars.

That is the real meaning of the predictability split. Railway's bill is unpredictable in the small (every second meters) but bounded by actual use. Render's bill is predictable in the small (fixed instances) but unbounded on one line (egress). Owned hardware is perfectly predictable in dollars and completely unpredictable in labor — until you automate the labor, at which point it is predictable in both. Teams leaving Heroku are not choosing between cheap and expensive. They are choosing which variable they want to hold constant: the invoice, the headcount, or the pager.

Picking your kind of predictable​

If the goal is the smallest invoice next month with the least thought, Railway wins this recompute at ~$102 for the reference topology — just watch egress past a few hundred gigabytes and set the workspace limits on day one. If the goal is the Heroku-shaped workflow with the least relearning, Render at ~$151 is the honest price of familiarity, and the migration credits soften the first year. If the goal is a bill that never moves, the owned box at ~$49 flat is unbeatable on dollars and non-negotiable on ops burden.

Whichever destination you pick, do the recompute above with your own dyno formation before you commit: same topology, both rate cards, your real egress number, and the database line itemized instead of forgotten. The platforms changed; the arithmetic of web/worker/Postgres did not.

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.