Secure Vercel preview deployments and env vars

Every branch you push to a Vercel project gets its own URL. That is great for testing what the AI just generated, and risky if those URLs are open and wired to production keys. This guide covers the settings that matter.

Checked against the Vercel docs linked below on October 14, 2026.

1. Turn on Deployment Protection

Open your project, then Settings, Deployment Protection. Vercel offers several methods:

• Vercel Authentication: only team members, or people you send a shareable link, can open protected URLs. This is the recommended default.
• Password Protection: a shared password for protected deployments.
• Trusted IPs: only listed IP ranges get through, others see a 404.

And a scope:

• Standard Protection: protects every deployment except your production domains.
• All Deployments: protects production too, for internal tools that should never be public.

Check which plan includes which method in Vercel's pricing docs. At minimum, make sure preview URLs are not open to the world.

Note that with Standard Protection, the generated production URL is also restricted. If your code fetches from VERCEL_URL, point it at the domain the user requested instead.

2. Split Preview and Production env vars

Each variable is assigned to Production, Preview, and or Development. AI tools and quick setups often tick all three for every key. Instead:

Variable	Production	Preview
DATABASE_URL	production database	separate preview database
STRIPE_SECRET_KEY	sk_live_...	sk_test_...
OPENAI_API_KEY	production project key	separate key with a low budget
SUPABASE_SERVICE_ROLE_KEY	production project	staging project
CRON_SECRET	required for production cron auth (guide)	optional; crons do not run on previews

Preview variables can also be scoped to a single branch. A branch specific value overrides the general Preview value with the same name.

With the CLI:

vercel env ls production
vercel env ls preview
vercel env add STRIPE_SECRET_KEY preview   # paste the test key

3. Mark credentials as Secret

When you add a variable, choose Secret for API keys and tokens. Secret values are write only after saving, so they cannot be read back from the dashboard by anyone with project access. Use Config only for non sensitive values.

4. Mind the public prefix

Vercel stores variables securely, but your framework decides what reaches the browser. In Next.js anything named NEXT_PUBLIC_* is bundled into client JavaScript and readable by every visitor, on previews and production alike. Never give a secret that prefix. The same goes for files: a deploy should not publish a stray .env or public source maps (exposed .env, .git, and source maps). More in environment variables in Cursor, Bolt.new, and Lovable.

5. Rotate correctly

Changing a variable only affects new deployments. After a leak:

1. Create the new key at the provider.
2. Update the variable in Vercel and redeploy.
3. Revoke the old key at the provider, so older deployments that still contain it stop working.

See the first hour after an API key leaks.

Checklist

• Deployment Protection on, at least Standard Protection
• Preview uses its own database and test mode keys
• Credentials stored as Secret variables
• CRON_SECRET on Production if you use Vercel Cron (secure cron jobs)
• No secret with a NEXT_PUBLIC_ prefix
• Public repo checked with the VibeLocked scanner for keys committed by mistake
• If you set a Content-Security-Policy, preview deployments allow vercel.live so the Vercel Toolbar still loads

Sources

• Vercel: Deployment Protection
• Vercel: Methods to protect deployments
• Vercel: Environment variables
• Vercel: Managing environment variables across environments