Netlify Deploy Previews: Test Every PR Before Merging (2026)

Netlify Deploy Previews aren’t just a nice-to-have; they’re the silent guardians preventing broken code from ever reaching production.

Let’s see it in action. Imagine a pull request on GitHub for a small change to a blog post.

{
  "ref": "refs/pull/123/merge",
  "before": "a1b2c3d4e5f6...",
  "after": "f7e8d9c0b1a2...",
  "repository": {
    "name": "my-awesome-blog",
    "full_name": "my-company/my-awesome-blog",
    "html_url": "https://github.com/my-company/my-awesome-blog"
  },
  "pusher": {
    "name": "developer-jane"
  },
  "sender": {
    "login": "developer-jane"
  }
}

As soon as this webhook payload hits Netlify, a few things kick off automatically. Netlify identifies this as a PR event for your connected repository. It then spins up a fresh, isolated build environment. This environment pulls down the exact code from the merged state of that PR (the refs/pull/123/merge ref). It runs your configured build command (e.g., npm run build or hugo). Upon a successful build, it deploys this version of your site to a unique, temporary URL. This URL is then posted back to the PR as a comment, ready for review.

The core problem Deploy Previews solve is the "it works on my machine" syndrome and the blind merge. Developers can test changes in a production-like environment before they’re merged into the main branch, catching visual regressions, broken links, or functional bugs that might be missed in local development. It provides a concrete, shareable URL for designers, QA, or even stakeholders to preview and approve changes.

Here’s a breakdown of the key components you control:

• Build Command: This is the npm run build, yarn build, hugo, gatsby build, or whatever command Netlify executes to generate your static site. You define this in your Netlify site settings under "Build & deploy" -> "Build settings."
• Publish Directory: After the build command runs, Netlify needs to know which directory contains the static assets to serve. This is typically public, dist, build, or site. This is also configured in your "Build settings."
• Environment Variables: Any API keys, secrets, or configuration values your build process needs can be set as environment variables in Netlify’s UI. These are injected into the build environment, ensuring your preview builds have access to necessary data without being committed to code.
• Branch Deployments: While PR previews are temporary, you can configure Netlify to deploy specific branches (like main or develop) to persistent URLs. This complements PR previews by providing a stable URL for the latest tested code.

When a PR is closed or merged, Netlify automatically tears down the Deploy Preview. This keeps your Netlify dashboard clean and avoids accumulating old, irrelevant preview URLs. It’s a managed lifecycle that ensures resources are used efficiently.

Most people think of Netlify Deploy Previews as a way to catch bugs. But the real power lies in their ability to act as a collaborative staging environment, providing an objective, live version of exactly what a PR will introduce. This immutable snapshot, accessible via a unique URL, transforms subjective code reviews into objective, interactive validations, allowing teams to iterate faster and with greater confidence than ever before.

The next step is often setting up deploy notifications or integrating with other CI/CD tools.