Skip to main content

Usage-Based Pricing: Why Your Railway and Render Bills Creep Up

· 5 min read

Usage-based pricing always looks cheap on the signup page. "Pay only for what you use." "Starts at $5." Then a few months in, your bill is double what you guessed, and you can't really point at the one thing that did it.

I've been comparing platforms a lot lately – partly because I run one, partly because people keep emailing me to ask whether X or Y is cheaper than Hostim. So here's the actual math on why metered hosting drifts upward over time, and the honest version of when it's the better deal anyway.


What "usage-based" actually means

You're not paying for a plan. You're paying for resources, counted in tiny units – CPU per minute, memory per gigabyte-minute, traffic per gigabyte that leaves the building, and sometimes requests and build minutes on top of that.

Railway is the clearest example. They raised a $100M Series B in January 2026 and the whole pitch is built around this model. The Hobby plan says "$5/month", but that $5 is a credit you spend, not a ceiling. A normal app that stays on all month spends it and keeps going.


The math behind the creep

Take one small service that's always on: 1 vCPU, 1 GB of RAM, running 24/7.

At Railway's list rates (roughly $0.000463 per vCPU-minute and $0.000231 per GB-minute), a full month of uptime works out to:

  • vCPU: about $20
  • RAM: about $10
  • ~$30/month – and that's before any traffic, before a database, before a second copy of the app.

So the "$5" service is really a ~$30 service the moment it has to stay up. Then you add the normal stuff: a worker or a cron app, a managed Postgres billed the same way, one week where a crawler hammers your endpoints and the egress line jumps. None of those are price increases. The rate card never moved. You just used more, and with metering, using more is the same thing as paying more. Nobody really plans for that at signup.


Why platforms do this

Two reasons, and both are reasonable. One, it matches their own cost – the cloud underneath bills them per second, so they bill you per second and pass the risk down. Two, it grows on its own: when your app does well they make more money without selling you anything new, and investors like revenue that climbs by itself. A company that just raised $100M needs exactly that kind of number.

I don't think anyone's being evil here. The incentive just points at a bigger bill, not a flat one.


When usage-based is actually the right call

I run a flat-price PaaS, so obviously I have a horse in this race. But metered billing genuinely wins in a few cases:

  • Spiky traffic that's idle most of the day. Scale-to-zero means you pay almost nothing while it sleeps.
  • Throwaway environments – preview deploys, CI, a demo that lives for an hour.
  • Early prototypes with no real traffic yet, where the free credit might cover the whole thing.

If that's your situation, metered is probably cheaper than anything I'd sell you. Use it.

And to be fair, not everyone is even moving toward more metering. Render just dropped its per-seat fees for flat team plans – predictable as you add people, though the compute itself is still metered. So it's not some industry-wide conspiracy. It's mixed.


When a flat plan wins

Flat pricing wins when your app is on all the time and fairly steady, which honestly describes most things in production:

  • a backend API that has to answer around the clock
  • a database that can't scale to zero
  • a SaaS with traffic that grows slowly and predictably

For those, metering just charges you for being available. A flat plan costs the same whether you serve ten requests or ten thousand, so you can actually guess next month's bill before it shows up.


What I do instead

Hostim.dev runs on bare metal in Germany and charges a flat price per app, from €2.50/month. Databases (Postgres, MySQL, Redis), volumes, HTTPS, logs and metrics are all in the price. No vCPU-minutes, no egress meter, no surprise at the end of the month.

If you're comparing right now:

The point isn't "usage-based is bad." It's that most people running a real backend sit on the steady, always-on side and pay as if they're on the spiky side. Pick the model that matches what your app actually does.


👉 Paste a Compose file and see your flat price – no signup, no card.