/env

description: Manage Vercel environment variables. Commands include list, pull, add, remove, and diff. Use to sync environment variables between Vercel and your local development environment.

Vercel Environment Variables

Manage environment variables for the current Vercel project with safety rails to prevent secret leakage.

> **🔒 Never-Echo-Secrets Rule**: Environment variable **values** must never appear in command output, summaries, or conversation text. Only show variable **names**, **environments**, and **metadata** (created date, type). This rule applies to all subcommands.

Preflight

1. **CLI available?** — Confirm `vercel` is on PATH.

• If missing: `npm i -g vercel` (or `pnpm add -g vercel` / `bun add -g vercel`).

2. **Project linked?** — Check for `.vercel/project.json` in the current directory or nearest parent.

• If not found: run `vercel link` interactively, then re-run `/env`.

3. **Detect environment files** — Check for `.env`, `.env.local`, `.env.production.local`, `.env.development.local` in the project root. Note which exist for the diff subcommand.

Plan

Based on "$ARGUMENTS", determine the action:

| Argument | Action | Destructive? | |----------|--------|-------------| | `list` / `ls` / _(none)_ | List env var names per environment | No | | `pull` | Download env vars to local `.env.local` | No (overwrites local file) | | `add <NAME>` | Add a new env var | Yes (if production) | | `rm <NAME>` / `remove <NAME>` | Remove an env var | **Yes** | | `diff` | Compare local vs Vercel key names | No |

For any operation that mutates **production** environment variables (`add` or `rm` targeting production):

> ⚠️ **Production environment mutation requested.** > This will change environment variables on your live production deployment. > **Ask the user for explicit confirmation before proceeding.** Do not mutate production env vars without a clear "yes."

Commands

"list" or "ls" or no arguments

<!-- Sourced from env-vars skill: vercel env CLI > List Environment Variables -->

# List all environment variables
vercel env ls

# Filter by environment
vercel env ls production

Present results as a table of variable **names only** grouped by environment. **Never print values.**

| Name | Production | Preview | Development | |------|-----------|---------|-------------| | DATABASE_URL | ✓ | ✓ | ✓ | | API_KEY | ✓ | ✓ | — |

"pull"

<!-- Sourced from env-vars skill: vercel env CLI > Pull Environment Variables -->

# 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

After pulling, remind the user:

> Ensure `.env*.local` is in your `.gitignore` to avoid committing secrets.

"add \<NAME\>"

1. Ask the user which environments to target: production, preview, development (can select multiple). 2. If **production** is selected, require explicit confirmation (see Plan section). 3. Run the add command:

<!-- Sourced from env-vars skill: vercel env CLI > Add Environment Variables --> Every variable has a type:

| Type | After saving | Use for | |------|--------------|---------| | **Secret** | Hidden in the dashboard and `vercel env ls`; can be replaced, never read back. Production and Preview Secrets are not returned by `vercel env pull`. | Passwords, API keys, tokens, database URLs | | **Config** | Readable by members with access | Non-sensitive values you need to read later |

Deployments receive both types at build time and runtime. Secret and Config replaced the Sensitive toggle; existing Sensitive variables are Secrets.

# Interactive — prompts for value, environments, and type
vercel env add MY_SECRET

# Non-interactive: read the value from a file so it never lands in shell
# history or process arguments (echo "value" | ... and --value do both)
vercel env add MY_SECRET production < ./secret.txt

# Add to production and preview in one command
vercel env add MY_SECRET production,preview < ./secret.txt

# Set the type explicitly
vercel env add MY_SECRET production --type secret < ./secret.txt
vercel env add SITE_REGION production --type config < ./region.txt

# Add development in its own command; development-only adds default to Config
vercel env add MY_SECRET development < ./dev-secret.txt

# Update an existing value
vercel env update MY_SECRET production < ./secret.txt

• **Defaults**: a non-interactive add to production, preview, or a custom environment is stored as Secret.
• **Public prefixes are always Config**: variables such as `NEXT_PUBLIC_*` or `VITE_*` are exposed to browsers, so the CLI refuses `--type secret` for them. Keep a private value under a name without the prefix.
• **Flags**: `--type config|secret` needs Vercel CLI 59.6 or later. Older CLIs use `--visibility`, now a deprecated alias of `--type`. `--sensitive` (Secret) and `--no-sensitive` (Config) still work in every version.
• **Team policy**: **Separate Production Secret Values** requires a Production Secret to differ from the Preview, Development, and custom environment values of the same key. Under it, create separate Production and non-Production values instead of adding one value to all targets. It replaces the deprecated **Enforce Sensitive Environment Variables** policy.

The CLI will prompt for the value interactively — **do not pass the value as a CLI argument or echo it**.

"rm \<NAME\>" or "remove \<NAME\>"

1. If the variable exists in **production**, require explicit confirmation. 2. Run the remove command:

<!-- Sourced from env-vars skill: vercel env CLI > Remove Environment Variables -->

# Remove from specific environment
vercel env rm