Netlify Deploy Previews: How They Work and How to Set Them Up

Deploy previews are probably the feature that sold me on Netlify in the first place. The idea is simple: every pull request gets its own live URL with a fully built version of your site. No more "can you pull my branch and run it locally?" — just send a link.

What's a deploy preview?

When you open a pull request, Netlify automatically clones that branch, runs your build, and publishes the result to a unique URL. It uses the exact same build process as production, so what you see in the preview is what you'll get when you merge.

The URL looks something like:

https://deploy-preview-42--your-site-name.netlify.app

The number matches the PR. Every new commit updates the same preview, so reviewers always see the latest version without doing anything.

Why this matters more than you'd think

Before I started using deploy previews, code review meant one of two things: reading a diff on GitHub and hoping the layout was fine, or asking someone to clone the branch and run it locally. Both suck for different reasons.

Deploy previews fix this because:

• Designers can actually review the UI without touching a terminal
• Content editors can check their copy in context, not in a CMS preview pane
• You catch layout bugs before they hit production — broken responsive layouts, missing images, weird spacing
• Multiple PRs can be reviewed in parallel without anyone running anything locally

I've found they completely change the review culture on a team. When non-developers can click a link and see the changes, they actually do it.

Setting them up

Good news: deploy previews are usually on by default. But if you want to double-check:

1. Open your site in the Netlify dashboard
2. Go to Site settings > Build & deploy > Deploy contexts
3. Make sure deploy previews are enabled

That's it. Netlify handles the rest through your Git provider integration (GitHub, GitLab, or Bitbucket).

Environment variables in previews

Sometimes you want previews to behave differently from production — maybe use a staging API, turn off analytics, or enable debug logging.

Netlify lets you set environment variables per deploy context. Go to Site settings > Environment variables, and when adding a variable, select the Deploy previews context to give it a different value than production.

This is one of those features you don't think you need until you're debugging why your preview is hitting the production API.

Preview URLs are public (sort of)

The URLs are technically public, but they're hard to guess — you'd need to know the site name and deploy number. For most teams, that's fine.

If you need actual protection, check out password protecting your Netlify site. On Pro plans, you can password-protect all deploys including previews.

Cleanup happens automatically

When a PR is closed or merged, Netlify removes the deploy preview. You don't need to manage any of this. Your dashboard stays clean, and you're not burning resources on previews nobody's looking at anymore.

Tips from using these daily

A few things I've learned from using deploy previews on every project:

• Drop the preview link directly in the PR description — saves people from scrolling to find it in the Netlify bot comment
• Set preview-specific env vars for staging APIs — you don't want preview deploys talking to production services
• Encourage non-developers to review previews — this is the whole point; make it part of your process
• Don't forget that preview deploys cost credits — on the free plan (300 credits/month), each preview deploy is 15 credits, same as production

Once you start using deploy previews regularly, it's hard to go back to reviewing changes any other way.