Env Vars
Manage Vercel .env conventions, vercel env CLI, and OIDC tokens so preview and production secrets stay consistent and chain into AI Gateway when provider keys appear.
Overview
env-vars is an agent skill most often used in Ship (also Build, Operate) that manages Vercel .env files, vercel env CLI commands, OIDC tokens, and environment-specific configuration.
Install
npx skills add https://github.com/vercel-labs/vercel-plugin --skill env-varsWhat is this skill?
- Covers .env hierarchy, .env.local, production vs development files, and .env.example conventions
- CLI patterns for vercel env pull, add, rm, and ls workflows
- Retrieval aliases for secrets, config vars, and OIDC entity matching
- chainTo loads ai-gateway when OPENAI_API_KEY, ANTHROPIC_API_KEY, or GOOGLE_API_KEY is detected
- OIDC token lifecycle guidance for Vercel-managed auth instead of only manual API keys
- chainTo targets ai-gateway when OPENAI_API_KEY, ANTHROPIC_API_KEY, or GOOGLE_API_KEY patterns match
- Path patterns cover .env, .env.local, .env.production, .env.development, and .env.example variants
Adoption & trust: 270 installs on skills.sh; 187 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your preview and production configs drift because .env files, Vercel dashboard vars, and provider API keys are managed ad hoc without a documented hierarchy.
Who is it for?
Solo builders launching on Vercel who need vercel env pull discipline and automatic nudges toward AI Gateway when legacy API keys show up in .env.
Skip if: Projects hosted entirely off Vercel with no vercel env workflow or teams using only platform-native secret managers with no local .env files.
When should I use this skill?
Working with .env files, vercel env commands, OIDC tokens, or environment-specific configuration on Vercel.
What do I get? / Deliverables
Secrets and config vars follow Vercel’s env file and CLI conventions with a clear path to OIDC or gateway auth when AI provider keys are detected.
- Aligned .env.example and environment-specific file layout
- Documented vercel env CLI steps for pull, add, and list operations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Environment pull and secret hygiene peak right before and during launch to Vercel, even though .env files are edited earlier in build. Launch prep on Vercel is when wrong env scopes or committed secrets cause failed deploys and leaked keys—this skill targets that gate.
Where it fits
Create .env.example listing required vars without committing .env.local values.
Run vercel env pull before a release candidate deploy so preview matches production variable names.
Audit .env.* files for provider keys and let chainTo surface ai-gateway OIDC guidance.
Rotate compromised keys using vercel env rm/add with documented scopes for each environment.
How it compares
Use instead of copying .env.local snippets from blog posts that ignore Vercel environment scoping and OIDC options.
Common Questions / FAQ
Who is env-vars for?
Indie developers and tiny teams deploying to Vercel who manage secrets across .env files, the dashboard, and CLI and want agent help that matches official env var docs.
When should I use env-vars?
During Build when authoring .env.example; during Ship and Launch when pulling or adding vars before deploy; during Operate when rotating keys or fixing preview-only misconfigurations.
Is env-vars safe to install?
It touches secrets and env files—never commit real keys the agent suggests placing locally; review the Security Audits panel on this Prism page and your gitignore before automation runs.
Workflow Chain
Then invoke: ai gateway
SKILL.md
READMESKILL.md - Env Vars
# Vercel Environment Variables You are an expert in Vercel environment variable management — `.env` file conventions, the `vercel env` CLI, OIDC token lifecycle, and environment-specific configuration. ## .env File Hierarchy Vercel and Next.js load environment variables in a specific order. Later files override earlier ones: | File | Purpose | Git-tracked? | |------|---------|-------------| | `.env` | Default values for all environments | Yes | | `.env.local` | Local overrides and secrets | **No** (gitignored) | | `.env.development` | Development-specific defaults | Yes | | `.env.development.local` | Local dev overrides | **No** | | `.env.production` | Production-specific defaults | Yes | | `.env.production.local` | Local prod overrides | **No** | | `.env.test` | Test-specific defaults | Yes | | `.env.test.local` | Local test overrides | **No** | ### Load Order (Next.js) 1. `.env` (lowest priority) 2. `.env.[environment]` (development, production, or test) 3. `.env.local` (skipped in test environment) 4. `.env.[environment].local` (highest priority, skipped in test) ### Critical Rules - **Never commit secrets** to `.env`, `.env.development`, or `.env.production` — use `.local` variants or Vercel environment variables - `.env.local` is always gitignored by Next.js — this is where `vercel env pull` writes secrets - Variables prefixed with `NEXT_PUBLIC_` are exposed to the browser bundle — never put secrets in `NEXT_PUBLIC_` vars - All other variables are server-only (API routes, Server Components, middleware) ## vercel env CLI ### Pull Environment Variables ```bash # Pull all env vars for the current environment into .env.local vercel env pull .env.local # Pull for a specific environment vercel env pull .env.local --environment=production vercel env pull .env.local --environment=preview vercel env pull .env.local --environment=development # Overwrite existing file without prompting vercel env pull .env.local --yes # Pull to a custom file vercel env pull .env.production.local --environment=production ``` ### Add Environment Variables ```bash # Interactive — prompts for value and environments vercel env add MY_SECRET # Non-interactive echo "secret-value" | vercel env add MY_SECRET production # Add to multiple environments echo "secret-value" | vercel env add MY_SECRET production preview development # Add a sensitive variable (encrypted, not shown in logs) vercel env add MY_SECRET --sensitive ``` ### List Environment Variables ```bash # List all environment variables vercel env ls # Filter by environment vercel env ls production ``` ### Remove Environment Variables ```bash # Remove from specific environment vercel env rm MY_SECRET production # Remove from all environments vercel env rm MY_SECRET ``` ## Bootstra