Sensitive environment variables
When you add or edit environment variables, choose Config or Secret:
- Config values remain readable after saving for members with access. Use them for non-sensitive configuration such as public prefixes and other values you may need to review later.
- Secret values are write-only after saving. Use them for passwords, API keys, and tokens. Existing Sensitive environment variables continue to work as Secrets.
Both project environment variables and shared environment variables support Config and Secret types.
During builds, if a Secret environment variable value is 32 characters or longer and appears in build logs, Vercel replaces the value with [REDACTED]. Vercel always redacts the VERCEL_AUTOMATION_BYPASS_SECRET and VERCEL_OIDC_TOKEN system environment variables from build logs, regardless of value length.
When Vercel redacts a Secret value, Vercel records an Activity Log event for each masked environment variable key. The event includes the key name, project, and deployment, but not the value.
Environment variables can be created at the project or team level:
- Go to the Vercel dashboard and select your team from the team switcher. Open Environment Variables from the sidebar. For project-level variables, select the project first.
- Choose Config or Secret under Type.
- Fill in the key, value, and target environments. For Secrets, you can assign different values per environment or Preview branch.
- In the environment variable table, each variable shows a Config or Secret label.
To create an Authorization Bearer token, see the access token section of the API documentation.
The API accepts a single environment variable object or an array of objects. Both examples below send an array.
curl --request POST \
--url https://api.vercel.com/v10/projects/<project-id-or-name>/env \
--header "Authorization: Bearer $VERCEL_TOKEN" \
--header "Content-Type: application/json" \
--data '[
{
"key": "<env-key-1>",
"value": "<env-value-1>",
"type": "sensitive",
"visibility": "secret",
"target": ["<target-environment>"],
"gitBranch": "<git-branch>",
"comment": "<comment>",
"customEnvironmentIds": ["<custom-env-id>"]
}
]'For readable Config values, set "type": "encrypted" (or "plain") and "visibility": "config".
To create an Authorization Bearer token, see the access token section of the API documentation.
import { Vercel } from '@vercel/sdk';
const vercel = new Vercel({
bearerToken: '<YOUR_BEARER_TOKEN_HERE>',
});
async function run() {
const result = await vercel.projects.createProjectEnv({
idOrName: '<project-id-or-name>',
requestBody: [
{
key: '<env-key-1>',
value: '<env-value-1>',
type: 'sensitive',
visibility: 'secret',
target: ['<target-environment>'],
gitBranch: '<git-branch>',
comment: '<comment>',
customEnvironmentIds: ['<custom-env-id>'],
},
],
});
// Handle the result
console.log(result);
}
run();With the Vercel CLI, vercel env add and vercel env update send visibility on every create and update. Use --visibility config or --visibility secret, or pass --sensitive / --no-sensitive to infer the type.
You can edit the value and environment for any environment variable. You cannot edit the key of a Secret after it is saved.
For Config variables, authorized members can view the current value when editing.
For Secret variables, the current value is hidden. Provide a new value to rotate the secret. You cannot convert a saved Secret to Config in place.
- From your dashboard, go to the team or project and select Environment Variables in the sidebar.
- Click Edit from the three-dot menu.
- Update the value and target environments, then click Save.
The legacy Enforce Sensitive Environment Variables team policy is deprecated. That policy required every environment variable a team member created in Production and Preview to be stored as Sensitive, decryptable only during deployments. With Config and Secret types, you choose the right classification per variable instead of forcing everything to be a Secret.
It is replaced by Separate Production Secret Values, an optional team policy in Security settings. Users with the owner role can enable Require Separate Values.
When enabled, each Secret must use a different value in Production than in Preview, Development, and custom environments. You cannot assign Production the same secret value as another environment for the same key. The dashboard shows Production must use a separate value. when you try to group Production with another target.
Teams that had the legacy policy enabled should review the new setting after upgrading.
Existing Sensitive environment variables are treated as Secret in the dashboard and API. You do not need to migrate them manually. To store the same key as Config instead, delete the Secret and create a new Config variable. You cannot convert Secret to Config in place.
Was this helpful?