Railway vs Vercel vs Cloudflare: What Bursty Builds Really Cost Per Second (and When a Flat Hetzner Node Wins)

Railway will run a five-minute build for about two cents. Vercel will run a five-minute AI request for a fraction of what it charged a year ago — because it stopped billing you for the time your function spent waiting on the model. Cloudflare will bill the same container in 10-millisecond slices and charge you nothing while it sleeps. Three vendors, three definitions of "per-second," three different answers to the question your finance page actually asks: what does a bursty git-push habit cost at the end of the month?

This post recomputes the same three workloads — one build, fifty parallel PR builds, and an all-day monorepo — against Railway's resource meter, Vercel's Active CPU meter, and Cloudflare Containers' 10ms meter, then sets all three next to the flat monthly rate of a Hetzner build node you own. The punchline is not which rate is lowest. It is that "per-second" describes legibility, not cheapness — and bursty builds are the workload where the distinction bites hardest.

The answer up front: three tiers, four meters​

Assumptions, stated once so the table below is checkable: a typical build gets 4 vCPU and 8 GB RAM for 5 minutes (300 seconds). Rates are the vendors' published 2026 numbers: Railway at $20/vCPU/month and $10/GB RAM/month metered per second; Cloudflare Containers at $0.000020/vCPU-second and $0.0000025/GB-second in 10ms increments; Vercel Fluid Compute at roughly $0.128 per Active CPU hour plus about $0.0106 per GB-hour of provisioned memory; and a representative Hetzner cloud box (4 vCPU / 8 GB class) at roughly $17/month flat, whether it builds once or a thousand times.

Two things to read off this table before the detail. First, at low volume the meters are almost free and the flat node looks wasteful; at sustained volume the flat node wins and the meters converge toward it. The crossover for this build shape sits around 400–900 builds a month — a range most teams cross without noticing. Second, Vercel's row refuses to line up, and that refusal is the point of half this post: Vercel meters builds and function execution on different clocks, so "which per-second rate is lower" is the wrong question there. The right one is which clock your workload runs on.

How each meter actually ticks​

Railway: resource-seconds, plain and legible. Every second a service exists with N vCPU and M GB, you owe N × $0.00000772 plus M × $0.00000386 (those are just the monthly rates divided by 2.592 million seconds). Hobby carries a $5 floor that covers the first $5 of usage; Pro raises the floor to $20. There is no separate invocation fee and no wall-clock-vs-active distinction: a build container holding 4 vCPU for 300 seconds costs the same whether the CPU burned or waited on the network. That simplicity is the appeal and the trap — it is trivially forecastable per build, and it meters idle hold time at full price.

Vercel: two clocks, and only one of them got cheaper. Vercel bills builds (build minutes against an included quota) separately from function execution. Functions on Fluid Compute pay three lines: Active CPU hours ($0.128/hr), provisioned memory for the instance lifetime ($0.0106/GB-hr), and invocations per million. The 2025 change branded "Active CPU pricing" paused the CPU line during I/O wait — Vercel's own example puts a fully-busy standard function at ~$0.149/hr all-in versus substantially more under wall-clock GB-hours. For an AI endpoint that spends 8 of 10 seconds waiting on a model response, that is roughly an 80% cut on the CPU line. For a CPU-saturated build, it changes nothing — which is exactly why comparing Vercel's rate to Railway's rate for builds is a category error, and why teams migrating AI workloads off wall-clock serverless see savings that build-heavy teams will not.

Cloudflare Containers: the finest slice, active-only. Containers bill per 10ms of active runtime — $0.000020 per vCPU-second, $0.0000025 per GB-second, plus a disk line at $0.00000007 per GB-second — on top of the $5/month Workers Paid plan, and scale to zero so idle containers cost nothing. The per-second rates run about 2.5× Railway's, but the meter stops when the container sleeps, where Railway's meter runs as long as the service is provisioned. For spiky preview environments that sit idle between pushes, "expensive seconds, zero idle" routinely beats "cheap seconds, always on."

Hetzner: one number, no meter. A 4 vCPU / 8 GB cloud box costs on the order of $17/month and builds all day for the same price as sitting idle. No per-second math, no floor-versus-usage reconciliation, no month-end surprise — and no elasticity past the box. The forecasting problem disappears because there is nothing to forecast; the capacity problem appears because there is nothing to burst into.

Tier 1: the single build (about two cents, everywhere)​

Walk the arithmetic once, since every tier below is a multiple of it. A 5-minute build on 4 vCPU / 8 GB consumes 1,200 vCPU-seconds and 2,400 GB-seconds.

• Railway: 1,200 × $0.00000772 = $0.0093 CPU, plus 2,400 × $0.00000386 = $0.0093 RAM. Total: ~$0.019.
• Cloudflare: 1,200 × $0.000020 = $0.024 CPU, plus 2,400 × $0.0000025 = $0.006 RAM. Total: ~$0.030 before the disk line (pennies) and the $5 plan.
• Hetzner: $0 marginal — the box is already paid for.
• Vercel: not comparable on this axis; the build consumes build minutes, and the function's Active CPU meter only starts at request time.

