Railway Prices Compute in Scientific Notation: What $0.000463 per vCPU-Second Actually Costs a Month

Railway's pricing page lists CPU at $0.000463 per vCPU-minute and memory at $0.000231 per GB-minute. You can do the multiplication — $0.000463 × 43,200 minutes in a 30-day month is $20. But the fact that you have to is the point.

Seven decimal places, two time units hiding in one line item, and a Hobby plan that bundles a $5 credit so your first small service looks free until month two: this is the most transparent-looking rate card that still leaves most developers unable to answer whether one always-on service costs $15 or $80 next month.

Here is the answer in the units humans actually budget in, the table that should have been on the pricing page, and why unit-of-measure illegibility is a different forecasting tax than the hidden-line-item problem eating Fly.io and Render bills.

The one-line decode, up front. At 100% duty cycle — an always-on service that never sleeps — Railway Hobby costs $20 per vCPU per month plus $10 per GB of RAM per month, billed per second and displayed rounded to the minute. A 1 vCPU / 1 GB API is therefore about $30/month before the $5 Hobby credit, $25 after credit, and $360/year if it stays up. Two vCPUs and 4 GB — a modest Postgres — is about $80/month. Misread $0.000463 as per-second instead of per-minute, the exact slip the original TODO title invites, and you get $1,200/month — 60× too high. That 60× error is not a contrived typo. It is the cost of pricing compute in scientific notation.

The rate card, translated (and why the units are the story)​

Railway documents one consumption rate two ways. The pricing page quotes per-minute figures because they yield round monthly numbers; the platform meters per second and rounds the display to the nearest minute. Both are true — divide or multiply by 60 — but the per-minute display is where most developers first meet the number, and the seven-decimal formatting does the rest.

Two footnotes worth keeping in your estimate:

First, the original shorthand "$0.000463 per vCPU-second" is 60× too high if read literally. At $0.000463 per second, a single vCPU at 100% duty is $1,200/month and $14,601/year — not the $243/year teams actually budget. Railway's figure is $0.000463 per minute ($0.00000772 per second). The companion figure "$0.000000231 per GB-second" is similarly off — 1,000× smaller than the displayed $0.000231/GB-minute and ~16× smaller than the true per-second GB rate. This is not Railway being deceptive. The docs state $20/vCPU-month and $10/GB-month plainly. It is what happens when a rate card carries as many significant digits as an orbital calculation: people copy the number and drop the unit.

Second, Hobby ($5/month including $5 of usage) and Pro ($20/seat/month including $20 of usage) share the same consumption rates in most official tables. Some community exporters show Pro CPU/RAM at roughly half the Hobby display rate, reflecting older tiers or promotions. Check your workspace invoice before banking on a Pro discount. The math below uses the published $20/$10 baseline — the conservative, and therefore useful, assumption for forecasting.

If you remember one row, make it this: $0.0278 per vCPU-hour, $0.0139 per GB-hour. Those multiply cleanly by 730 hours/month without a calculator.

What an always-on service actually costs​

The bill is vCPU × $20 + GB × $10 + egress + volume, minus the plan credit. Below are four shapes teams actually run, at 100% duty (always on, no serverless sleep) over a 30-day month. One service, one replica — the resources you reserve are the resources you pay for while the replica runs.

*Annualized after credit, before egress.

How to read it:

• A sidecar is still $10/month after credit — not free, not scary, but not the $5 the plan price suggests.
• A 1 vCPU / 1 GB API — the default "I deployed a web app" shape — is about $25/month on Hobby after credit, or about $8 if it sleeps 70% of the time. It is not $8 always-on, not $80 always-on, but $25–$30. That is the range the scientific notation hides.
• The naive 60× misread would put the Small API at $1,204/month and Postgres at $2,404/month. No one pays that, but the same four digits producing both $20 and $1,200 depending on a three-letter unit is the legibility failure in one number.
• Annualizing clarifies the TODO's anchor. One always-on vCPU is $243/year, not "about $1,200/year." The $1,200/year figure only appears for five vCPUs ($100/month) or a multi-service project with bursts and egress. Treat it as a composite project cost, not a single-vCPU cost, and the math reconciles.

Three adjustments after the base:

1. The Hobby credit is a floor, not a discount. You pay $5 even if you use $0.50. A Sidecar at $15 raw is $10 after credit; a second Sidecar on the same workspace is $25 raw total but only one $5 credit — it does not multiply per service.

2. Egress is the quiet multiplier. Railway egress is $0.05/GB on Metal and up to $0.10/GB elsewhere. A 50 GB/month API adds $2.50–$5.00 that never appears in the CPU/RAM line. An image-heavy service at 500 GB adds $25–$50 and can double a Small API's bill.

3. Duty cycle is the real variable. Nothing above assumes serverless sleep. If your service sleeps when idle — and many Hobby workloads do — you pay for active seconds only. A Small API at 30% duty (~7 hr/day, typical for an internal tool) is ~$9 raw, ~$4 after credit, not $30. The table is the always-on ceiling. The sleeping floor is 3–10× lower. That is why two teams can both be right that "Railway costs $4" and "Railway costs $30" for the "same" app.

Legibility is not the same as honesty​

The 2026 PaaS pricing conversation has — correctly — focused on hidden line items: Fly.io adding inter-region private networking at Machine rates and volume snapshot metering in early 2026, Render cutting Hobby egress from 100 GB to 5 GB, Vercel's ISR and edge-middleware meters. Those are honesty problems: the bill grew a new row after you committed. Legibility is the other tax. It compounds even when every line is disclosed.

Railway's rate card shows all three signatures of a legibility tax:

