Railway's Per-Second Meter vs Render's Flat Workspace Fee: What a Bursty Side Project Actually Costs in 2026

Two platforms, two opposite answers to the same question: what should idle cost? Railway's answer is almost nothing, metered by the second — Hobby starts at $5 a month including $5 of usage, and every vCPU-second and gigabyte-hour ticks against that credit. Render's answer, since its April 2026 repricing, is a flat workspace fee plus fixed per-service prices — Hobby $0, Pro $25 a month, Scale $499 a month, with compute sold as fixed-size instances on top.

So which one wins for your bursty side project? Here is the verdict up front, with the receipts below:

Read the table carefully, because the headline is a split decision with a twist. Render wins the bursty case on price — free is hard to beat. Railway wins on honesty of scaling: its bill grows smoothly with use instead of jumping in $7-per-service steps the moment you outgrow free-tier limits. And both of them lose to a flat box the moment egress or steady utilization enters the picture. The rest of this post is the line-by-line math behind each cell, the crossover point where the winner flips, and the one line item neither PaaS can make disappear.

How Railway's meter actually works​

Railway's Hobby plan costs $5 a month and includes $5 of usage credit — your first $5 of compute is, in effect, prepaid. Beyond that, everything is metered per second of actual use at published rates: roughly $20 per vCPU-month of CPU, $10 per GB-month of RAM, $0.15 per GB-month of volume storage, and around $0.05–$0.10 per GB of egress (Railway's own VPS comparison confirms the $20/$10 headline rates and per-second billing).

That "$0.000463 per vCPU-second" figure floating around teardowns is really the per-minute rate ($20 divided by ~43,200 minutes in a month); per second it is closer to $0.0000077. The unit matters less than the shape: you pay for what you burn, and only while you burn it. Spin up three replicas for a traffic spike and you pay triple for exactly the minutes the spike lasts, then the meter falls back to baseline.