At this tier the only honest conclusion is that everyone is cheap. A team doing twenty builds a month pays under fifty cents in metered compute on either Railway or Cloudflare — well under Railway's $5 floor, which is the actual bill. The floor, not the rate, is the price of bursty at small scale, and it is why "two cents a build" marketing never survives contact with the invoice: you paid $5 for $0.40 of compute.

Tier 2: fifty parallel PR builds (the afternoon that matters)​

Now burst: fifty PRs land after lunch, each needing the same 5-minute build, all at once. Compute is 50 × Tier 1: ~$0.93 on Railway, ~$1.50 on Cloudflare, plus nothing else — no reservation, no queue tuning, no pre-provisioned runner pool sitting warm "just in case."

This is the tier where per-second metering genuinely earns its keep, and it is worth saying why plainly: the flat-rate alternative handles this afternoon in one of two ways, both bad. Either the Hetzner build pool was sized for the average day, in which case fifty parallel builds queue and developers watch spinners, or it was sized for this afternoon, in which case most of its capacity idles most of the month. Elasticity is the product being sold here, not compute. Ninety-three cents is the price of not having to choose between a queue and an idle fleet — and for PR-driven teams, that is usually the correct purchase.

The caveat arrives with the next tier: elasticity priced per second is a bargain for afternoons and a tax on everydays.

Tier 3: the all-day monorepo (where the flat node strikes back)​

Take a busy monorepo: 20 builds a day, 22 workdays a month, same 5-minute shape. That is 440 builds, or 264,000 vCPU-seconds and 528,000 GB-seconds.

• Railway: 264,000 × $0.00000772 ≈ $2.04 CPU, plus 528,000 × $0.00000386 ≈ $2.04 RAM... scaled to the full month including the services idling between builds, real teams report the meter landing several times that once always-on preview services and staging environments hold resources between pushes. The compute alone is ~$4–8/month; with a staging environment held warm it crosses the $20 Pro floor quickly.
• Cloudflare: 264,000 × $0.000020 ≈ $5.28 plus 528,000 × $0.0000025 ≈ $1.32, ~$6.60 plus the $5 plan — but only if containers actually sleep between builds. A preview environment that never scales to zero is just an expensive VM.
• Hetzner: ~$17, unchanged. The box does not care whether it ran 40 builds or 440.

Somewhere between Tier 2 and Tier 3 sits the crossover, and its exact position matters less than its existence: below it, metering wins by eliminating idle; above it, the flat node wins by eliminating metering. A team that picked Railway for its fifty-PR afternoons and then grew into monorepo-everyday throughput can sail past the crossover without any single bill looking anomalous — each month is a little higher, never shocking, until someone totals the year. The 2026 Medium teardown that made the rounds — a developer budgeting $20 on Pro and opening $286 — is the canonical shape of this failure: not one runaway workload, but steady-state throughput on a meter priced for bursts.

The legibility problem is separate from the rate problem​

Here is the argument the rate tables obscure. "Per-second" sounds like precision, but each vendor's second contains different things, and forecasting requires knowing which:

• Railway's second is a provisioned second: reserved CPU and RAM, burning or idle alike. Forecastable from your service sizes, punishable when services idle.
• Vercel's Active CPU second is a burning second for CPU plus a held second for memory plus a per-invocation line. Two workloads with identical wall-clock time and wildly different bills — the AI endpoint that waits versus the build that burns — which is fairer but harder to predict from a dashboard of request counts.
• Cloudflare's 10ms slice is an active slice with genuine zero when asleep — the most honest meter of the three, and the one most dependent on your code actually sleeping. A container that polls instead of idling converts the best rate card into the worst bill.
• Hetzner has no second at all, which is perfectly legible and perfectly inelastic.

So when someone asks "which per-second rate is lower," answer the question they asked with the table above — then answer the question they meant: can you predict next month's bill from this month's deploys? On Railway, yes, if you know your service sizes. On Vercel functions, only if you know your active-to-wait ratio, which most teams have never measured. On Cloudflare, only if you trust your scale-to-zero, which you should verify rather than assume. The forecasting input each meter demands — sizes, burn ratios, sleep behavior — is the real cost of adopting it, paid in observability work rather than dollars.

What this means on machines you own​

A self-hosted fleet does not escape this tradeoff; it just denominates it differently. A fixed Hetzner build pool is Tier 3 pricing at every tier: unbeatable at sustained throughput, wasteful at one build a month, and queuing at fifty parallel PRs unless overprovisioned. The Cluster-API answer is to make the pool itself elastic — scale the runner set with the queue, pack tenant builds alongside tenant apps, let idle nodes drain — so the flat monthly rate covers the average while automation absorbs the afternoon. That is the actual cost advantage of owned hardware: not cheaper seconds, but the ability to choose, per workload, whether it gets dedicated capacity, shared bin-packed capacity, or nothing until the queue says so.

None of the three vendors is overcharging. Each meter rewards the shape it was designed for: Railway rewards steady-state services with legible sizes, Vercel's Active CPU rewards wait-heavy AI workloads, Cloudflare rewards workloads that truly sleep. Bursty builds are none of those shapes consistently — they are Tier 1 on Monday, Tier 2 on Friday, Tier 3 by next quarter — which is why the team running them on someone else's meter should re-derive the crossover every few months, and why the team running them on its own fleet should automate the pool before arguing about the rate.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.