DevOps & process
When we set up CI/CD for a project, preview deploys are almost always the first thing we configure — before tests, before linting, before anything else. That may sound backwards, but a clickable URL on every pull request changes the dynamics of code review more than any test suite.
This is not about impressing with DevOps jargon. It is about reducing the time you spend finding bugs that could have been caught earlier — and giving non-technical stakeholders a way to validate changes without installing anything locally.
TL;DR
Key takeaways
- Preview deploys on every PR give a unique URL where the change can be tested in a production-like environment — without touching production.
- Visual review catches UI bugs, layout breaks, and regressions that unit tests rarely find.
- Stakeholders can approve changes before merge — reducing rework after deploy.
- Vercel, Netlify, and Cloudflare Pages provide preview deploys out of the box for Next.js and static sites.
- A good pipeline also runs lint, type-check, and tests — preview deploys do not replace them, they supplement them.
What goes wrong without preview deploys
Without preview deploys, code review typically looks like this: the developer opens a PR, the reviewer reads the diff, maybe checks out locally if they have time and the right setup, and merges. Bugs in layout, styling, edge cases in data, and integrations with third-party services are discovered in production — or at best in staging, if you have a dedicated staging environment you actually use.
The problem gets worse when the team grows or when stakeholders outside development need to approve changes. A marketing lead cannot review a CSS change in a diff. A product owner cannot validate a new feature without running the project locally. The result is either blind trust or slow feedback loops.
Preview deploys solve both: every PR gets a unique URL, the change can be seen and tested immediately, and feedback comes before merge — not after deploy.
What a pipeline with preview deploys looks like
When a developer pushes to a feature branch and opens a pull request, the CI/CD pipeline triggers automatically: lint and type-check run first — that typically takes under a minute. If it fails, the pipeline stops and the PR cannot be merged.
Then the platform builds the project and deploys it to a unique preview URL — typically something like `feature-xyz-project.vercel.app`. The URL is posted automatically as a comment on the PR, so reviewers and stakeholders can click directly.
When the PR is merged to main, production deploys automatically. The preview URL may be kept for a period or deleted — depending on platform and configuration. The point is: production is updated only via main, and every change is tested in isolation first.
Preview deploys vs. traditional staging
Dedicated staging environment
One shared environment where all changes are tested sequentially.
- Known and familiar setup
- Can mirror production closely — same database, same config
- Only one version at a time — latest merge overwrites
- Requires coordination: who tests when?
- Often stale or out of sync with production
- Manual deploy or separate pipeline to staging
Preview deploys per PR
Unique URL for every pull request — parallel environments.
- Every change tested in isolation — no conflicts
- Automatic — no manual deploy
- Stakeholders can review simultaneously without waiting
- Environment is created and destroyed automatically
- Database and secrets require extra setup for full parity
- Platform-dependent — Vercel, Netlify, Cloudflare Pages
What you should have in place
A minimal CI/CD pipeline with preview deploys does not require much — but these things must be in place.
- Git hosting with pull requests (GitHub, GitLab, Bitbucket)
- Deployment platform with preview support (Vercel, Netlify, Cloudflare Pages)
- Lint and type-check in CI — failures block merge
- Environment variables configured for preview environments (API keys, database URLs)
- Branch protection: main can only be merged via PR with green CI
- Automatic comment on PR with preview URL (the platform typically does this itself)
- Documentation so the team knows the preview URL is there and should be used
Database and secrets in preview environments
The classic challenge with preview deploys is data: if your app reads from a production database, preview deploys will either hit production (dangerous) or fail (if access is blocked). The solution depends on the project.
For static sites and marketing sites it is rarely a problem — there is no database. For apps with a backend we typically recommend a dedicated preview database with seed data, or preview deploys pointing at a read-only copy of staging data. It requires extra setup, but it is worth it.
Secrets are handled via the platform's environment variable system: production secrets and preview secrets are separate, so a preview deploy never uses production API keys for writes.
Questions we get again and again
Which platform do you recommend for preview deploys?
For Next.js and static sites, Vercel, Netlify, and Cloudflare Pages are all good choices — they provide preview deploys out of the box with minimal configuration. The choice depends on your existing stack, budget, and whether you need edge functions, serverless, or a dedicated backend. We typically start with what you already use or what matches your hosting.
Do preview deploys cost extra?
Most platforms include preview deploys in their base plans. With many PRs and a large team it may require a paid plan — but the cost is typically far lower than the time you spend finding bugs in production.
Can we use preview deploys with our own server?
Yes, but it requires more setup. Docker-based solutions like GitHub Actions deploying to a container platform can provide preview environments, but it is not out of the box like Vercel or Netlify. For teams already running their own infrastructure it can make sense — otherwise a managed platform is often the faster path.
What about E2E tests — should they run against the preview URL?
They can, and it is a good idea for critical flows. Playwright and Cypress can run against the preview URL in CI and catch regressions automatically. It adds time to the pipeline, so we typically recommend it for checkout, login, and other flows where bugs are costly — not for every cosmetic change.
How long does setup take?
For a Next.js project on Vercel, preview deploys are typically active within a working day — connect repo, configure environment variables, set up branch protection. More complex setups with database seeding, E2E tests, and custom domains for previews take longer, but the foundation is quick to put in place.
If you want CI/CD set up properly
We are happy to talk about your current pipeline.
Write a few lines about what you run today — hosting, git flow, where bugs are typically discovered — and we will come back with a concrete assessment of what is most valuable to change first.