Usage-based pricing: paying for what a service actually consumes
Cloud Computing's own pricing-models lesson covered the general spectrum — fixed capacity vs. pay-as-you-go. Railway sits deliberately and consistently at the pay-as-you-go end, for every resource, and understanding exactly what's metered is the difference between a predictable bill and a surprising one.
Intermediate
2 min read
What's actually metered, continuously, not in fixed tiers
CPU: metered by actual vCPU-seconds consumed
Memory: metered by actual GB-seconds allocated and used
Egress: metered by actual bandwidth served out of Railway's network
Unlike a platform selling fixed-size plans ("the $20/month tier gives you 2 vCPUs and 4GB RAM, whether you use them or not"), Railway bills for the actual compute and memory a service consumes while it's running, down to the second — a service that's idle most of the day but briefly spikes genuinely only pays for the spike, not for provisioned-but-unused capacity sitting there the rest of the time.
The real trade-off this model accepts: less predictable, potentially cheaper
A consistently low-traffic service (a small internal tool, a side project) genuinely costs less under metered billing than it would under a fixed minimum tier sized for peak load that mostly never arrives — this is the model's real upside. The trade-off: a sudden, unexpected traffic spike (or a runaway process consuming CPU in an infinite loop — a real, concrete risk a badly-written background worker can trigger) translates directly into a correspondingly larger bill, with no fixed ceiling the way a capped plan would provide, unless usage limits/alerts are configured deliberately.
Why this model fits Railway's own "deploy anything" design particularly well
A background worker that's mostly idle, waking up briefly to process a queued job (this curriculum's own Message Queues domain covers exactly this shape of workload), is expensive to run well under a fixed-capacity plan sized for its rare busy moments — and cheap, naturally, under metered billing that only charges for the brief moments it's actually doing work. This is a real, structural fit between Railway's pricing model and the kind of varied, multi-service workloads (a worker, a cron job, a low-traffic API) the platform is actually designed to host side by side.
Setting spending limits, deliberately
Dashboard → Usage → Set a monthly spending limit
Because metered billing has no inherent ceiling, Railway lets a team set an explicit spending limit — once usage approaches or hits it, Railway can pause services rather than let a bill grow unbounded, a deliberate, configured safety net rather than something that happens automatically without being set up. Forgetting to configure this, then deploying something that unexpectedly consumes far more compute than planned (a bug causing an infinite retry loop, say) is the realistic version of the risk this pricing model's flexibility trades for.