Every Heroku Exit Guide Crowns Its Author: What Puter's Top-5 Left Out

Puter's Top 5 Heroku Alternatives (2026) opens with a ranking: Puter at number one, then Vercel, Render, Cloudflare Pages/Workers, and Firebase. Two names are nowhere on the page — Railway and Fly.io, the two platforms most Heroku refugees actually shortlist first. And there is a sixth row no vendor-authored guide ever prices: the same workloads on a flat-rate box you own. That missing row is worth more than the ranking.

This is not a hit piece on Puter. Its guide is a competent, well-organized specimen of a genre every migrating team will read a dozen of. That is exactly why it is worth reading closely: once you see how one exit guide positions its author first, omits its closest competitors, and never mentions the self-hosted row, you can read all of them correctly — as migration data wrapped around a positioning statement.

The row no vendor prices: the same stack, five ways​

Strip the rankings and ask the only question a migrating team needs answered first: what does a typical always-on setup — one web service, one background worker, one Postgres database — cost per month on each platform? Here it is at two tiers, small and production-class, using published list prices as of mid-2026:

Three things jump out. First, Puter's guide is directionally right that Render undercuts Heroku substantially — about 45% less at the production tier here, at the edge of the guide's "50–80% less" band. At the small tier the two are effectively tied ($19 vs $20): the Render discount only opens up as you scale. Second, the metered platforms (Railway, Fly.io) win the small tier and converge toward Render as the footprint grows; usage-based pricing rewards small and punishes sprawl, which is why "typical" ranges replace exact totals in their rows. Third, the self-hosted row is 4–10× cheaper at both tiers — and it is the only row whose price includes no labor, no managed backups, and no one to page but you. More on that honesty gap below.

The variable that moves every row except Hetzner's is bandwidth and usage growth: metered bills scale with traffic, seat-based bills scale with headcount, and flat-rate hardware scales with neither until you outgrow the box. Any exit math that prices only today's footprint and not next year's traffic curve is a snapshot, not a plan.

What the guide gets right​

Credit where it is due: Puter's comparison tables hold up as migration data on the points that matter most, and each checks out against independent sources.

Heroku is in sustaining mode. The guide lists Heroku's status as "maintenance mode (Feb 2026)" in every table. Salesforce did move Heroku into sustaining engineering in February 2026 — security and stability work only, no new features, enterprise sales limited to renewals. If you are still on Heroku, you are on a platform with a frozen roadmap. That single fact does more to justify migrating than any pricing table.

Render is the most direct replacement, and the numbers check out. Git-push deploys, the web-plus-worker-plus-Postgres mental model, Blueprint specs as a better app.json — the mapping is genuinely close. The guide's two sharpest specifics also verify: Render's proxy timeout is 100 minutes against Heroku's hard 30-second router cap, and comparable resources land roughly half below Heroku list prices at the production tier. The table above confirms the discount independently.

Vercel's limits are stated fairly. The guide gives Vercel its due for Next.js integration and preview deployments, then names the real constraints: serverless-first with no always-on containers or background workers, tight timeouts (5 minutes max on Pro), and a Hobby tier restricted to non-commercial use that pushes real teams to Pro at $20 per user per month. That per-seat multiplier is the line most Vercel-curious teams miss, and the guide does not hide it.

Firebase's scaling risk is flagged, not buried. The guide warns that Blaze pay-as-you-go has no spending caps and that a read-heavy app can jump from a few dollars to thousands. For a guide that ranks Firebase in its own top five, that is an honest paragraph.

So the guide works as a reference for the five platforms it covers. The problem is the shortlist itself.

The two omissions: Railway and Fly.io​

Railway and Fly.io are, by most independent measures, the first two names on a Heroku refugee's shortlist. Both publish dedicated Heroku migration guides. Both offer the git-push workflow Heroku trained a generation to expect. Railway's Hobby plan starts at $5 a month plus usage; Fly.io's shared-CPU VMs start around $2 a month pay-as-you-go. Neither appears anywhere in Puter's top five.