The unit doesn't match the budget window. You budget by the month. The rate is quoted by the minute. Every conversion needs a 43,200× or 2,592,000× multiplier no one holds in working memory. Contrast Hetzner: a CX22 is €3.79/month whether February has 28 days or the instance handled 10 requests or 10 million. The unit is the budget window.

Significant digits swamp the signal. $0.000463 and $0.000231 differ by 2× where it matters (CPU costs twice RAM), yet they look like the same tiny number. Worse, $0.000463/vCPU-minute and $0.00000772/vCPU-second are identical prices that look 60× apart if the unit is skimmed. A rate card that needs you to count trailing zeros to tell "twice as much" from "sixty times as much" has not priced its product — it has obfuscated it.

Forecast error is asymmetric and always up. When developers guess an always-on 1 vCPU / 1 GB bill from the tiny rates alone, errors cluster at $8–$12 (anchoring on the $5 plan fee) while reality is $25–$30. Nobody guesses $80. Every surprise is therefore an overage, every overage feels like a price hike, and the platform absorbs blame for a forecasting failure its own formatting invited.

This distinction matters: a fully disclosed, fully metered bill can still be unplannable if the unit is unplannable. "We added a new meter" and "we quoted the meter in units you can't budget in" produce the same outcome — the forecast was wrong — but they have different fixes. One needs fewer meters. The other needs bigger units.

Railway is not alone here. Azure Container Apps ($0.000024/vCPU-second), Fly Machines (per-second while started), and Cloud Run (per-100ms) all price below the monthly horizon. Railway's seven-decimal display plus dual per-minute/per-second quoting just makes it the clearest exhibit. The math is not hard. The legibility is.

The flat-box counterpoint: the same workloads on Hetzner​

Put the same four profiles on owned Hetzner Cloud hardware under a Cluster API fleet — the topology bex provisions — and the invoice changes shape.

Every row is a flat monthly number. Run 10 requests or 10 million, pay the same. Push 19 TB of egress, pay the same — Hetzner's 20 TB alone is roughly $950–$1,000 of Railway egress value (19,000 GB × $0.05) and about $2,850 of Vercel overage at $0.15/GB. That is not a rounding difference. It is a different cost structure.

Worked comparison, always-on:

• Small API ($25–$30/month on Railway Hobby): one CX22 at €3.79 holds it plus a sidecar with headroom — about one-eighth the price, before counting the second service that doubles the Railway bill but rides free on the same box.
• App + cache (~$35/month): still one CX22.
• Postgres (~$76–$80/month): one CPX22 at €7.99 or CPX31 at €13.99. The monthly delta is $63–$68, about $760/year that never appears as a line item because it arrives as $0.03 per hour.

At 100% duty cycle, flat hardware wins by 3–8× for always-on single-tenant workloads, even after the $5 credit. The gap narrows only because most Hobby workloads are not 100% duty.

That is the honest break-even, and it tells you when Railway is still the right call: workloads that sleep. An internal tool at 10% duty (~2.4 hr/day) costs ~$3 raw ($30 × 0.10) — free after the Hobby credit — while a CX22 still costs €3.79 that hour whether anyone hit the endpoint. Preview environments that live 20 minutes per PR, webhook ingestors that fire 400 times and sleep between, staging DBs that serve traffic only during review — those are not "small vs big" differences. They are "metered vs flat" structural differences. Metered wins whenever duty cycle is the variable, not total size.

The bex stance — and why this list keeps benchmarking PaaS bills against a Hetzner box — is not that one is always cheaper. It is that the unit you budget in should be the unit you are billed in. On a Cluster API fleet, the platform API is not another metered surface. A MachineDeployment scales a node pool; the node has a price; that price is the invoice. No per-second conversion, no new egress row since January, no per-GB-minute display to decode.

A one-minute estimator you can keep in your head​

If you are on Railway today and want to know before deploy whether a service stays inside Hobby, use vCPU-hours:

• CPU cost ≈ vCPUs × active hours × $0.0278
• RAM cost ≈ GB × active hours × $0.0139
• Total ≈ CPU + RAM, minus $5 credit, plus egress

Examples:

• 0.5 vCPU / 0.5 GB, 730 hr (always on): 0.5×730×0.0278 + 0.5×730×0.0139 ≈ $15.22 → $10.22 after credit
• 1 vCPU / 1 GB, 200 hr (sleeps nights): 1×200×0.0278 + 1×200×0.0139 ≈ $8.34 → $3.34 after credit
• 2 vCPU / 4 GB Postgres, 730 hr: 2×730×0.0278 + 4×730×0.0139 ≈ $81.18 → $76.18 after credit

If always-on math ever exceeds $8–$10/month for a single service across a quarter, the exercise worth running is not "which line item do I cut" but "would this workload's duty cycle pay for a flat box" — because the answer then depends on a number you already know: how many hours a month the service needs to be awake.

Railway at $20/vCPU-month plus $10/GB-month is fair for what it offers — no nodes to patch, no control plane to run, automatic sleep when idle, and a pricing page that at least states the monthly equivalents. The problem is not price. It is that the rate card's units are doing work on your forecast, making an always-on $30 look like $5 until the second invoice, then like a misprice when the math clears. Once the conversion lives in hours and months instead of seven-decimal seconds, the decision is not a trick. It is a duty-cycle question every team can answer from its own logs. And once it is that question, the flat-box alternative stops sounding like a philosophical commitment to self-hosting and starts sounding like what it is: the version of the bill you can do in your head before you git push.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. No per-vCPU-second meter, no per-GB-minute display to decode: the platform runs on a Cluster API fleet you control, so the API is the control plane, not another line item. Star the repo on GitHub or deploy your first app today.