Dora NodaHeroku is in sustaining engineering, Render restructured its workspace plans in April, Railway shipped high-availability Postgres, and Fly.io started billing for lines that used to ride along free. Every 2026 PaaS comparison converges on the same split verdict — Render for simplicity, Railway for deploy speed, Fly.io for edge — but none of them tells you which verdict describes your team. This post does that: four workload shapes, four verdicts, the 2026 pricing change behind each one, and the fourth option the roundups never price.
Here is the whole framework up front. The rest of the post is the evidence.
| Your shape | Verdict | Why it wins for you | 2026 move that matters |
|---|---|---|---|
| Small team, standard web app, wants "Heroku that works" | Render | Fixed per-service pricing, managed Postgres/Redis, zero Docker required | April workspace-plan restructure |
| Solo dev or tiny team iterating daily, many preview envs | Railway | Fastest git-push-to-live, per-second billing, unlimited seats on paid plans | HA Postgres (March, experimental) |
| Latency-sensitive app serving users on multiple continents | Fly.io | Machines in 30+ regions, per-second VM billing, full Docker control | Unbundled billing: snapshots + egress IPs now metered |
| Many small services, predictable load, cost-sensitive | Self-hosted | One flat hardware invoice regardless of service count | Hetzner June CCX hike narrows but doesn't close the gap |
If your shape isn't in the table, the decision checklist near the end will place you. If it is, skip to your section — but read the "where each verdict flips" notes, because every one of these wins has a boundary.
The 2026 moves that changed the verdicts
Four platform changes this year moved real teams' decisions. Everything below assumes them.
Heroku went into sustaining engineering. In early 2026 Heroku announced no new features and no new enterprise contracts, which turned "should we leave Heroku" from a roadmap question into a migration deadline for thousands of teams. That exodus is the reason every 2026 comparison is really a "where next" guide, and it set the bar the other three are judged against: whoever feels most like Heroku used to wins the refugees.
Render restructured workspace and team plans on April 23, 2026. Render now charges for three things: a flat workspace-plan subscription, metered features like bandwidth, and per-service compute prorated to the second. The restructure mostly hit teams rather than solo developers — if you priced Render off a 2025 comparison, the team line of your estimate is stale. The underlying pitch didn't change: fixed instance prices per service, managed Postgres, Key Value, and cron, no Docker knowledge required.
Railway shipped experimental HA Postgres in March 2026 and kept unlimited seats on paid plans. The HA Postgres launch attacks Railway's longest-running objection — that its databases weren't serious enough for production — while per-second usage billing plus unlimited seats keeps it the cheapest way to give a whole team deploy access. The "experimental" label matters: teams with strict data durability requirements should read it as a roadmap signal, not a checkbox.
Fly.io unbundled. Volume snapshot billing ($0.08 per GB-month, first 10 GB free) started charging early this year, and app-scoped static egress IPs began billing January 1 at $0.005 per hour. Neither line is large on its own; together they signal Fly.io's 2026 strategy of metering what used to ride along free. Fly.io also replaced its old named tiers with pure pay-as-you-go Machines billing — every VM bills per second, which rewards spiky and scale-to-zero workloads and punishes nobody in particular, as long as you can predict your bill.
Render: the simplicity verdict
Render wins teams that want traditional-PaaS simplicity: push a repo, get HTTPS, attach Postgres, go home. Fixed per-service instance pricing means the bill is knowable before deploy day, which is exactly what a team migrating off Heroku's dyno model wants to hear. Managed Postgres, Key Value (Redis-compatible), cron jobs, and preview environments cover the standard web-app surface without a Dockerfile anywhere.
The team profile this describes is concrete: two to ten engineers, one production app plus a staging copy, traffic that is spiky by the hour but predictable by the month, and nobody who wants to own infrastructure. For that team, Render's April restructure is a budgeting detail, not a dealbreaker — the workspace subscription is flat and the per-service compute is fixed, so the invoice still has no surprises.
Where the verdict flips: service count. Render prices per service, so a team running fifteen microservices pays fifteen instance lines before serving a single request. At that shape, per-second billing (Railway, Fly.io) or a flat hardware invoice (self-hosted) starts winning on arithmetic alone. Render also keeps you in its regions — if your users span continents and latency is a feature, read the Fly.io section instead.
Railway: the iteration-speed verdict
Railway wins the fastest time from git push to live URL, and in 2026 it pairs that with the most generous team economics: unlimited seats on paid plans mean adding your fifth engineer costs nothing extra. Per-second usage billing makes preview environments nearly free — spin up twenty for a launch day, delete them after, pay for hours not months. For a solo developer or a tiny team deploying multiple times a day, nobody else is close on pure iteration economics.
The March 2026 experimental HA Postgres launch is the one to watch. Railway's historical knock was always the database story: fine for side projects, questionable as the system of record. HA Postgres doesn't fully close that objection while it carries an experimental label, but it changes the trajectory — teams evaluating Railway for production in late 2026 are betting the label comes off, and the bet looks reasonable.
Where the verdict flips: sustained scale. Per-second billing is kind to spiky workloads and honest with steady ones — a service running 24/7 at high utilization pays for every second of it, and at some point a fixed instance (Render) or owned hardware (self-hosted) undercuts the meter. Railway also keeps the platform surface intentionally narrow: if you need multi-region deployment or Docker-level control, you're shopping at Fly.io.
Fly.io: the edge verdict
Fly.io wins genuinely geo-distributed apps, full stop. Machines deploy to 30+ regions with per-second billing, scale-to-zero, and full Docker control — the combination nobody else offers. A latency-sensitive API serving users in São Paulo, Berlin, and Tokyo from one codebase with region-local execution is a workload shape only Fly.io serves natively at PaaS simplicity.
That power comes with the steepest learning curve of the three. Fly.io's pricing is pure usage — shared-CPU VMs from roughly $2 per month at the smallest size, plus volumes, plus the newly metered snapshots and egress IPs — and the bill moves with traffic in ways fixed-instance shoppers find hard to predict. There is a pricing calculator for a reason. Teams that thrive on Fly.io treat the bill as an engineering metric: watch it, alert on it, optimize against it.
Where the verdict flips: single-region simplicity. If all your users are in one geography and you don't need Docker-level control, you're paying Fly.io's complexity tax for edge capacity you never use. A standard web app on Fly.io works fine — it's just more platform than the workload needs, and the unbundled 2026 billing lines (snapshots, egress IPs) add invoice lines a Render team never sees.
The fourth option: the same workload on owned hardware
The roundups never price the fourth option, so let's do it here. Take the reference workload the comparisons keep circling: a standard web app with Postgres, Redis, a worker, and a staging copy — four to six containers, steady traffic, one region.
On owned Hetzner hardware under Cluster API, that workload fits comfortably on a single dedicated box. An AX42-class machine (8-core Ryzen, 64 GB RAM, NVMe) runs roughly €57–97 per month depending on configuration, and it doesn't care whether you run four services or forty — the invoice is flat while the PaaS invoices scale with service count. That flatness is the entire economic argument: "many small services, one flat invoice" is a shape where per-service and per-second pricing both lose.
Honesty requires the 2026 caveat: Hetzner raised cloud prices steeply in June 2026, with the dedicated-vCPU CCX line roughly doubling (the CCX13 went from €15.99 to €42.99 per month). Dedicated servers moved less, but the era of assuming Hetzner prices only drift downward is over — recheck the price list before you budget. Even after the hike, though, the arithmetic for the reference workload holds: one flat hardware invoice against three metered ones, with the gap widening as service count grows.
The cost of the fourth option isn't money, it's operations. Somebody owns the machines, the Kubernetes upgrades, the Postgres backups, the 3 a.m. pages. For a team with platform-engineering capacity — or a team standardizing on Cluster API so machine lifecycle is declarative rather than artisanal — that's a fixed cost amortized across every service. For a team of three with no ops appetite, it's a second job. Price the labor honestly and the fourth option usually still wins past a handful of services; pretend the labor is free and you'll win the spreadsheet and lose the quarter.
The decision checklist: five questions
If the table at the top didn't place you, answer these in order. The first "yes" is your answer.
- Do your users span continents with latency requirements? Yes → Fly.io. Nobody else does multi-region at PaaS simplicity.
- Do you run (or plan to run) more than ~8 services with steady traffic? Yes → self-hosted. Per-service and per-second pricing both scale against you past this point; a flat hardware invoice doesn't.
- Do you deploy multiple times a day with heavy preview-environment use? Yes → Railway. Per-second billing plus unlimited seats is built exactly for this.
- Do you want managed Postgres, fixed pricing, and zero Docker? Yes → Render. The Heroku-successor slot, deliberately.
- None of the above? You're early enough that any of the three works — pick by team taste, keep the app portable (12-factor, standard Postgres), and revisit when one of the first four questions flips to yes.
Two meta-rules sit above the checklist. First, revisit on pricing changes, not anniversaries: the 2026 moves above each flipped somebody's verdict mid-year, and the next restructure will flip somebody else's. Second, keep the exit cheap regardless of your pick: standard Postgres, containers you can run anywhere, infrastructure described as code. The teams hurt most by Heroku's sustaining-engineering announcement weren't the ones on Heroku — they were the ones whose Heroku dependence had no migration path.
What the verdicts agree on
Step back and the split verdict is really a consensus wearing a trench coat. Every 2026 comparison agrees that the Heroku era's single default is gone, that per-second billing won for spiky workloads and fixed pricing won for predictable ones, that managed Postgres is table stakes, and that multi-region belongs to Fly.io uncontested. The disagreement is only about which team each platform describes — which is why a decision framework beats a price table. Prices change every April; workload shapes change every funding round.
When your shape points at the fourth option — many small services, one flat invoice — Bex.co is the open-source, AI-native Render alternative that runs it on machines you own: push a git repo, get a running HTTPS service, with a Render-compatible API your existing tooling already speaks. Star the repo on GitHub or deploy your first app today.