This is not ignorance. Puter's own site links separate "Railway alternatives" and "Fly.io alternatives" guides in the Related section at the bottom of the page — the author knows exactly what these platforms are and chose to leave them off the Heroku shortlist. That choice is the positioning statement: a shortlist is never a neutral census of the market. It is an argument about which category the author's product wins.

Why would these two be the ones cut? Notice what the included five have in common: Vercel (frontend/serverless), Cloudflare (edge/serverless), Firebase (backend-as-a-service), and Puter itself (browser-based cloud OS with serverless workers). Render is the only traditional container PaaS on the list — and it is framed as the legacy-shaped option, the "spiritual successor" for teams that cannot let go of the old mental model. Railway and Fly.io are the two platforms that compete most directly with both framings: they run real always-on containers and feel modern. Including them would have crowded the exact middle of the market where Puter wants its own story to sit. Whether that was deliberate or instinctive, the effect is the same: the shortlist flatters the author by removing its nearest neighbors.

The practical lesson: when an exit guide omits the two defaults, read the omission as data. It tells you which competitors the author takes seriously enough to exclude.

Reading the genre: every guide's number one is its author​

Puter ranking Puter first is not a scandal — it is the genre convention. Puter's own Render alternatives guide also crowns Puter number one. Every vendor-authored "alternatives" page in this market does the same thing, because the page exists to capture "X alternatives" search traffic and convert it, not to produce a dispassionate ranking. Expecting neutrality from it is a category error.

Once you accept that, these guides become genuinely useful — as migration data, not as shortlists. The comparison tables (timeouts, deployment models, free-tier terms) are usually accurate, because false specifics are checkable and embarrassing. The ranking and the shortlist membership are the marketing. So read them with three questions:

1. Who is missing? Cross-check the shortlist against two or three rival guides. The names that appear on everyone else's list but this one are the author's real competition.
2. What is the author's category? Every guide frames its winner's category as the future and the alternatives as legacy-shaped compromises. Name the frame and it stops working on you.
3. Which row would lose the author money? No vendor guide prices the self-hosted row, the "just use a VPS" row, or the competitor it fears most. Add those rows yourself — that is the table at the top of this post.

A guide that survives those three questions is still worth bookmarking. Puter's does: its per-platform facts are solid even if its shortlist is self-serving.

The honest caveats on the cheap row​

The Hetzner row in the table above is real — a €5 cloud VM genuinely runs a small web-plus-worker-plus-Postgres stack, and a ~€50 dedicated box genuinely absorbs a production footprint that costs $70–125 on managed platforms. But the number is only half the price. The rest:

• Postgres becomes your job. Managed Postgres means automated backups, point-in-time recovery, failover, and version upgrades. Self-managed means you configure all of that, test restores, and own the 3 a.m. page when the primary stops replicating. Budget the tooling (or the managed-database add-on, which narrows the gap).
• The platform engineering is yours too. Deploys, TLS, private networking, log aggregation, autoscaling policy — Render and Heroku ship these; on your own box you assemble them from open-source parts and maintain the assembly.
• There is no free tier that sleeps. Managed platforms let a side project idle near zero. A flat-rate box bills the same whether it serves one request or one million, which makes it the cheapest option for always-on workloads and a wasteful one for experiments.

None of that erases a 4–10× cost gap, but it converts "cheaper" into "cheaper if you staff it." Teams that already run infrastructure — or that want an open-source PaaS that runs the assembly for them on their own machines — capture the gap. Teams with no ops capacity may rationally pay Render's markup, which is, after all, still half of Heroku's.

Use exit guides as data, not shortlists​

Heroku's sustaining mode makes this exercise timely rather than theoretical: every team still on the platform is now on a frozen roadmap, and the exit guides are competing to define where they land. Let them compete. Take Puter's timeout tables, Render's migration guide, Railway's and Fly.io's Heroku playbooks, and the self-hosted row above; combine them into your own shortlist; and price your actual footprint at your actual traffic curve instead of anyone's ranking.

The genre will keep crowning its authors. That is fine — once you know the convention, you can enjoy the data and ignore the crown.

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.