Production Vs Preview Deployments

Vercel uses deployment environments to separate work that is being developed, reviewed, and released. The most important distinction for beginners is Preview Deployments versus Production Deployments. A Preview Deployment is for testing and review before release. A Production Deployment is the version intended for real users on the production domain.

This distinction sounds simple, but many deployment mistakes come from blurring it. A developer shares a preview link as if it were private. A client approves work on a preview URL but nobody checks production after merge. A feature branch uses production API credentials. A production domain points at the wrong deployment. A team treats a successful build as proof that users saw the change. Learning the environment model early prevents those mistakes.

In Vercel, every deployment is a built version of your project. What changes is how that deployment is classified, which environment variables it receives, which URLs point to it, and how people should use it.

The Three Working Environments

Think in three layers: local development, preview, and production.

Local development happens on your machine. You run the project with a local dev server, edit files, and test quickly. Local development is fast and private to your machine, but it is not proof that the hosted deployment will work. Your machine may have different environment variables, Node versions, package-manager behavior, network access, or filesystem case sensitivity.

Preview is hosted by Vercel but is not the real production release. Preview Deployments are created for branches and pull requests so the team can inspect a proposed change. They are useful for design review, QA, stakeholder feedback, copy checks, and testing a build in Vercel's hosted environment before users see it.

Production is the real released environment. It is what the production domain should serve. Production should use production settings, production secrets, production databases, and production monitoring. Production deployments need extra care because mistakes affect users, customers, analytics, SEO, and business workflows.

A simple flow looks like this:

Local machine
  edit code
  run local checks
  commit changes

Preview Deployment
  created from branch or pull request
  reviewed by developer, teammate, or client
  not the final public release

Production Deployment
  created from production branch or promoted deployment
  served through production domain
  verified after release

That flow is the heart of modern Git-based deployment.

What A Preview Deployment Is For

A Preview Deployment gives you a real hosted URL for code that is not yet production. It answers a practical question: what will this branch look like if deployed by Vercel?

Use previews to check:

• layout and responsive behavior in a real browser;
• whether assets load from deployed paths;
• whether a frontend build succeeds outside your machine;
• copy, content, forms, and navigation changes;
• client or stakeholder feedback before merge;
• integration behavior against preview-safe services;
• whether a pull request is ready to merge.

Preview URLs are much better than screenshots because reviewers can interact with the page. They can click links, test forms, resize the browser, inspect errors, and compare the exact branch under review.

But preview does not automatically mean private. Unless protection is configured, a preview deployment may be accessible to anyone with the URL. Do not put unfinished confidential work, private data, customer records, credentials, or internal documents in a preview just because it is not production. Later lessons cover Preview Deployment Protection, but the safe assumption starts now: if a browser can load it, treat it as shareable unless you have verified protection.

What A Production Deployment Is For

A Production Deployment is the release intended for users. It should be connected to the production branch or deliberately promoted according to the team's workflow. It is usually what the custom production domain serves.

Production should have a higher bar than preview. Before production, confirm the expected branch, deployment status, environment variables, domain routing, and basic user-facing behavior. After production, open the production URL and verify the actual site, not only the Vercel dashboard.

A small production verification might be:

Deployment: completed successfully
Branch or commit: expected release commit
Domain: production domain loads the new version
Assets: CSS, JS, images load without 404s
Main path: homepage works
Critical path: contact form, checkout, login, or API smoke test works
Logs: no immediate runtime errors
Rollback plan: previous deployment is identifiable

For a course exercise, your production deployment may be a harmless generated Vercel URL. For real work, production is where plan choice, domain ownership, billing ownership, environment variables, monitoring, logs, and rollback become operational responsibilities.

Branches And Deployment Environments

With the GitHub workflow from the previous lesson, Vercel commonly uses the production branch for Production Deployments. The branch is often main, but a project can choose another branch.

Work from other branches usually creates Preview Deployments. Pull requests get preview URLs so reviewers can inspect the change before merge. After the pull request is approved and merged into the production branch, Vercel creates a Production Deployment.

The relationship is usually:

main
  -> Production Deployment

feature/header-copy
  -> Preview Deployment

pull request: feature/header-copy -> main
  -> Preview Deployment linked from the PR

merge into main
  -> new Production Deployment

This model keeps production calmer. The production branch should contain work that has passed the review process. Feature branches can change quickly and fail safely because they affect previews rather than the public production domain.

Generated URLs And Stable Domains

Vercel deployments receive generated URLs. These URLs are useful for previewing and identifying a specific deployment. A generated URL may contain the project name, team or account information, branch details, or a unique deployment identifier depending on the type of URL.

A generated URL is not the same as a production domain. A production domain is a domain you intentionally connect, such as example.com or www.example.com. The production domain should point to the current Production Deployment.

