Preview Environments
Date: 2026-08-17
A running deployment per pull request, at its own URL. It changes what review can be — a designer, a stakeholder or a tester can look at the actual thing rather than at a diff, which surfaces the problems code review structurally cannot.
A preview environment is an ephemeral deployment of a branch, created automatically when a pull request opens and destroyed when it closes.
What it unlocks
CODE REVIEW SEES the diff
PREVIEW SEES the result
→ a designer checks the spacing
→ a stakeholder confirms the copy
→ QA tests on a real phone
→ you check it on a slow connection
→ an accessibility pass on the
real thing — Accessibility Testing
Most of those people cannot read a diff, and asking them to review one is why feedback arrives after release instead of before — Code Review.
Why it beats a shared staging server
SHARED STAGING
one environment, everyone's changes
→ whose change broke it?
→ a queue to deploy
→ someone's half-finished work is
always on it
→ "is staging up to date?"
PREVIEW PER PR
isolated by construction
→ no queue, no contention
→ the URL is the change
→ destroyed automatically
Contention on a shared staging environment is a real tax — it serialises work that was parallel and makes “it worked on staging” ambiguous.
The hard part is data
The application deploys easily; the state behind it doesn’t.
SHARED DATABASE
simplest
← previews interfere with each other
← a destructive migration affects
everyone
BRANCH / FORK PER PREVIEW
isolated, and the best experience
← needs platform support
SEEDED EPHEMERAL DATABASE
deterministic, disposable
← the most work, the most control
— Test Data
See: Test Data
Never point a preview at production data. It’s a lower-controls environment holding real customer PII, with URLs that are frequently public and indexable — PII in Analytics.
Seeded ephemeral is the right target, and a good seed script pays for itself here as well as in local development.
Everything else that has to be per-preview
API keys test-mode credentials,
never production
— Secrets Management
Payment provider sandbox mode
Emails a catcher, not real
sending
Analytics disabled, or a separate
property
→ or preview traffic
pollutes real data
Webhooks to the preview, not the
production endpoint
Search index separate, or shared
read-only
See: Secrets Management
Analytics is the one that leaks quietly. Preview traffic landing in your production property inflates sessions and corrupts experiment data for weeks before anyone traces it — Tool Discrepancies.
Guard them
Preview URLs are guessable, and the deployments are real:
□ noindex, or robots blocking
□ basic auth or SSO
□ test-mode payment keys only
□ no production database
□ expire automatically
A preview environment indexed by search engines is a genuine and recurring incident — unreleased pricing, unannounced products, duplicate content against your own site.
Running tests against them
PR OPENED
→ preview deploys
→ E2E against the preview URL
— End-to-End Testing
→ Lighthouse against the preview
→ axe scan
→ visual diffs — Visual Regression Testing
See: End-to-End Testing · Visual Regression Testing
Testing against a real deployment catches what a local test can’t — CDN behaviour, real network, actual build output, environment configuration — Pipeline Design.
The costs
- Money. Compute, databases and build minutes per open pull request
- Complexity. Provisioning, seeding, teardown, secrets per environment
- Drift. A preview differing meaningfully from production gives false confidence — the closer they are, the more useful
- Cleanup. Environments that don’t destroy themselves accumulate cost and stale URLs
Set expiry aggressively — a preview for a pull request untouched for a week is waste.
The realistic position
Platform-provided previews are close to free — Vercel, Netlify and Cloudflare do this with no setup, and for a static or framework front end there’s little reason not to.
A full-stack preview with an isolated database is a real project, and the case for it strengthens with the number of non-engineers who need to see work before it ships. For a retail team with designers, merchandisers and marketers reviewing changes, that case is usually strong.