Fixed vs Metered: What Render, Railway, and Fly.io Really Cost for Three Typical Workloads

Ask three teams what they pay to host the same app and you will get three different answers — not because the app differs, but because the bill has a shape. Render charges a fixed monthly price per instance whether your app is busy or idle. Railway and Fly.io meter usage by the second, so the bill breathes with traffic. As Pavel Hostim put it in his June 2026 three-way pricing comparison, the right pick depends less on the headline price and more on which shape fits how you work.

That framing is exactly right, but it leaves the question every team actually asks unanswered: for my workload, who wins — and by how much? This post puts numbers on it. We cost three workload shapes you will recognize — a steady-state web service, a bursty cron job, and an idle-mostly staging environment — on all three platforms, find where the ranking flips, and then price the fourth option: a flat-rate box you own.

The three shapes in 60 seconds​

Rates above are from Hostim's comparison and each platform's pricing page, accurate around June 2026. Exact numbers drift — Render restructured its workspace plans in April 2026 and repriced compute again in August (we priced that reprice against Hetzner separately) — but as Hostim notes, the shapes change far less than the numbers. The math below uses these rates; if a rate moved since, the flip points move with it but the logic holds.

Three workloads, four bills: where the ranking flips​

Here are the numbers: three typical workloads, each costed on Render, Railway, Fly.io, and a Hetzner CX32 (€7.85/mo, roughly $8.50, with 20 TB of included traffic). Estimates include plan fees and egress where the platform meters it.

Workload A — steady-state web service. 1 vCPU / 2 GB RAM running 24/7, ~100 GB egress a month. Your production API.

Workload B — bursty cron job. 1 vCPU / 1 GB, runs 2 hours a day (~8% of the month). Nightly reports, sync jobs.

Workload C — idle-mostly staging. 0.5 vCPU / 512 MB, actually exercised ~10% of the month.

One accounting note before the takeaways: plan fees are paid once per account, not once per workload. A team running all three workloads on Railway pays a single $5 Hobby fee with one shared $5 usage credit — combined usage is ~$44, so the real combined bill is $44 plus $5 egress, about $49, not the $55 you get from summing the rows. Render sums cleanly per instance ($32–37 for all three), and Fly.io has no plan fee so its rows add up directly ($15). The per-row numbers above still answer "what does this workload cost on its own," which is the right question when you are deciding where to put the next workload.

Three takeaways fall out of the table:

1. Metered wins low utilization, fixed wins high utilization — with a visible crossover. For the Workload A shape, Railway's bill equals Render's $25 at roughly 60% utilization; below that, metered wins, above it, fixed wins. If you can forecast utilization, you can pick the model arithmetically.
2. Fly.io wins raw compute in every row — no plan fee and the cheapest per-unit rates. The price you pay instead is configuration surface: regions, machine sizing, and autoscaling policy are yours to manage.
3. Render's free tier is the staging cheat code if you accept ~15-minute cold starts. Nobody else has a $0 row.

Why the metered bill is harder to predict (and how to bound it)​

Fixed pricing is a budgeting feature: finance can put $25 × services in a spreadsheet and be right. A metered bill moves with three things, and each needs its own guardrail:

• Traffic-driven run time. Autoscaling from one machine to five at 3 AM is the platform working as designed — and five times the compute. Bound it with a max-instance cap and an alert at 2× your expected instance-hours.
• Egress. Railway's $0.05/GB and Fly's $0.02/GB look trivial until a workload ships gigabytes daily. A staging env that mirrors production traffic can cost more in egress than compute. Alert on GB/day, not dollars/month — by the time dollars move, the traffic already happened.
• Idle-but-running services. The staging env everyone forgot, the preview deployment nobody closed. On metered platforms these are a slow leak; on Fly.io, stopping the machine cuts the bill to disk-only (~$0.15/GB/mo). A weekly "what is still running" review pays for itself.

None of this is exotic — it is the same FinOps discipline cloud teams learned on AWS a decade ago, compressed into a $5–50/mo bill. The 2026 twist is that metered billing is spreading everywhere: usage-credit pricing for AI tools has already produced infamous surprise bills (one team reportedly burned a $7,000 annual plan in a day after a vendor switched to usage credits). Every team should budget one afternoon to set caps and alerts before the first production deploy, on any metered platform.

The third option: a flat-rate box you own​

Now add up the PaaS column totals for a team running all three workloads: Render ~$32–37, Railway ~$49, Fly.io ~$15 — every month, forever, climbing with traffic. A single Hetzner CX32 at €7.85/mo runs all three workloads at once (4 vCPU / 8 GB swallows a 1-CPU API, a cron job, and a staging env with room to spare), with 20 TB of included traffic making the egress line item round to zero.

The honest caveat is operations: the PaaS bill buys deploys-from-git, managed TLS, rollbacks, and someone else's pager. On your own box, that is your evening. Flat-rate wins the cost comparison by 2–7× precisely because it unbundles the platform labor from the compute — which is why the interesting question is not "VPS or PaaS" but "can I get PaaS ergonomics on flat-rate capacity I own?"

Which shape for which team​

• You budget annually and hate variance → Render fixed instances. The bill is a constant; utilization risk is yours but capped.
• Your traffic is spiky or batch-shaped → Railway or Fly.io metered. Paying for 8% utilization beats reserving 100% — just set the caps first.
• You run multi-region or scale-to-zero → Fly.io. Per-machine per-second billing with disk-only stopped state is purpose-built for this.
• You would rather own capacity than model it → Flat-rate Hetzner plus a self-hosted PaaS layer. One predictable number, all workloads included.

The fixed-vs-metered debate is really a debate about who absorbs utilization risk: you (fixed — you pay for idle) or the meter (metered — you pay for peaks). Teams that hate surprise bills are not really asking for the cheapest row in the table. They are asking for a bill they can forecast — and that is a property of the pricing model, not the price. As metered billing spreads from compute into AI usage credits and agent run-time, the teams with caps, alerts, and a clear-eyed view of their utilization curve will be the ones whose bills stay boring.

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-rate capacity instead of a meter that moves with traffic. Star the repo on GitHub or deploy your first app today.