Usage-based vs capacity billing

The short answer

Usage based pricing bills what a running app consumes, so the invoice follows traffic and whatever stays busy. Capacity based pricing bills the size you configured for the hours that service runs, including the hours it sits quiet.

Neither model is the better price. They are two bets. The rates below were read on October 28, 2026 from Railway pricing and Unbroker pricing. Plan limits and two other worked examples stay on Railway pricing explained. This post does not repeat that page.

Two ways a platform turns CPU and memory into a bill

How CPU is billed on a PaaS is the whole difference. One meter watches consumption. The other watches the size you reserved.

Usage-based

Per-second billing meters the CPU, memory, and disk a service actually uses, for the seconds it uses them. Railway’s pricing page says billing is always per second, so a stopped service costs nothing for those resources.

Capacity-based

Configured capacity billing charges the vCPU and memory you set, for each hour a replica of that shape is running. On Unbroker a short utilization spike does not change that line if the configuration and the replica count stay the same.

Flat-price machines

A Linux cloud server is a third model: one monthly price for the virtual machine, not an hourly CPU line. The S size is $17.95 for 4 vCPU, 8 GB of RAM, and 100 GB of SSD, with unlimited traffic under fair use. It is a monthly contract. Cancelling schedules the stop at the end of the month you have paid for. The rest of the sizes, and what you operate yourself, are on Linux cloud servers and VPS vs PaaS.

Why usage-based bills grow even when nothing changed

If you are asking why a PaaS bill is high while the product looks the same, the usage meter moved. The sticker price did not have to.

Traffic and spikes

A usage meter adds CPU and memory for the seconds the process is actually busy. A busier hour costs more than a quiet hour of the same service. A capacity meter ignores that swing and keeps charging the configured size.

Background work that never stops

A worker, a cron job, or a process that holds memory still counts as consumption while it runs. On a per-second meter that time is on the bill even when no user is there. Stopping the service is what drops the compute charge to nothing, on Railway’s wording.

Replicas and autoscaling

Every running copy is another meter. On Unbroker, autoscaling bills the replicas that are actually running between your minimum and maximum. Adding a replica adds its configured CPU and memory for the hours it runs. Leaving the replica count alone leaves the CPU and memory line alone.

Egress and storage

Outgoing transfer and disk keep their own meters, separate from CPU. Railway lists egress at $0.05 per GB. Unbroker lists $0.05 per outbound GB after 100 GB on Pro, and inbound and private-network transfer are free. Railway volumes are $0.00000006 per GB-second, with a monthly constant of $0.15 per GB. Unbroker storage is $0.20 per provisioned decimal GB-month. This post does not invent a traffic total on top of those rates. Railway vs Render is a different comparison and is not restated here.

Real public rates, side by side

These are units, not invoices. A row does not say what you will pay. Railway’s monthly column is the constant its pricing page publishes for a resource held at full use across the billing month. The charge is still per second.

Resource	Railway, usage	Unbroker, configured capacity
CPU	$0.00000772 per vCPU-second. Monthly constant $20 per vCPU.	$0.03 per configured vCPU-hour while the service runs.
Memory	$0.00000386 per GB-second. Monthly constant $10 per GB.	$0.015 per configured GiB-hour while the service runs.
Disk	$0.00000006 per GB-second. Monthly constant $0.15 per GB.	$0.20 per provisioned decimal GB-month.
Egress	$0.05 per GB.	$0.05 per GB after 100 GB on Pro.

Read October 28, 2026. Railway’s sandbox and VM rates are a different product and are left on Railway’s pricing page. The three examples below use CPU and memory only. They exclude disk, egress, builds, tax, and every other service on the account.

Worked examples with explicit assumptions

Each example is one service, 0.5 vCPU and 0.5 GiB, over a 720-hour month (30 days, 2,592,000 seconds). Railway bills memory in decimal GB. 0.5 GiB is 0.536870912 GB, using 1 GiB = 1,073,741,824 bytes and 1 GB = 1,000,000,000 bytes. That is the conversion behind the pricing page’s note that a 10 GiB volume is 10.74 decimal GB. Dollar lines are the exact product rounded to the nearest cent.

A small always-on API

Assume the service runs all 720 hours and uses 100% of that 0.5 vCPU and 0.5 GiB the whole time.

Railway CPU is 0.5 × 2,592,000 × $0.00000772 = $10.00512, which is $10.01. Railway memory is 0.536870912 × 2,592,000 × $0.00000386 = $5.37146, which is $5.37. Usage is $15.38.

Unbroker CPU is 0.5 × 720 × $0.03 = $10.80. Unbroker memory is 0.5 × 720 × $0.015 = $5.40. Usage is $16.20. Those two lines are the same compute lines as the example on the pricing page.

If this $15.38 were the only Hobby usage, it is over the $5 included credit, so Railway’s pricing FAQ says you are charged the usage total. If this $16.20 were the only Pro usage, it is under the $25 credit, so the invoice stays $25 before tax. The usage lines are not the invoices.

A service idle most of the day

Same size, still running all 720 hours, but average use is 10% of the 0.5 vCPU and 10% of the 0.5 GiB. Nothing is stopped.

Railway then bills 10% of the always-on consumption: $1.00 of CPU and $0.54 of memory, $1.54 of usage. Unbroker still bills the configured size, $16.20, because the service stayed up. The percent you assume is the whole difference.

