What PR Preview Environments Really Cost: Render vs Railway vs Self-Hosted

Every pull request deserves a live environment. That sentence is easy to agree with and surprisingly expensive to implement, and the gap between "spin up a copy per PR" as a feature checkbox and as a monthly bill is where teams keep getting surprised. Render, Railway, and Fly.io each answer the preview-environment question differently, and the self-hosted answer — namespaces, database snapshots, wildcard DNS — has a cost curve that looks nothing like any of theirs.

Here is the short version for a typical team — five developers, about 20 pull requests a month, each open for roughly two days, each preview running one web service plus one Postgres:

The managed options converge around forty dollars a month, and the self-hosted option is nearly free per preview but demands real engineering to build. The rest of this post shows the math behind each row, the parity checklist most comparisons skip, and exactly where the answer flips.

What "preview parity" actually means​

Before comparing prices, it helps to pin down what you are buying. A preview environment that a team will actually trust has six parts:

1. Per-PR app copies created automatically when a PR opens, updated on every push, destroyed on merge or close.
2. Database copies — and here is the detail everyone glosses over: an empty schema copy is not the same as a production-data copy, and they cost wildly different amounts.
3. Expiry garbage collection, so a PR left open for three weeks does not burn money for three weeks.
4. Per-preview URLs with TLS, obtainable without filing a ticket.
5. Cost controls, typically the ability to run previews on smaller compute than production.
6. Monorepo awareness, so a docs-only change does not spin up the entire stack.

Keep this checklist in mind. Every "we have preview environments" claim below scores differently against it, and item 2 is where the managed offerings are weakest.

Render: full-stack copies on a flat workspace fee​

Render's preview environments are the most deliberately designed of the managed options. You define your stack in a Blueprint (render.yaml), flip previews to automatic, and every PR against the linked branch gets a fresh copy of the whole production environment — services, datastores, and environment groups. Merge or close the PR and Render destroys the copies. Prefer control over automation? Manual mode provisions a preview only when the PR title contains [render preview], and automatic mode lets individual PRs opt out with [skip preview].

Three mechanisms keep the bill sane. First, previews can run on smaller compute than production: previewPlan for Postgres and Key Value instances, previews.plan for everything else. Second, previews.expireAfterDays deletes environments after N days without new commits — the default is no expiry, so set this on day one. Third, root directories and build filters mean a PR that only touches docs never provisions anything.

Now the fine print that matters. Render states plainly in its docs that copies of datastores and persistent disks do not include data from the base resource. Your preview Postgres is a fresh empty database; if you want seed data, you wire an initialDeployHook to load it after first deploy. Calling these "full database copies" is accurate for infrastructure and wrong for data — and for teams whose bugs only reproduce against realistic data, that distinction is the whole ballgame.

The pricing math: preview environments require a Pro workspace or higher. Pro is $25 per month per workspace, flat — unlimited members, unlimited services — plus compute, and preview resources are billed like any other Render service, prorated by the second. A minimal preview (Starter web at $7/mo plus Starter Postgres at $6/mo, roughly $13/mo of full-month compute) living for two days costs about $0.87. Twenty such PRs in a month land around $17 in preview compute, for a total near $42/mo on top of whatever production already costs.

Railway: the same shape, metered by the minute​

Railway's PR environments follow the same lifecycle: enable them in project settings and each opened PR gets a temporary environment duplicating the base environment's services, auto-deployed from the PR branch, deleted on merge or close. Domains are provisioned automatically as long as the base services use Railway-provided domains. It is a close second to Render on polish — slightly less declarative (no Blueprint equivalent with per-preview plan overrides in YAML), slightly more "it just duplicates the canvas."

The billing model is the real difference. Railway Pro is $20/mo per subscription, and that $20 goes toward usage — it is a commit, not a fee. Everything else is metered: roughly $10 per GB of RAM per month and $20 per vCPU per month, billed per minute of actual consumption.

Run the same typical team through that meter. A preview with a small web service and Postgres — say 1 vCPU and 1 GB of RAM combined — represents about $30/mo of full-month usage. Two days of PR life is 2/30 of a month, so each PR costs about $2.00 in metered usage. Twenty PRs total ~$40 of usage; the $20 subscription absorbs the first $20, leaving ~$20 in overage. Total: ~$40/mo — within noise of Render's number, arrived at by a completely different route.

