CI/CD & Deployment Pipelines' own domain covered per-environment secrets as something a pipeline must be deliberately configured to separate. Vercel builds the same separation directly into its dashboard as a first-class, three-way split — and the most common real mistake is forgetting which of the three a given variable actually needs.
Beginner
2 min read
The three environment types Vercel actually tracks
Production — the live site, the domain your real users hit
Preview — every branch/PR deployment (lesson 2)
Development — your local machine, running `vercel dev` or `next dev`
Every environment variable set in Vercel's dashboard is scoped to one, two, or all three of these — a variable can be set for Production only, for Preview only, for both, or for all three, and Vercel automatically injects the correct set depending on which kind of deployment is currently building.
Why this separation matters beyond just convenience
A real, concrete example this distinction exists to prevent: a preview deployment accidentally using a production payment-processor key, letting a QA tester's test checkout charge a real card, because nobody separated the two. Scoping STRIPE_SECRET_KEY to "Production" as the live key and a separate value to "Preview" as the processor's own test-mode key means every preview deployment is automatically, structurally safe to click around in — this is Web Security's own least-privilege principle, applied to which environment a secret is even reachable from, not just which service.
NEXT_PUBLIC_ prefix: the boundary between server-only and client-visible
// Server-only — never sent to the browser, safe for secretsprocess.env.DATABASE_URL// Sent to the BROWSER as part of the JS bundle — visible to ANYONEprocess.env.NEXT_PUBLIC_ANALYTICS_ID
Next.js (and therefore Vercel) treats any environment variable prefixed with NEXT_PUBLIC_ as intentionally exposed to client-side code, baked directly into the JavaScript bundle shipped to every visitor's browser — anything without that prefix stays server-only. Prefixing a genuine secret with NEXT_PUBLIC_ by mistake (a real, easy typo to make) ships that secret to every single visitor's browser, fully readable in plain text via browser dev tools — this is precisely the "secret baked into client-side code" leak path Web Security's own secrets-management lesson named directly, just with this specific, concrete mechanism behind it.
Pulling environment variables locally, safely
vercel env pull .env.local
Rather than manually copying environment variable values from the dashboard into a local .env file (a real, common way a value drifts out of sync, or a secret ends up pasted into a Slack message — exactly the insecure-channel leak path Web Security's secrets-management lesson also named), the Vercel CLI can pull the current values for a given environment directly, keeping local development in sync with whatever the dashboard actually has configured.