Manage environment variables across Vercel environments and keep local .env in sync - vercel env pull/add/rm/ls, per-environment values (development/preview/production + custom), sensitive secrets, OIDC tokens for keyless cloud access, and the NEXT_PUBLIC build-time inlining gotcha. Use when someone says "sync my .env", "vercel env pull", "set a secret on Vercel", "my env var is undefined in production", "different API key per environment", "why is my NEXT_PUBLIC var stale", or "connect to AWS/GCP without storing keys". Do NOT use when the task is the deploy/promote/rollback flow - use vercel-deploy-pipeline; for routing AI provider keys through one gateway - use vercel-ai-gateway; for runtime/region/caching config (ISR, Fluid Compute) - use vercel-edge-and-isr; for blocking bots or WAF rules - use vercel-firewall-and-botid; for bundle/runtime speed tuning - use next-on-vercel-perf.
Click to play with sound.
---
name: Vercel Env Management
description: Manage environment variables across Vercel environments and keep local .env in sync - vercel env pull/add/rm/ls, per-environment values (development/preview/production + custom), sensitive secrets, OIDC tokens for keyless cloud access, and the NEXT_PUBLIC build-time inlining gotcha. Use when someone says "sync my .env", "vercel env pull", "set a secret on Vercel", "my env var is undefined in production", "different API key per environment", "why is my NEXT_PUBLIC var stale", or "connect to AWS/GCP without storing keys". Do NOT use when the task is the deploy/promote/rollback flow - use vercel-deploy-pipeline; for routing AI provider keys through one gateway - use vercel-ai-gateway; for runtime/region/caching config (ISR, Fluid Compute) - use vercel-edge-and-isr; for blocking bots or WAF rules - use vercel-firewall-and-botid; for bundle/runtime speed tuning - use next-on-vercel-perf.
---
# Vercel Env Management
Vercel is the source of truth for environment variables; your local `.env*` files
are a *cache* of it, not the other way around. This skill keeps that cache honest:
pull the right values for the right environment, add and remove vars without
leaking secrets into git, and use OIDC so you never paste a long-lived cloud key
anywhere. Get this wrong and you ship a preview build talking to a production
database, or a `NEXT_PUBLIC_` key that is stale because it was baked in at build.
This is one step in the **vercel-platform** ship-a-Next.js-app workflow. It is
deliberately *not* a transcription of the `vercel env` man page - it sequences the
commands into the order a real project needs them and flags the three mistakes
that actually cost people an afternoon. Pair it with `vercel-deploy-pipeline`
(which consumes these vars at build) and `vercel-ai-gateway` (which replaces a pile
of per-provider keys with one).
Trigger eagerly: "sync my env", "pull env vars", "set a secret", "env var is
undefined", "different value per environment", "my `NEXT_PUBLIC` var won't update",
"keyless AWS/GCP access", "OIDC token".
… install to load the full skill