Railway Ranked Its Own Rivals on Preview Environments — So We Priced the Rematch: What 50 PRs a Month Costs on Metered vs Instance Pricing vs a Namespace You Own

In May 2026, Railway did something vendors rarely do: it published a ranking of the best preview-environment platforms that included itself — first, naturally — alongside Vercel, Render, Northflank, Heroku Review Apps, and a handful of Kubernetes-native options. The post is well-reported and worth your time. But its most interesting sentence isn't about who won. It's the concession: Render takes third place, praised explicitly for "predictable instance pricing" against usage-metered rivals.

That concession is a pricing argument wearing a product ranking's clothes. So let's settle it with arithmetic. What does a PR-heavy month — 50 pull requests, each with its own running environment and its own database copy — actually cost under Railway's per-resource-minute metering, under Render's per-instance pricing, and under the third option neither vendor mentions: ephemeral namespaces on machines you already own, where the 51st preview environment costs nothing at all?

Here is the answer up front, with the full working below: for a typical small preview (one web service plus one Postgres copy, alive 48 hours), 50 PRs cost roughly $25 in usage on Railway (plus the seat base), roughly $46 on Render (plus the workspace base), and roughly $0 marginal on your own cluster. But flip the workload hot — previews running load tests and seed jobs at high CPU — and the meter passes the instance price at around a third of reserved utilization. The model that wins depends on one variable most teams never measure: how hard their previews actually work while they're alive.

The worked month: assumptions on the table first​

Any cost comparison without stated assumptions is marketing. Here are mine, chosen to resemble a typical small-team preview rather than anyone's flattering edge case:

• Preview shape: one web service (0.5 vCPU, 512 MB RAM) plus one isolated Postgres copy (0.5 vCPU, 512 MB RAM). The isolated database matters — it's the property that lets a developer run a destructive migration on a branch without coordinating with anyone, and Railway's ranking post rightly treats per-environment databases as a first-class comparison axis.
• Lifetime: 48 hours median per PR — opened, reviewed, CI'd, merged. Torn down on merge in all three models.
• Volume: 50 PRs in a 730-hour month. That implies about 3.3 preview environments alive concurrently on average, a number that matters for the owned-hardware column.
• Rates used: Railway's published usage prices (CPU $20/vCPU/month, RAM $10/GB/month, from Railway's pricing docs); Render's Starter-class web service at $7/month with preview resources billed like any other service, prorated by the second; a Hetzner CX33 cloud server (4 vCPU, 8 GB RAM) at €8.49/month for the owned column.

The three-column month, idle-lean case (previews mostly waiting on humans — ~10% average CPU on web, ~5% on the database):

The Railway web row works out as 0.05 average vCPU × 48 h × ($20/730 h) ≈ $0.07 of CPU plus 0.3 GB × 48 h × ($10/730 h) ≈ $0.20 of RAM. The Render web row is $7/730 × 48 ≈ $0.46 — same whether the container idles or burns. The owned column: 3.3 average concurrent environments at 1 vCPU/1 GB each fits comfortably on a single 4 vCPU/8 GB node with headroom, so the whole month's previews ride on roughly ten euros of sunk compute.

Why both vendors prorate — and still differ by nearly 2×​

Here is the subtlety the ranking post glosses and the headline numbers hide: Render prorates too. Preview resources are billed by the second, so a preview that lives 48 hours costs 48 hours, not a month. The difference between the models was never "flat versus metered." It is reserved versus consumed.

Render bills the instance type for every second the environment exists, regardless of whether the container is serving traffic or waiting on a design review. Railway bills the CPU-seconds and gigabyte-minutes the environment actually consumes. An idle-lean preview — the modal preview, waiting on humans 90% of its life — costs nearly its full reservation on Render and a fraction of it on Railway. That is the entire 84% gap in the table above, and it is a utilization story, not a unit-price story.

This also tells you exactly when the ranking flips. Recompute the same month with hot previews — web at 75% average CPU, database at 40%, full RAM committed, the shape you get when every PR runs seed jobs, integration suites, and load smoke tests:

The crossover sits at roughly a third of reserved CPU utilization. Below it, the meter wins. Above it, the reservation wins. Nothing about either vendor changed — only how hard your previews work while alive. If your team has never measured average preview CPU, you are choosing a pricing model blind, and this is the number to go instrument first.

Two honest footnotes before anyone pastes this table into a budget doc. First, both columns exclude the platform base both vendors charge (Railway's $20/seat Pro, Render's paid workspace) — symmetric treatment, since you pay either regardless of PR count. Second, database sizing is doing quiet work in these numbers: Railway's per-environment Postgres copies are genuinely isolated databases, Render's preview database story the ranking itself grades as "partial," and teams that need full production-shaped data per PR will size both columns up. The direction of the comparison survives; the exact dollars move with your shape.

What the ranking gets right — and the three costs it skips​

Railway's post earns its ranking on three axes that survive contact with real teams. Per-environment databases really are the feature that decides whether previews change developer behavior or just demo well. Automatic teardown on merge really is load-bearing — the post's own warning about "orphaned Postgres instances accruing cost on the bill" is the voice of experience. And the agent angle is genuinely forward-looking: Railway's MCP-driven environment lifecycle (create, wait for readiness, query the URL, run tests, clean up) is the only entry on the list building explicitly for the pattern where an AI validates its own PR before a human ever looks.

But three costs never make the ranking, and all three land on the reader:

1. Stale-PR lifetime. The 48-hour median is doing heavy lifting. A PR that sits open for ten days costs five times the median on both metered and prorated-instance pricing. Render at least ships a forcing function — previews.expireAfterDays auto-deletes environments idle past N days. Whatever platform you pick, set the expiry; it is the cheapest line item in this entire post.
2. Egress and storage. Railway bills egress at $0.05/GB and volumes at $0.15/GB/month — small numbers that stop being small when 50 previews each pull production-shaped seed data and container images. Budget 10–20% on top of the compute math for a data-heavy preview shape.
3. The third model's real price. The owned-namespace column says $0 marginal, and the compute really is sunk. What isn't free is the operator burden: someone owns the cluster, the preview automation, the database provisioning per namespace, and the 3 a.m. page when the node fills up. The ranking excludes this option because none of its ten entries sell it — but for a team already running a Cluster API fleet, a preview is a namespace plus a Postgres operator plus a wildcard DNS record, and the marginal cost truly is zero.

Which model for which team​

• Under ~20 PRs a month, previews mostly idle: Railway-style metering wins on pure dollars, and the per-PR database copies are the best in the ranked set. Watch stale-PR lifetime.
• High PR volume with hot, CI-heavy previews: Render-style instance pricing wins once average utilization crosses roughly a third of reserved — and its predictability makes the budget conversation shorter even when the dollars tie.
• Already operating your own Kubernetes fleet: stop renting per-PR compute entirely. Ephemeral namespaces cost nothing marginal; spend the savings on the Postgres operator and the expiry automation instead.
• Agents validating their own PRs: weight the MCP-native lifecycle over either pricing column. The team whose agent can spin up, test, and tear down its own environment will out-ship the team saving $20 on the meter.

Railway deserves credit for publishing a ranking it knew it couldn't win on every axis — conceding Render's pricing predictability in its own post is a confident move. But rankings tell you who won the author's game. The meter-versus-instance question is your game, and now you have the table to play it: measure your previews' utilization, multiply by your PR volume, and pick the model whose assumptions match your reality rather than the vendor's.

Running previews on machines you already own? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with per-PR environments as namespaces that cost nothing extra to create. Star the repo on GitHub or deploy your first app today.