Preview Environments for Every Branch: How They Work and What They Cost
A preview environment gives every branch or pull request its own live URL, so changes are reviewed running rather than read as diffs. How they work, the hard part (databases), the ways to get one, and why they matter more when an AI agent is writing the code.
A pull request shows you what changed. It doesn't show you whether it works.
For a one-line fix, reading the diff is enough. For a new checkout flow, a redesigned settings page, or anything a designer, a product manager, or a client needs to approve, the only honest review is clicking through the running thing. Preview environments exist for that: every branch gets its own deployment, at its own URL, automatically.
They used to be a luxury of teams with a platform engineer. Frontend hosts made them standard for static sites. For full-stack applications — with a backend and a database — they're still harder than they look. Here's how they work and where the difficulty actually is.
What a preview environment is
When a branch is pushed or a pull request is opened, the system:
- Builds the application from that branch.
- Deploys it somewhere isolated from production and from other branches.
- Gives it a unique URL — something like
feature-checkout.preview.example.com. - Posts the URL on the pull request.
- Updates the deployment on every new push.
- Tears it down when the branch is merged or closed.
Reviewers click a link instead of checking out a branch and running it locally. Non-developers can review at all.
The easy half: frontends
For static sites and frontend frameworks, preview deployments are a solved problem. Vercel, Netlify, and Cloudflare Pages all create a preview URL for every pull request with essentially no configuration. If your app is a frontend talking to an existing API, you probably have this already.
The difficulty starts the moment the branch changes something that isn't static files.
The hard half: backends and data
A full-stack preview needs everything production needs: the server process, environment variables, background workers, and — the difficult one — a database.
The database problem
Every approach to preview databases is a trade-off:
| Approach | Upside | Downside |
|---|---|---|
| Share staging's database | Simple, realistic data | Branches with migrations break each other — and staging |
| Empty database per preview | Fully isolated | Nothing to look at until you seed it |
| Seeded database per preview | Isolated, usable | Seed data drifts from reality; seeding takes time |
| Branch/clone of a real database | Realistic and isolated | Needs a database that supports cheap branching; real data may contain personal information |
The first option is the one teams start with, and it fails as soon as two branches each include a migration. Branch A adds a column; branch B renames a table; staging is now in a state neither branch expects.
For most applications, an isolated database per preview with good seed data is the practical sweet spot. Write a seed script that creates a realistic, anonymised set of records, run it on every new preview, and keep it in version control so it evolves with the schema.
If you do clone real data, scrub it. A preview URL is easier to share — and to leak — than a production dashboard.
The other problems
- Secrets. Previews need API keys, but not production's. Use test-mode keys for payment providers and a separate email sandbox, or previews will charge real cards and email real customers.
- Webhooks and callbacks. OAuth redirect URLs and payment webhooks are registered against specific domains. A new preview URL per branch needs wildcard redirects or a proxy.
- Cost. Every open pull request is a running application. Twenty open branches is twenty deployments. Previews should sleep when idle or be deleted promptly on merge.
- Cleanup. A preview system that creates environments reliably and deletes them unreliably will quietly become your biggest bill.
Ways to get preview environments
Frontend hosts (Vercel, Netlify, Cloudflare Pages): excellent for frontends, often with integrations for databases that support branching.
Application platforms (Render, Railway, Fly, and others): many offer preview or PR environments for full-stack apps, with varying support for per-preview databases. Check specifically what happens to the database — it's the detail that varies most.
Build it yourself on Kubernetes: a namespace per pull request, a database per namespace, and a wildcard DNS record and certificate in front. Very flexible, and a real project to build and maintain.
A development platform where the branch is the environment: rather than deploying a branch somewhere, the workspace the branch was developed in is already running, and gets a URL. The preview is not a separate artifact; it's the same environment the work happened in.
Why this matters more with AI agents
When a person writes a change, they've usually run it. When an agent writes a change, the pull request can look complete and plausible while the feature doesn't actually work — the agent may have tested it, or may have assumed.
A live URL per branch changes the review from "does this diff look right?" to "does this thing work?", and the second question is much harder to fool. It's also the thing that makes it realistic to review agent work from a phone: tap the link, click through the flow, approve or send it back.
It helps the agent, too. An agent that can load the preview, hit the endpoint, and read the real response can verify its own work before asking you to — which is most of the difference between an agent that's useful and one that needs checking at every step. That feedback loop is the argument we make in Why AI Coding Agents Need Persistent Workspaces.
A minimum viable setup
If you're setting this up for the first time:
- Automatic deploy per pull request, with the URL posted on the PR.
- An isolated database per preview, created fresh and seeded from a script in the repo.
- Test-mode secrets only — never production keys in a preview.
- Automatic teardown on merge or close, and a sleep-when-idle policy.
- HTTPS on every preview, via a wildcard certificate or automatic issuance.
Get those five right and previews become the default way your team reviews changes — which is where they're most valuable.
EasySpawn gives every branch a live URL with SSL, running in the workspace it was built in, with a managed database alongside it — so you review agent work by clicking through it, not by reading the diff. Preview deployments are included on the Pro plan. See pricing or join the waitlist.
Related: Running Claude Code Agents in Parallel With Git Worktrees · Agent Hosting Is Becoming Free. Here's What Isn't.
Keep reading
Agent Hosting Is Becoming Free. Here's What Isn't.
Anthropic now ships ways to keep Claude Code running without your laptop — Remote Control, cloud sessions, scheduled Routines. That's good news, and it changes what's worth paying for. The session is becoming a commodity. The environment the work ships into is not.
A Security Checklist for Vibe-Coded Apps
AI-built apps fail security in predictable ways: open databases, keys in the browser, authorization checked only in the UI. A practical checklist for non-security people — what to check, how to test it yourself, and what to fix before real users arrive.