The feature that makes this shape work for side projects is serverless sleep. When a service sees no outbound requests for about 10 minutes, Railway puts it to sleep, and a sleeping service costs nothing until the next request wakes it (Railway's Render comparison). This is the mechanism that lets an idle-most-of-the-time project live inside its $5 credit: a 0.5-vCPU, 512 MB service would cost about $15 a month running flat out ($10 of CPU + $5 of RAM), but at 4–5% active time it burns well under a dollar, and the $5 Hobby floor is the whole bill.

Two caveats before you celebrate. First, the $5 floor is a floor: even a project that burns $0.30 of compute pays $5. Second, sleep means cold starts — the next request after an idle stretch waits for the service to wake. For a personal dashboard or a bot you poke twice a day, that is invisible. For anything with latency expectations, it is the real price of the meter.

How Render's new model works​

Render's April 23, 2026 repricing replaced per-seat billing (Professional at $19/member/month, Organization at $29) with flat workspace fees: Hobby $0, Pro $25/month, Scale $499/month, all with unlimited team members, with legacy workspaces force-migrated on August 1, 2026. Render says 75% of paying customers saw costs stay flat or fall — which tells you who the repricing was for: teams, not side projects.

The critical thing to understand is what the flat fee does not cover. It buys workspace features — bandwidth allowance, build minutes, previews, autoscaling on Pro and above — not compute. Compute is still fixed-price per service: a Starter web service runs about $7 a month (0.5 CPU, 512 MB), Postgres Basic starts around $6 a month, and each service is its own fixed line item whether it serves a million requests or twelve.

The workspace fee wraps three metered allowances around that fixed compute: included bandwidth (5 GB on Hobby, 25 GB on Pro, 1 TB on Scale, then $0.15/GB overage), build pipeline minutes (500/1,000/5,000, then $5 per 1,000), and preview environments (single-service on Hobby, full-stack on Pro).

For the free tier specifically: 750 instance-hours a month shared across the workspace (spun-down time doesn't count), with free web services sleeping after 15 minutes without inbound traffic and taking 30–60 seconds to wake.

So Render's shape is the mirror image of Railway's: instead of one smooth meter, you get fixed per-service steps plus two overage meters (bandwidth, build minutes) that only bite once you exceed the included allowance. Predictable — until it isn't.

The worked comparison: two profiles, real totals​

Assumptions, stated plainly so you can check my arithmetic: Railway at $20/vCPU-month CPU + $10/GB-month RAM with the $5 Hobby credit applied; Render at $7/mo Starter services, ~$6/mo basic Postgres, Hobby $0 / Pro $25 workspace fees, $0.15/GB egress overage; sleep behavior as documented above (Railway ~10-minute idle sleep, Render free 15-minute sleep with 30–60s wake).

Profile A: the bursty side project. One web service (0.5 vCPU, 512 MB), actively serving about an hour a day — roughly 4% utilization — asleep the rest of the time, a couple of GB of egress.

• Railway: $15/mo of always-on-equivalent compute × 4% ≈ $0.60 of real burn, comfortably inside the $5 credit. Bill: $5.
• Render: Hobby workspace ($0) + free web service, asleep ~23 hours a day, spun-down hours not counting against the 750-hour pool. Bill: $0.

Render wins Profile A on price, full stop — with two asterisks. Add a background worker and the free tier stops covering you: Render has no free worker tier, so that always-idle cron job is a $7/mo Starter the moment you add it, while on Railway the same idle worker burns pennies inside your existing $5 credit. And both bills assume you tolerate sleep; keeping the service permanently warm costs Railway ~$10 after credit versus Render's $7 Starter — nearly a wash.

Profile B: steady production. API (0.5 vCPU/512 MB) + worker + Postgres, running 24/7, ~100 GB monthly egress.

• Railway: API $15 + worker $15 + Postgres ~$15.75 (compute plus a few GB of volume) + ~100 GB egress at ~$0.05–0.10/GB ($5–10) ≈ $51–56 gross, minus the $5 credit. Bill: ~$46–51/mo, rising linearly with every extra vCPU and gigabyte of egress.
• Render Hobby: $7 + $7 + $6 = $20 of fixed compute, plus (100 − 5) GB × $0.15 = $14.25 of bandwidth overage. Bill: ~$34/mo — but no autoscaling and single-service previews.
• Render Pro: $20 compute + $25 workspace fee + (100 − 25) GB × $0.15 = $11.25 overage. Bill: ~$56/mo, with autoscaling and full-stack previews.

Now the sensitivity analysis, because single-point comparisons lie by omission. The ranking flips on two variables:

1. Utilization. Below ~10% active time, Railway's burn hides inside the $5 credit while Render's free tier charges $0 — Render leads. Past ~30% utilization on multiple services, Railway's meter climbs past $10–15 while Render's fixed $7-per-service steps hold flat — Render leads again, differently.

   Railway's sweet spot is the middle: spiky workloads that would force Render users onto paid tiers for headroom (autoscaling needs Pro at $25) but average out cheap on a per-second meter.

2. Egress. This is the lever that breaks both PaaS bills. At 500 GB/mo of egress, Render's overage alone is ~(500 − 5) × $0.15 ≈ $74 on Hobby; Railway's is ~$25–50; both dwarf the compute. Anyone serving images, video, or large downloads hits this wall first, and no workspace fee or usage credit softens it.

What both models still meter that a flat box never does​

Price the same Profile B on a single Hetzner CX22 — 2 vCPUs, 4 GB RAM, 40 GB disk, 20 TB of included traffic for roughly €4 a month — and the whole topology (API, worker, Postgres, 100 GB of egress) fits in ~$5/mo flat. Not $34, not $48. Five dollars, and the 500 GB egress scenario that costs Render $74 in overage alone still costs $5.

This is the deeper point beneath the price war: both billing shapes, for all their differences, still meter something a flat-rate box never has to. Railway meters every second and every gigabyte; Render meters bandwidth and build minutes around fixed service fees. Neither meter exists on owned hardware, where idle costs nothing extra — it is already paid for — and egress up to 20 TB is included in the sticker price.

The honest counter-argument: the box doesn't patch itself, scale itself, or wake you up at 3 AM — you operate it. That operations cost is real, and for a side project it usually exceeds any hosting bill. The PaaS premium buys freedom from ops, and for many teams that is money well spent. But notice what the premium is proportional to: on Railway it scales with your success (more usage, more bill), on Render it scales with your architecture (more services and bandwidth, more bill), while the box stays flat through both. That is why the migration stories all rhyme — teams leave when the meter starts taxing growth rather than idleness.

Which workload belongs where​

If your side project sleeps all day and you can live with a 30–60-second wake-up: Render's free tier at $0 is the cheapest hosting in existence that still counts as hosting. If your project has a worker, bursts unpredictably, or you want one bill that bends instead of stepping: Railway's $5 floor plus per-second meter is the most forgiving shape.

If your app is steady, multi-service, and pushing real egress: add up the overage lines before you commit to either — and price the flat box, because somewhere around hundreds of GB of transfer or 24/7 multi-service operation, the box wins by 5–10x and the only remaining question is who does the ops.

That last question is the one worth answering deliberately rather than drifting into. Run the numbers for your utilization and your egress, pick the shape whose bill stays boring as you grow, and revisit the decision when the meter starts being the most interesting line in your budget.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with flat hardware economics instead of per-second or per-service meters. Star the repo on GitHub or deploy your first app today.