If that $1.54 were the only Hobby usage, it is under $5, so there is no extra usage charge. The Hobby subscription is still $5. On Unbroker Pro the $16.20 stays under the credit, so the invoice stays $25 before tax. A confirmed pause or a delete stops Unbroker’s interval. Railway’s stopped service drops the compute charge to nothing.

A service with a daily spike

Same size, running all month. For 22 hours a day use is 10% of that size, and for 2 hours a day it is 100%. Across 30 days that is 660 quiet hours and 60 busy hours.

Railway CPU is 0.5 × (660 × 0.10 + 60) × 3,600 × $0.00000772 = $1.75. Railway memory, with the GiB-to-GB conversion, is $0.94. Usage is $2.69.

Unbroker, with one replica the whole month, is still $16.20. The spike does not show up in CPU or memory. If a second replica of the same size runs only during those 60 hours, add 0.5 × 60 × $0.03 = $0.90 and 0.5 × 60 × $0.015 = $0.45, which is $1.35. Usage becomes $17.55. That second total is a different assumption, not a correction of the first.

Plan fees and included credit

The plan fee and the credit are not a second copy of the usage rates. On the pages read October 28, 2026, Hobby is $5 per month with $5 of included usage, and Railway Pro is $20 per workspace per month with $20 of included usage. Included usage resets each cycle and does not accumulate. If Hobby usage is $5 or less, Railway says you are not charged extra for usage. If Hobby usage exceeds $5, Railway says you are charged the usage total. For Railway Pro, the pricing page says usage beyond the included credit is billed at the usage rates. It does not repeat the Hobby sentence about charging the usage total.

Unbroker Pro is $25 per month with $25 of usage credit. Credits reset each cycle and do not roll over. If usage is under the credit, the invoice stays $25 before tax. If usage is higher, only the difference is added. The pricing page’s own always-on sketch is 0.5 vCPU × 720 hours = $10.80, 0.5 GiB × 720 hours = $5.40, a 10 GiB volume at $2.15, and 100 build minutes at $0.50. Eligible usage is $18.85, the credit covers it, and the estimated invoice is $25.00. The same page says $38 of usage would leave $13 of overage and an invoice of $38. Build time on that page is $0.005 per execution minute. Transfer, managed infrastructure, and tax are outside the sketch.

Which model fits which app

Pick the meter that matches how the app spends its time. Do not pick it because a single example came out lower.

Usage-based fits when

The process is idle, or stopped, for much of the month, and you accept that a busy stretch raises the bill. Predictable cloud pricing is harder here, because the invoice waits on what the process actually did.

Capacity-based fits when

The service stays up, and you would rather write the CPU and memory line before deploy than watch a utilization chart. You pay for the reserved size even when use is well under 100%.

A flat server fits when

You want one monthly machine price and you are willing to operate the OS. That is the Linux cloud server, not a third way of metering the same app platform.

How to keep any PaaS bill predictable

Write the line before the first deploy, then notice when a second copy starts running. The list is a checklist, not a promise about next month’s invoice.

1. Write the vCPU, memory, replica count, and expected running hours.
2. Multiply by the published rate for that meter. State the utilization percent if the meter is per second.
3. Set a maximum replica count and treat each extra replica as its own line.
4. Shut down previews you are not using. Each one is another running copy.
5. Keep egress and disk on their own lines. Do not fold them into the CPU estimate.
6. Pause or stop a service that should not run overnight, if the platform lets you.
7. Remember the plan fee. Usage under the included credit does not make the subscription $0.
8. Turn on a spend alert where the platform has one. This post does not describe a specific alert product.

FAQ

What is the difference between usage-based and capacity-based pricing?

Usage based pricing bills the CPU and memory a running service actually consumes. Capacity based pricing bills the size you configured for the hours that service runs. Neither one is the whole invoice: the plan fee and included credit still apply.

Why is my PaaS bill higher than last month?

On a usage meter the bill follows consumption, so traffic, a process that stayed busy, an extra replica, egress, or disk can raise it while the product looks the same. On a capacity meter the CPU and memory line stays put unless the configuration or the running time changed.

Does a PaaS charge me when my app is idle?

It depends which meter is running, and whether the process is still up. Railway says a stopped service costs nothing for CPU, memory, and disk, and a running service is still billed per second for what it uses. On Unbroker Pro, an app does not sleep from inactivity, so configured CPU and memory keep accruing until you pause or delete it.

Is per-second billing a lower bill?

Only at low utilization, and only on the usage line. The examples below hold the size fixed and change the percent of that size that is actually used. A plan fee can still be due when usage is under the included credit.

How do I estimate my monthly cost before deploying?

Write the vCPU, the memory, the replica count, and the hours the service will run, then multiply by the published rate. The Unbroker pricing example does that for 0.5 vCPU and 0.5 GiB over 720 hours.

How does replica autoscaling affect the bill?

You pay for the replicas that are actually running, between the minimum and the maximum you set. A utilization spike does not change the CPU or memory line while the configuration and the replica count stay the same.

What does configured capacity mean on Unbroker?

It is the vCPU, memory, and replica count you set. Billing follows that shape while the service runs, not a moment-to-moment utilization reading. Storage follows the size you provision.