Skip to content

Vercel and Netlify

Copy a getmyenv context to Vercel or Netlify with npx getmyenv push. The CLI decrypts locally and uses your own platform token. Names-only diff and prune.

Last updated: 2026-10-05

How push works

Vercel and Netlify read environment variables from their own settings, not from run. push copies one context there.

  • The CLI decrypts locally and pushes with your platform token. Your token stays on your machine. We store a push record only.
  • That copy lives in Vercel or Netlify. Future changes in getmyenv are not pushed automatically. Run push again.
  • getmyenv manages the values. Vercel or Netlify decides how the deployment exposes them.
  • Read-only contexts push like run reads them: a trusted or approved machine, or a server token from an allowed IP. Only the owner sets Read-only values, in the dashboard.

Set up

Link the folder to the platform once with its own CLI, then set your token. Create a Vercel token in Account settings, Tokens, or a Netlify personal access token in User settings, Applications.

# macOS, Linux
vercel link
export VERCEL_TOKEN=<token>

netlify link
export NETLIFY_AUTH_TOKEN=<token>
# Windows PowerShell
vercel link
$env:VERCEL_TOKEN="<token>"

netlify link
$env:NETLIFY_AUTH_TOKEN="<token>"

vercel link writes .vercel/project.json. netlify link writes .netlify/state.json. Without them, pass --project and --team for Vercel, or --site for Netlify.

Check it works

--dry-run prints what would change, with names and types only, and writes nothing. It also says whether anything changed in getmyenv since the last push to that destination.

npx getmyenv push vercel -c production --dry-run

  + STRIPE_SECRET_KEY      sensitive
  ~ DATABASE_URL           sensitive
  + NEXT_PUBLIC_API_URL    readable

Then push. The CLI asks first. --yes skips the question.

npx getmyenv push vercel -c production
npx getmyenv push netlify -c production --target deploy-preview

Readable and sensitive

getmyenv stores no type on a variable. The CLI picks one from the name.

  • Names with a public prefix (NEXT_PUBLIC_, VITE_, PUBLIC_, NUXT_PUBLIC_, REACT_APP_, EXPO_PUBLIC_, GATSBY_) are pushed as readable. Names with a public prefix are inlined into the browser bundle at build time.
  • Every other name is pushed as sensitive: Sensitive on Vercel, secret on Netlify. The platform does not show the value again.
  • Vercel Development: the CLI asks for Sensitive. If Vercel refuses it, those variables are pushed as readable and listed after the push.
  • Netlify dev: values for local development are readable.
  • A public prefix on a value that looks secret prints a warning. Nothing is blocked.

Targets

  • Vercel: production (default), preview, development. Branch-specific Preview variables are left alone.
  • Netlify: production (default), deploy-preview, branch-deploy, dev. A variable with one value for all deploy contexts is not changed. Give it per-context values in Netlify first.
  • Names the platform sets or reserves (VERCEL_*, NETLIFY_*, AWS Lambda names) are skipped.

Prune

--prune also removes variables from the target that are not in the context. The CLI names every one before it asks, and with --yes it still prints the list.

  • Reserved and system variables are never removed.
  • On Vercel, a variable that also targets other environments only loses the pushed target. The others keep it.
  • When the platform cannot remove only the pushed target, the variable stays and is listed under Not pruned.
npx getmyenv push vercel -c production --prune --dry-run

In the dashboard

The context page shows where the context was last pushed, when and by whom, and how many names changed in getmyenv since. Changes made in Vercel or Netlify are not shown. A push record never means the platform matches getmyenv. Removing a record changes nothing on the platform.