That convergence is not a coincidence. Both vendors are charging roughly list price for small compute plus a ~$20 platform fee; they just package it differently. Render's flat workspace fee wins for larger teams (ten members cost the same as two), while Railway's usage-credit model wins for quiet months — few PRs means you pay little more than the subscription.

Fly.io: the parts list, some assembly required​

Fly.io has no built-in PR preview feature. What it has is an official blueprint — "Git Branch Preview Environments on GitHub" — showing how to build review apps yourself with GitHub Actions and flyctl: create an app per PR, deploy the branch, destroy on close.

This is worth mentioning not to dunk on Fly but because the blueprint is an honest parts list. Reading it tells you exactly what Render and Railway automate away: app provisioning, branch deployment, DNS, TLS, teardown, and (in community variants of the pattern) database forks. If you are pricing the self-hosted build, Fly's blueprint is the closest thing to a reference implementation of the glue you would write — and a reminder that per-PR Postgres forks are the part nobody hands you for free.

The self-hosted accounting: nearly free per preview, honestly expensive to build​

On a Cluster-API-managed fleet running on machines you already rent, the marginal cost of one more preview environment rounds to zero. A namespace, a Deployment with small resource requests, a Service, an Ingress route off a wildcard domain with cert-manager — these consume headroom, not budget. Two concurrent previews at half a gigabyte each fit in the slack of almost any node pool. Database-wise you actually have an option the managed vendors do not give you: copy-on-write CSI snapshots can clone a volume in seconds, which is the closest thing in this comparison to a true production-data copy per PR.

So per-preview, self-hosted wins by a mile. But per-preview was never the whole bill. The fixed cost is a build project with five work items:

• Per-PR namespaces and lifecycle webhooks — create on PR open, sync on push, delete on merge/close, driven by your git forge's webhooks.
• Database provisioning per PR — empty-plus-seed via an init job (the Render model, easy) or snapshot-cloned volumes (the actually-good model, harder: snapshot scheduling, restore orchestration, storage growth).
• Expiry garbage collection — your own expireAfterDays, because PRs get abandoned and headroom is not infinite.
• DNS and TLS fan-out — wildcard DNS plus automated certificates per preview hostname.
• Cost visibility — per-namespace resource accounting, so one team's 40 open PRs do not silently eat the pool.

That is somewhere between a focused week and a quarter-long platform project depending on how far down the database-cloning rabbit hole you go. Here is the honest framing: a single engineer-week costs more than a decade of Render's $25/mo workspace fee. Self-hosted previews are not a cost optimization. They are a control optimization that happens to have zero marginal cost — worth it when you need something the managed menu does not serve, not as a way to save forty bucks.

Where the answer flips​

The ~$40/mo managed consensus holds for the typical team, but four variables move it:

• PR volume. Managed preview compute scales linearly with PR-days. At 100+ PRs a month with long-lived branches, Render and Railway each climb past $150/mo in preview compute alone, while self-hosted marginal cost stays flat until you must add a node. High-velocity teams feel this first.
• Database weight. The managed math above assumes Starter-class databases. Previews that need production-shaped Postgres change the ratio fast — managed database minimums are the most expensive line in every preview bill, while a snapshot clone on your own storage is nearly free.
• Data-copy needs. Neither Render (explicitly: no data in copies) nor Railway hands you production data in previews. If your testing genuinely needs realistic data, the managed path means building seed pipelines anyway — at which point you are paying the managed fee and doing integration work, and the self-hosted snapshot story starts looking like the actual product.
• Team shape. Render's flat $25 with unlimited members gets cheaper per head as you grow; Railway's metered model favors quiet months and small teams. A two-person side project with five PRs a month pays ~$25 on Render and barely over $20 on Railway.

The decision rule that falls out: under ~30 PRs a month with seedable databases, rent — the managed fee is less than the meeting where you discuss building it. Past that volume, or the day a bug only reproduces against real data, the self-hosted parts list stops being a project and starts being the cheaper architecture.

The bottom line​

Render and Railway have converged on the same deal from opposite directions: Render sells you a flat-fee workspace with declarative, cost-controlled preview copies; Railway sells you metered duplication where the subscription doubles as credit. Both land near $40/mo for a typical team, both destroy previews on merge, and both stop short of copying your data. Fly.io hands you the blueprint and wishes you luck, which is more useful than it sounds — it prices the glue honestly.

Build your own when you need data-realistic previews at volume, on infrastructure you already pay for. Until then, forty dollars is a bargain for never thinking about preview garbage collection again.

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.