Pull-request previews for every client branch, without a Vercel bill: the DNS, the isolation and the automatic cleanup

Preview environments — a live URL for every pull request, so a client or a reviewer can click through a change before it merges — are one of the few platform features that sell themselves. A client who can open a link and see the new feature, instead of reading a description of it, approves faster and complains less. The reason agencies ration them isn’t that clients don’t want them. It’s that on a per-seat, per-environment platform, a preview per PR across a dozen clients is a bill that scales with how much work you’re doing, which is exactly the wrong direction.

They’re worth having right. Here’s what “right” actually involves, because the demo version and the production version differ in three specific places.

The URL

A preview needs its own address, and the address needs to appear the moment the pull request opens — a reviewer isn’t going to wait while someone wires up DNS. The working version uses a wildcard: a single DNS record for *.previews.yourdomain (or the client’s domain) means every new preview gets a subdomain instantly, with no per-preview DNS change. The preview for PR #42 is just pr-42.previews.…, routed and HTTPS-ready as soon as the environment is up, because the wildcard certificate already covers it.

That’s the difference between previews that appear in a minute and previews that require a step. If each preview needs its own DNS entry and its own certificate, nobody will keep up, and the feature quietly dies. A wildcard record and a wildcard certificate make a new preview a routing fact, not a task.

The isolation

A preview that shares the production database isn’t a preview — it’s a loaded gun pointed at production. The whole value of previewing a change is that you can exercise it, including the parts that write data, without consequences. So each preview needs its own isolated copy: its own process and, critically, its own database, seeded or branched from a safe source, that the preview can mutate freely and that disappears when the preview does.

This is the part the cheap version skips, and it’s the part that matters. A preview with a throwaway database lets a reviewer actually use the feature — create records, run the migration, click the destructive button — and know that none of it touched anything real. A preview wired to production looks the same in a demo and is a liability the first time someone tests a delete.

The cleanup

Here’s the part everyone forgets, and the part that turns previews from a feature into a slow leak: they have to go away. A preview per pull request is fine; a preview per pull request that never gets torn down is a server slowly filling with the ghosts of merged branches, each holding memory and a database, until the box is full of environments for work that shipped weeks ago.

The only version that survives contact with a busy team is automatic cleanup: the preview is created when the pull request opens and destroyed when it merges or closes, without anyone remembering to do it. Ephemeral has to mean ephemeral. If cleanup is manual, it won’t happen, and the “free” previews become the reason you’re paying for a bigger server.

How it comes together without the per-preview bill

Railyard creates a preview environment for each pull request automatically — its own isolated copy with its own database, on the client’s own server, under a wildcard subdomain with HTTPS already handled — and tears it down when the PR merges or closes. Because the previews run on servers you already have, there’s no per-environment price: a dozen clients with active pull requests is a dozen clients’ worth of previews on the servers their apps already live on, not a line item that grows with your throughput.

The feature clients love stops being the feature you ration. Every pull request gets its URL, its isolation and its automatic exit, and the only thing that scales with the number of previews is how much faster your clients approve the work.