The difference matters during review. A client might approve a preview URL, but users will visit the production domain. After merge, someone still needs to verify the production domain. If the preview works but production points at an older deployment, the release is not complete.

Use URLs deliberately:

Preview URL
  share for review
  tied to branch, PR, or deployment
  may change as branch changes

Production domain
  user-facing address
  should represent released work
  needs post-release verification

Specific deployment URL
  useful for comparing or diagnosing a commit
  should not replace production-domain checks

Never paste private dashboard links, secret-bearing URLs, or internal credentials into public issue trackers. A preview URL is usually fine to share with intended reviewers, but think about who can access the content.

Environment Variables Differ By Environment

One of the biggest reasons to separate preview and production is configuration. Vercel lets projects use environment variables across environments. That means preview and production can use different API keys, database URLs, feature flags, email settings, and service endpoints.

For example:

Preview environment
  PAYMENT_MODE=test
  EMAIL_PROVIDER_API_KEY=test key
  DATABASE_URL=preview database

Production environment
  PAYMENT_MODE=live
  EMAIL_PROVIDER_API_KEY=live key
  DATABASE_URL=production database

Do not use production credentials in previews unless the project has a specific, reviewed reason. Preview code changes quickly and may include experimental logic. It should not accidentally send real customer email, charge live payments, overwrite production data, or call paid services at full scale.

Also remember that browser-exposed environment variables are public once included in frontend JavaScript. Frameworks such as Next.js use naming conventions for public variables. Later lessons cover this in detail. For now, the rule is: environment separation does not make browser secrets safe. Server-only secrets must stay server-side.

Preview Is For Feedback, Not Final Proof

Preview Deployments are excellent for review, but they are not identical to production. A preview may use different variables, a different domain, different protection settings, different data, and a different branch. It may not have the same traffic, caching behavior, analytics setup, or third-party service configuration as production.

Use preview to reduce risk, not to skip production verification.

A healthy review sequence is:

1. Developer tests locally.
2. Pull request creates Preview Deployment.
3. Reviewer tests preview URL.
4. Pull request is approved.
5. Branch merges into production branch.
6. Vercel creates Production Deployment.
7. Developer verifies production URL.

Skipping step 7 is common and dangerous. The merge might have included another change. Production variables might differ. The domain might route incorrectly. A service might reject the production domain. Always check the released site.

Client Review With Preview Deployments

Preview Deployments are especially helpful for client feedback. Instead of sending screenshots, you can send a URL for a specific change. The client can review copy, layout, navigation, and flow in the browser. Designers can inspect spacing. Developers can reproduce feedback against the same deployment.

Set expectations clearly:

This is a preview URL for review.
It is not the final production domain.
Please review the listed changes only.
Do not share it outside the review group unless we have agreed it is public.
After approval, we will merge and verify the production domain.

For sensitive client work, do not rely on politeness. Use deployment protection, authentication, or another controlled review environment. A generated URL can be forwarded. Search engines and bots are not the only risk; humans share links too.

Common Environment Mistakes

The first mistake is assuming preview is private. Treat preview links as accessible unless protection is configured and tested.

The second mistake is using production data in previews. A bug in a feature branch should not corrupt production records, email real customers, or trigger real payment flows.

The third mistake is merging without production verification. A preview proves the branch could deploy. It does not prove the production domain now serves the expected release.

The fourth mistake is letting production branch rules be vague. The team should know whether main, production, or another branch creates Production Deployments.

The fifth mistake is giving every reviewer production access. Many stakeholders only need preview links. Dashboard permissions, environment variables, billing, and production promotion should be limited to people who need them.

The sixth mistake is storing secrets in code to make previews work. Fix the environment variable setup instead. Committed secrets remain in Git history and may leak through forks, logs, local machines, or build systems.

A Practical Review Checklist

Before merging a pull request, check the preview:

Preview Deployment built successfully.
Preview URL opens in a browser.
Changed pages match the pull request.
No obvious console errors.
No missing assets.
Preview uses preview-safe services and data.
Reviewer notes are resolved.

After merging, check production:

Production Deployment built successfully.
Production domain loads the expected commit.
Critical user path still works.
Environment variables are production-appropriate.
Runtime logs show no immediate errors.
Rollback target is known.

These checklists are intentionally short. The point is to create the habit. Bigger projects can add automated tests, deployment checks, synthetic monitoring, analytics checks, and release runbooks.

Review Questions

• What is the difference between a Preview Deployment and a Production Deployment?
• Why is a preview URL better than a screenshot for review?
• Why should preview and production use different environment variables?
• Why does a successful Preview Deployment not remove the need for production verification?
• What should a client understand before reviewing a preview URL?
• Which branch creates Production Deployments in your project?

Official References

• Vercel Deployment Environments
• Generated Deployment URLs
• Deploying Git Repositories with Vercel