Which Vercel env vars should be Secret? How to check yours

Vercel's docs split the two types by whether anyone can read the value back after saving. A Config value remains readable after saving for members with access, and the docs suggest Config for non-sensitive configuration such as public prefixes and values you may need to review later. A Secret value is write-only after saving. The August 24, 2026 changelog says the value remains available to your deployments and can be replaced, but members cannot view or retrieve it. The docs say to use Secret for passwords, API keys, and tokens. Vercel encrypts every value at rest either way. The type decides who can read it back.

In a typical vibe-coded app, that puts these in Secret: a Stripe secret key, a Supabase secret or service_role key, a model provider API key, a DATABASE_URL that contains a password, a session or JWT signing secret, an OAuth client secret, and a webhook signing secret. Config is for a site URL, a feature flag, an analytics ID, or the Supabase publishable key you already ship to the browser on purpose.

The type does not change what your code sends to the browser. Next.js inlines a NEXT_PUBLIC_ variable at build time into the JavaScript delivered to the client, replacing each process.env.NEXT_PUBLIC_... reference with a hard-coded value. Vercel's CLI docs say a variable with a public framework prefix, such as NEXT_PUBLIC_, is stored as Config. A credential under a public name is public no matter what label the dashboard shows. Rename it, read it only on the server, and rotate it. Secret keys shipped in the frontend and Public env vars, the Supabase anon key, and row level security cover that case.

On July 9, 2026, Vercel's changelog said build logs now replace a Sensitive variable's value with [REDACTED] when the value is 32 characters or longer. The section on build logs below has the current rule.

On August 24, 2026, Vercel replaced the Sensitive toggle with two types. When you add or edit a variable, you choose Config or Secret. The changelog says variables already marked Sensitive are treated as Secrets and keep working without migration, and that the environment variable list in the dashboard shows each variable's type and where it applies.

Secrets are allowed in Development now. The docs say this reverses the earlier rule that limited Sensitive variables to Production and Preview. In the CLI docs, a new variable defaults to Secret in Production, Preview, and custom environments, and to Config in Development. Because a Secret cannot be read back, vercel env pull keeps the real value already in your local file for that key. If the file has no real value, the CLI writes a placeholder for you to replace.

Two limits come with the write-only design. You cannot edit the key of a Secret after it is saved, and you cannot convert a saved Secret to Config in place. To store the same key as Config, delete the Secret and create a new Config variable.

The team policy changed too. The Enforce Sensitive Environment Variables policy is deprecated. It required every variable a team member created in Production and Preview to be Sensitive. The CLI docs say the CLI no longer enforces it. Its replacement is Separate Production Secret Values, an optional policy in the team's Security settings. A user with the Owner role can enable Require Separate Values. When it is on, each Secret must use a different value in Production than in Preview, Development, and custom environments, and the dashboard shows "Production must use a separate value." if you try to group Production with another target. The docs say teams that had the legacy policy enabled should review the new setting.

Vercel's security bulletin says: "As of October 16, 2026 at 10:19 AM PST, all remediation actions related to the security incident are complete, and the incident is closed."

The bulletin says the incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee. The attacker used that access to take over the employee's individual Vercel Google Workspace account, which gave them access to that employee's Vercel account. From there they pivoted into a Vercel environment and maneuvered through systems to enumerate and decrypt non-sensitive environment variables. The bulletin describes non-sensitive variables as those that decrypt to plaintext.

Vercel says it first identified a limited subset of customers whose non-sensitive variables were compromised, reached out to them, and recommended an immediate rotation of credentials. A broader review then found a small number of additional accounts compromised as part of the incident, and Vercel says it notified those customers. The same review found a small number of accounts with signs of compromise that appear to be separate from the April incident and do not appear to have originated on Vercel systems.

The bulletin's recommendations:

• Enable multi-factor authentication, with an authenticator app or a passkey.
• Review and rotate environment variables that were not marked sensitive. The bulletin says those values (API keys, tokens, database credentials, signing keys) should be treated as potentially exposed and rotated as a priority.
• Use the sensitive environment variables feature so secret values are protected from being read in the future.
• Rotate before you delete. The bulletin says deleting your Vercel projects or account is not sufficient, because compromised secrets may still provide access to production systems.
• Review the activity log for your account and environments.
• Investigate recent deployments for unexpected or suspicious ones, and delete any in question if in doubt.
• Set Deployment Protection to Standard at a minimum.
• Rotate your Deployment Protection tokens, if set.

The bulletin says "sensitive." Since August 24, 2026 that is the Secret type. Vercel's Deployment Protection docs say Standard Protection protects all deployments except production domains and is available on all plans.

The current docs say that during builds, if a Secret value is 32 characters or longer and appears in the build logs, Vercel replaces it with [REDACTED]. A shorter Secret is not replaced. Vercel's environment variables guide says shorter API keys need manual care to keep them out of logs. The docs describe this redaction for Secret values. A Config value printed in a build log stays readable there.

Vercel always redacts the VERCEL_AUTOMATION_BYPASS_SECRET and VERCEL_OIDC_TOKEN system variables from build logs, whatever their length. Each time it redacts a Secret, Vercel records an Activity Log event for the masked key with the key name, project, and deployment, but not the value. The July 9 changelog says the Build Logs view also indicates when redaction happened.

Do not print environment values in build scripts. Remove env, printenv, and any console.log(process.env) from package.json scripts and build config. If an old build log shows a credential in full, rotate that credential.