Preview and production are deployment environments, not guarantees about the services behind them. On Vercel, production is the version promoted to the live production domains. A preview is a non-production deployment created from a branch, pull request, or CLI deploy. The label tells you how the code was deployed. It does not prove which database, payment account, webhook endpoint, storage bucket, or email service that code can reach.
The reliable way to tell them apart is to check the deployment’s environment in the Vercel dashboard. The URL is useful evidence, but it cannot settle the question by itself: Vercel creates generated URLs for both preview and production deployments, and a generated production URL can still serve production code.
Preview vs production at a glance
| Preview deployment | Production deployment |
|---|---|
| Environment is labelled Preview in Vercel | Environment is labelled Production in Vercel |
| Usually created from a non-production branch or pull request | Usually created from the configured production branch or vercel --prod |
| Uses Preview-scoped and any branch-specific variables | Uses Production-scoped variables |
| May still reach production data if its credentials point there | Expected to reach live production services |
Vercel’s environment model defines Local, Preview, and Production, with Custom Environments available on Pro and Enterprise plans. Each environment can have its own variables. That separation exists only when somebody configures different values or restricts a connected resource to the intended environment.
Other hosts draw the same line with the same two words. Cloudflare Pages calls the deployment built from your production branch the production deployment and gives every other branch and pull request a preview deployment on a hash-prefixed pages.dev subdomain, public by default until you enable an access policy. The Cloudflare preview-to-production question has the same answer as the Vercel one: promoting the code does not promote the configuration behind it.
How to tell which Vercel environment you are looking at
Use these checks in order:
- Open the deployment in the Vercel dashboard and read its environment label. Trust
Production,Preview, or a custom environment name over a guess based on the address bar. - Check which branch and commit produced it. A production-branch commit can have both a production deployment and immutable generated URLs.
- Identify the URL type. Vercel documents a moving branch URL that points to the latest deployment on that branch and a commit URL that points to one exact deployment. Both sit alongside custom and production domains in the same project.
- If the application exposes a safe internal diagnostic, check
VERCEL_ENVor an equivalent server-side environment marker. Do not expose secrets or full connection strings to make this check easier.
Vercel’s generated URL reference is the reason the old shortcut fails. A custom domain usually points to production, while a branch-style URL usually points to a preview, but Vercel also generates a unique URL for production deployments. The dashboard label remains the authoritative answer.
What a preview isolates, and what it does not
A preview isolates a deployment of your code. Its commit-specific URL stays on that exact build for as long as the retention policy keeps it, while the branch URL moves when the branch gets another deployment. Neither form automatically clones every service the application uses.
Vercel lets one variable name hold separate Production, Preview, Development, custom-environment, or branch-specific values. Preview variables can apply to every non-production branch or one named branch. If DATABASE_URL has different values, the two deployments can reach different databases. If Preview and Production receive the same value, both deployments reach the same database.
Working out why one value set in one place makes identical code behave two ways is its own mechanism, covered separately. For this check, the important distinction is simple: the environment label selects configuration; the selected configuration determines what the deployment can reach.
A preview isolates a code deployment. Data is isolated only when its credentials and connected resources point somewhere other than production.
The same rule applies beyond the database. A preview can send real email, create live payment objects, consume paid model credits, or trigger production webhooks if its Preview-scoped values use those live accounts.
The version that kept turning up in the June and July 2026 audits is specific: a schema change or bulk edit was rehearsed against a preview URL, but that deployment still carried the production DATABASE_URL. The code build was disposable; every row it touched was live.
How to verify preview data isolation without risking production
Do not prove isolation by creating, editing, or deleting a row and waiting to see whether a customer notices. Verify the configuration first.
- In Project Settings, compare the environment scopes for database, storage, payment, email, and webhook variables. Confirm the scopes and destinations without copying secret values into notes or screenshots.
- Check each provider’s dashboard for the project, account, database, or mode named by the non-secret parts of the configuration. Stripe test mode, a staging database project, and a non-production email recipient policy are stronger evidence than a different URL.
- For Vercel Marketplace integrations, review the resource’s allowed environments. Vercel added a Production-only resource setting that can remove Development and Preview access to integration credentials.
- Add a harmless environment identifier such as
APP_ENV=previewand display it only in an authenticated diagnostic or server log. This confirms which configuration loaded without revealing the configuration itself. - Test with a dedicated preview account and reversible data. If the test account appears in the production admin or receives a production webhook, stop and correct the boundary before testing anything destructive.
This check covers environment reach, not the wider platform decision. A shared database behind two deployments is the same missing isolation described in one database, no staging, and a deploy set to break.
Preview vs staging
A pull-request preview and a persistent staging environment solve different problems. The preview shows one proposed code change. Staging gives a team a stable pre-production destination with its own data, integrations, access policy, and release path across many changes.
Vercel previews can support a quick code review, and a carefully configured preview can use isolated data. That still does not make every preview a durable staging system. Vercel’s Custom Environments are designed for longer-lived targets such as staging and QA on supported plans.
Building that separate environment is its own mechanical job. Whatever platform provides the deployment target, the database, storage, OAuth callbacks, webhooks, and third-party credentials still need deliberate non-production counterparts.
Protect the preview URL too
A preview may contain unreleased screens, test accounts, internal copy, or endpoints that should not be public. Generated deployment URLs are publicly accessible by default unless protection is configured. Vercel’s Standard Deployment Protection can require Vercel Authentication for generated and preview URLs while leaving the current production domain public, and that method is available on all plans.
Protection controls who can open the deployment. It does not change the database or credentials behind it. Access control and data isolation are separate checks.
What a clean preview proves
A successful preview proves that this build completed and that the paths you exercised worked under its current configuration. It does not prove production readiness, safe data isolation, rollback safety, or behavior under real traffic.
That difference appeared throughout AxonBuild’s fixed June and July 2026 study of 26 AI-built apps: none reached the green band even though each had a working application to inspect. The full ledger behind that number, and what it says about readiness beyond any one deploy, lives in its own study. Is your AI-built app ready to launch covers the wider evidence a passing preview cannot supply.
Common questions about preview vs production
What is the difference between deployment and production?
A deployment is one build of your code sitting at its own URL. Production is the environment label the host gives the deployment currently serving your live domains. Every production release is a deployment; most deployments never carry the production label, and the label is what selects which set of environment variables the build loads.
Is a Vercel preview deployment the same as staging?
No. A preview usually represents one branch or pull request. Staging is a persistent pre-production environment with stable configuration and isolated supporting services. A preview can be part of staging practice, but the generated URL alone does not create that system.
Does a Vercel preview use the production database?
Only if its Preview-scoped configuration or connected integration points to the production database. Vercel supports separate and branch-specific Preview values, but it does not infer or create an isolated copy of every external database automatically.
Can a generated vercel.app URL be production?
Yes. Vercel generates unique URLs for both preview and production deployments. A branch-shaped URL is a useful clue, but the deployment’s environment label in the dashboard is the reliable check.
Are Vercel preview deployments public?
Yes, unless you turn protection on. Anyone holding the generated URL can open a preview deployment, because Deployment Protection is a setting you switch on per project rather than a default. Search engines are not the usual exposure route: Vercel adds an X-Robots-Tag: noindex header to preview deployments automatically. A forwarded link is the route that matters, and Vercel Authentication with Standard Protection closes it on every plan.
Can I test safely on a preview URL?
You can test safely after confirming its data, payment, email, storage, and webhook destinations are non-production and its access is appropriately protected. A Preview label by itself is not that confirmation.
When every fix and release still depends on you
AxonBuild can trace the failure, repair the broken workflow, and ship the next change without rebuilding the parts that already work.
