Railway raised $100 million to become the AI-native cloud, charging $0.00000772 per vCPU-second — a meter so fine it sounds like it must be cheap. I recomputed the same steady API-plus-worker-plus-Postgres workload on that meter and on a flat Hetzner box, and the meter came out at $106.50 a month against $42.60 for the box: two and a half times the price, for the identical topology running the identical hours.
That ratio is not a gotcha. It is the predictable result of comparing per-second billing against flat iron at high utilization, and Railway's own blog says as much. But the number matters because the pitch around the raise — "50% under hyperscalers," AI-native everything — invites a reading where the meter is cheap in absolute terms. It is not. It is cheap relative to the most expensive baseline in computing, and those are very different claims.
The raise, in 90 seconds
In January 2026, Railway announced a $100 million Series B led by TQ Ventures, with FPV Ventures, Redpoint, and Unusual Ventures participating (VentureBeat). The company said it serves two million developers — acquired, it claims, without spending a dollar on marketing — processes more than 10 million deployments a month, and pushes over a trillion requests through its edge network.
The thesis, in founder and CEO Jake Cooper's telling, is that AI coding tools moved the bottleneck: code gets generated in seconds, so the scarce resource is somewhere to run, test, and update it without waiting on slow build-and-deploy loops. Railway's answer is infrastructure it fully controls — it left Google Cloud in 2024 to build its own data centers — with deployments it says complete in under a second.
The pricing claim attached to the raise is the one this post audits: per-second billing ($0.00000772 per vCPU-second, $0.00000386 per gigabyte-second of memory, $0.00000006 per gigabyte-second of storage) that undercuts hyperscalers by roughly 50 percent and newer cloud startups by three to four times, with no charges for idle virtual machines. VentureBeat also reports Railway stayed online through recent widespread outages that took down major cloud providers. So the question is narrow and fair: what does that meter actually cost for an ordinary steady workload, next to a flat box?
The recompute: one steady workload, two bills
Take the most boring production topology in existence: an API, a background worker, and Postgres, running 24/7 with steady traffic. Size it modestly — 1 vCPU and 1 GB each for the API and worker, 1 vCPU and 2 GB plus a 10 GB volume for Postgres — and assume 100 GB of monthly public egress. Nothing here is exotic; it is the shape of thousands of real side projects and small SaaS backends.
On Railway's Pro plan ($20 a month including $20 of usage), the meter prices come straight from Railway's pricing docs: $20 per vCPU-month, $10 per GB-month of RAM, $0.15 per GB-month of volume storage, and $0.05 per GB of egress. (Check the per-second figures against the monthly ones: $0.00000772 × 2,592,000 seconds in a 30-day month is $20.01. They agree.)
| Service | Railway sizing | Monthly math | Cost |
|---|---|---|---|
| API | 1 vCPU + 1 GB | $20 + $10 | $30.00 |
| Worker | 1 vCPU + 1 GB | $20 + $10 | $30.00 |
| Postgres | 1 vCPU + 2 GB + 10 GB vol | $20 + $20 + $1.50 | $41.50 |
| Egress | 100 GB public | 100 × $0.05 | $5.00 |
| Total | $106.50 |
Usage of $106.50 blows past the $20 included allowance, so the bill is $106.50. Internal traffic between the three services rides Railway's private network and is free, which this math already assumes — routing the database over its public URL would add egress instead.
Now the flat box. A Hetzner CPX32 — 4 AMD EPYC shared vCPUs, 8 GB of RAM, 160 GB of NVMe, 20 TB of included traffic — comfortably swallows all three services with headroom to spare. After Hetzner's June 15, 2026 repricing, it lists at $41.99 a month before the primary IPv4 address, which is about $0.60 a month extra. Total: about $42.60 a month, traffic included.
$106.50 versus $42.60. The meter costs 2.5× the box for the same always-on topology. Note this uses Hetzner's current post-hike price — the CPX32 used to list at $15.99, at which point the ratio would have been 6.4×. The gap already narrowed once; this post is not pricing the hike out of existence.
Where the lines cross: the utilization curve
One data point is an anecdote, so here is the curve. The same 4 vCPU / 8 GB fully consumed on Railway costs $160 a month in compute alone (4 × $20 + 8 × $10), plus storage and egress — call it $166.50 against the box's $42.60, or roughly 4× at full saturation. The meter's premium grows with utilization: per-second billing converges to a ~4× markup over flat iron as the box fills up.
Run that backwards and you get the decision rule. The flat box wins once average utilization of box-equivalent resources climbs past roughly a quarter — $42.60 ÷ $160 ≈ 27% on compute, a touch lower once metered storage and egress count. Below that line, the meter wins, and sometimes by a lot.
Railway's Serverless mode is the obvious middle path: let the API sleep when idle and CPU/RAM charges stop while it naps. If the API is awake only 8 hours a day, its $30 falls to about $10 and the total drops to roughly $86.50 — still about 2× the box. And there is a structural reason it cannot go further for this topology: the worker polls a queue and Postgres holds open connections, and Railway's own Serverless docs warn that outbound traffic like heartbeats, polls, and database connections keeps a service awake. The two services that cannot sleep are most of the bill.
That is the complete picture, and it is the opposite of cherry-picked: the meter wins low-utilization and spiky workloads, the box wins steady ones, and the crossover sits near 25% utilization. Anyone choosing between them should be measuring their own average utilization, not reading slogans.
What "AI-native" actually changes about the bill
The raise was sold as AI-native cloud infrastructure, so what do the AI primitives cost? Railway bills sandboxes and cloud agents at separate VM rates: $50 per vCPU-month and $50 per GB-month, with memory billable while a VM waits for work. An always-on 2 vCPU / 4 GB agent sandbox therefore costs $100 + $200 = $300 a month before egress — 3.75× what the same resources cost at container rates ($80).
This is the honest answer to what "AI-native" changes about the bill: the workloads the label refers to are metered at a premium to the already-premium container meter, not a discount to it. Destroy sandboxes when done, lean on idle timeouts and checkpoints, and the number falls fast — Railway's docs say exactly that. But anything agent-shaped that must stay warm pays the highest unit price on the platform, which is worth knowing before the roadmap fills with always-on agents.
The honest counter-case: when Railway wins
None of the above means the meter is a bad deal in general. Three caveats, all real, all in Railway's favor.
First, spiky and sleepable workloads genuinely invert the result. Railway's own worked examples show a sporadic API on Serverless landing under a dollar of usage for the month — cheaper than any always-on box at any price. If your traffic has a shape with real zeros in it, per-second billing is the right tool and this post's topology is not your topology.
Second, the Hetzner column excludes ops labor and the Railway column includes a deployment platform: git-push deploys, preview environments, private networking, usage alerts, and hard spend caps come with the meter. The named customer stories (VentureBeat) measure Railway against hyperscalers, not against flat iron — G2X's infrastructure bill falling from $15,000 to about $1,000 a month, and YC-backed Kernel running its customer-facing system for $444 a month — and on that axis the 50%-under claim has receipts. Just remember what is being compared each time.
Third, Railway concedes the steady-workload point itself. Its September 2026 pricing essay states it plainly: "If your workload sits at roughly the same size all month and fits cleanly into an available server size, fixed or provisioned pricing can be hard to beat." When the vendor's own blog agrees with your recompute, the recompute is probably right.
What "50% under hyperscalers" actually means
The claim deserves one careful paragraph, because it is doing framing work. Hyperscaler on-demand list price is the most expensive way to buy compute that exists at scale — the rack rate nobody with a committed-use discount or a FinOps team actually pays. Undercutting it by half is a real achievement built on real cost control (owning the data centers instead of renting Google Cloud, as Railway has done since 2024). But it leaves the metered-vs-flat axis untouched.
The right mental model has two axes, not one: whose iron (hyperscaler, Railway's own, your Hetzner box) and how it is metered (per-second, provisioned, flat). Railway moved decisively on the first axis and charges a premium on the second. A team migrating off AWS can simultaneously save 50% and still pay 2.5× what the same workload costs on flat iron — both statements true, different denominators. Slogans quote the flattering denominator. Bills use the other one.
The bottom line
For a steady API, worker, and Postgres that never sleep, Railway's per-second meter bills about $106.50 a month where a flat Hetzner CPX32 bills about $42.60 — a 2.5× premium that stretches toward 4× at full saturation and shrinks below 1× only once average utilization drops under roughly a quarter. The AI-native primitives invert the intuition further: always-on agent sandboxes pay the platform's highest unit rates, not its lowest.
None of that erases the reasons teams choose Railway — zero-ops deploys, Serverless economics for spiky traffic, and genuine savings against hyperscaler bills. It just puts the meter where it belongs: a premium pricing model for flexibility and velocity, not a cheap one. Measure your utilization, know which denominator your comparison uses, and the right choice is usually obvious.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Flat-iron economics with a PaaS workflow, so steady workloads stop paying the meter. Star the repo on GitHub or deploy your first app today.



