Preview Deployments Explained - One Live URL for Every Branch

A preview deployment is a live, temporary copy of your app built from a specific Git branch, with its own URL. Push a branch called feature/new-checkout and, a few minutes later, anyone with the link can click through the new checkout in a real browser, without it touching production. Previews make code review, client sign-off and QA far easier. This guide explains how they work, what to watch out for (databases, secrets, search engines) and a simple workflow to adopt.

How preview deployments work

With push-to-deploy hosting, one branch (usually main) is connected to production. Preview deployments extend that to every other branch:

1. You push a branch other than the production branch.
2. The host builds it with the same install and build commands as production.
3. It starts the build on its own preview URL.
4. Each new push to the branch updates that preview.
5. When the branch is deleted, or goes stale, the preview is removed.

On NewHost, branch preview deploys are included on the Developer plan and up. Pushes to other branches deploy to their own preview URL, up to 5 previews per app, and a preview is removed automatically when the branch is deleted or after 14 days without a deploy. See pricing for plan details.

If you are new to branch-based deploys, start with Git push to deploy.

What previews are good for

Code review that includes the UI

Reviewers can read the diff and then click the real thing. Layout bugs, broken mobile views and awkward flows show up in minutes instead of after release.

Client and stakeholder sign-off

Agencies can send a client a link instead of screenshots. The client approves what they will actually get, and there is a clear record of which version was approved.

QA and testing

Testers can work on a feature in isolation, without waiting for a shared staging server to be free, and without one half-finished feature breaking another.

Safer dependency upgrades

Upgrading a framework version or a big dependency? Push it to a branch and run the preview side by side with production before merging.

Previews vs staging

Many small teams find previews replace a staging server entirely. Larger teams often use both: previews for each feature and a staging branch for the combined release.

Handling databases in previews

This is the part teams most often get wrong. A preview must never write to your production database. Options, from simplest:

1. A shared preview database with test data, separate from production. Good enough for most apps.
2. Seed data on build - run migrations and a seed script so each preview starts from a known state.
3. A database per preview - maximum isolation, but more to manage and clean up.

With Prisma, a preview build step might look like this:

npx prisma migrate deploy && npx prisma db seed && npm run build

Be careful with migrations: if a preview branch's migration runs against a shared preview database, it affects other previews too. Keep migrations backwards-compatible, or give schema-changing branches their own database. Our guide to Node.js with MySQL and Prisma covers migrations in more depth.

Secrets and environment variables

Previews should use their own, lower-privilege credentials:

• Payments - use your payment provider's test keys, never live keys.
• Email - send to a test inbox or a sandbox mode so customers never get a message from a preview.
• Third-party APIs - use sandbox accounts where they exist.
• Base URLs - read the site URL from an environment variable rather than hard-coding production, so links, redirects and OAuth callbacks work on the preview domain.

A common pattern is to set an APP_ENV=production variable only on production, and switch behaviour everywhere else:

const isProduction = process.env.APP_ENV === 'production';

// Outside production, redirect every email to a test inbox
export function recipientFor(to) {
  return isProduction ? to : process.env.TEST_INBOX;
}

export const paymentKey = isProduction
  ? process.env.PAYMENT_LIVE_KEY
  : process.env.PAYMENT_TEST_KEY;

Keep previews out of search engines

You don't want Google indexing half-built pages. Add a noindex header on non-production environments. In Next.js, next.config.js can do this:

/** @type {import('next').NextConfig} */
const nextConfig = {
  async headers() {
    if (process.env.APP_ENV === 'production') return [];
    return [
      {
        source: '/:path*',
        headers: [{ key: 'X-Robots-Tag', value: 'noindex, nofollow' }],
      },
    ];
  },
};

module.exports = nextConfig;

Also think about who can see a preview. If a feature is confidential, don't share its URL publicly, and avoid putting real customer data into preview databases - that data would still be subject to POPIA. See POPIA for developers.

A simple team workflow

1. Create a branch per feature: feature/quote-form.
2. Push early. The preview URL appears after the first build.
3. Open a pull request and paste the preview link into the description.
4. Reviewers check the code and the preview; the client signs off if needed.
5. Merge to main - production deploys.
6. Delete the branch - the preview is cleaned up.

Frequently asked questions

Do preview deployments cost extra?

It depends on the platform. On NewHost, branch preview deploys are included from the Developer plan (R249/month excluding VAT) upward, with up to 5 previews per app.

Can previews use a custom domain?

Previews normally run on a generated URL linked to the branch. Your custom domain stays pointed at production, which avoids any chance of a preview being mistaken for the live site.

How long does a preview stay online?

That varies by platform. On NewHost, a preview is removed when its branch is deleted or after 14 days without a new deploy.

Should previews connect to production data?

No. Use a separate database with test or seeded data, and test keys for payments and email. This protects your customers and keeps previews from causing real-world side effects.

Want per-branch previews for your Next.js or Node.js app on South African servers? See Next.js hosting or compare plans.