A preview environment per pull request, on servers you own
Per-PR preview environments are one of the features that made Vercel and Netlify’s workflow feel inevitable in retrospect — a reviewer clicks a link instead of reading a diff and imagining what it does. The part that’s easy to miss when that workflow only exists on someone else’s managed platform: every one of those preview environments is a running server, and running servers cost money whether or not anyone’s actually looking at the PR.
What turning it on actually does
With GitHub connected, flip previews on for an app and every pull request after that gets its own full copy — same build, same process types, its own URL, automatically removed the moment the PR closes. No manual provisioning per PR, no manual cleanup when it’s done; the lifecycle matches the PR’s own lifecycle exactly.
The part that’s actually different: previews sleep
This is the detail that matters more than the preview mechanic itself: new staging and preview apps default to sleeping after 30 minutes of no traffic, and the next request wakes them back up. A PR that’s open for two weeks while someone’s on vacation isn’t a server idling at full cost for two weeks — it’s a server that’s asleep almost the entire time and wakes up the moment someone actually opens the preview link again.
Configurable per app under Settings → General: never, 10 minutes, 30 minutes, 1 hour, 6 hours, or a full day of no traffic before sleep — or set awake hours instead, specific days and a time window (in the app’s own time zone) it should stay up, sleeping outside that window regardless of traffic and waking on the next request either way.
railyard sleep my-preview-app 30Full environments, not just previews
Previews are the PR-scoped case of a broader idea: environments are full copies of a project — production, staging, whatever a team needs — created from the canvas. Services inside one environment reference each other the normal way (${{api.RAILYARD_PRIVATE_URL}}), resolved within that same environment automatically, so a staging environment’s services talk to staging’s own database, not production’s, without anything being hardcoded to know the difference.
Why the cost model is the actual point
A preview-per-PR system that bills like a production server for every open PR either gets used sparingly (defeating the point of having it) or becomes a line item someone eventually questions. One that sleeps by default does the useful thing (a running environment to actually click through) without the usual tradeoff of paying full price for idle infrastructure most of a PR’s lifetime.
Full reference: Environments and previews.