Vercel replaces the Sensitive toggle with Config and Secret types for environment variables

Vercel announced on August 24, 2026, in its changelog, a change to how environment variables are classified. The old Sensitive toggle (on/off) gave way to two explicit types: Config and Secret. The difference may seem cosmetic, but it changes how teams reason about secrets and reduces a common class of deploy error: accidentally exposing a value that should stay hidden, or the opposite, hiding a public URL that someone would need to inspect later.

What Config and Secret mean in practice

The two types solve opposite problems:

• Config: the value remains readable after being saved, for members with access. It's meant for non-sensitive values you might need to check later, such as variables with a public framework prefix (NEXT_PUBLIC_, VITE_, etc.).
• Secret: the value is available to deployments and can be replaced, but no member can view or retrieve the content after it's saved. It's the natural destination for passwords, API keys, and tokens.

The key point is that the distinction is no longer "sensitive or not" (a somewhat ambiguous binary state) but a semantic choice about what that value actually is. In practice, this aligns the tool with what teams were already doing mentally: a public API_URL should never get the same treatment as an API_KEY.

Anyone who already had variables marked as Sensitive doesn't need to do anything. According to the changelog, they're automatically treated as Secret and continue to work with no migration needed. It's a non-breaking transition, which is the right behavior for something that lives at the core of production deploys.

Changes to team policies

Here's the part that requires attention from anyone administering an organization on Vercel, because it involves a security policy that may be active today.

The Enforce Sensitive Environment Variables policy has been discontinued. When enabled, it required every variable created by a team member to be marked as Sensitive, including non-sensitive configuration. This created friction: a public URL would end up treated as a secret just to satisfy the rule. With the Config and Secret types, each member chooses the appropriate type per variable, so the policy no longer made sense.

In its place comes Separate Production Secret Values, available in the Security settings. When enabled, it requires that a Secret's Production value differ from the values used for the same key in Preview, Development, and custom environments. The logic is straightforward: it prevents the same real API key from leaking through an exposed preview deploy and compromising production, a known attack vector in public preview environments.

One thing to watch for: if your team had the old policy active, it's worth confirming whether the new Separate Production Secret Values should be turned on. Vercel notes that the old policy is no longer enforced by the CLI, so don't count on it as a safety net. Anyone relying on that guarantee needs to reconfigure it explicitly.

How to set types via the CLI

For scripts, CI pipelines, and automation, choosing the type now goes through the --visibility flag in vercel env add or vercel env update:

# Config
vercel env add API_URL production \
  --value "https://api.example.com" \
  --visibility config --yes

# Secret
vercel env add API_KEY production \
  --value "sk_live_..." \
  --visibility secret --yes

The old flags remain valid for compatibility. When --visibility is omitted, --no-sensitive maps to Config and --sensitive maps to Secret. After adding or updating a variable, the CLI output shows the type under the Visibility field.

For anyone maintaining provisioning scripts, the message is: there's no need to rewrite anything now, but when you do update those scripts, migrating to --visibility makes the intent more explicit and readable than the --sensitive / --no-sensitive pair.

What changes for devs deploying in Brazil

The concrete gain is reducing a category of silent error. Under the old toggle model, it was easy to leave an API key unmarked as sensitive (leaving it readable in the dashboard for any team member), or to mark a configuration variable as sensitive and then have no one be able to inspect it later when debugging a deploy. By forcing the choice between Config and Secret at creation time, the interface pushes the security decision to the right moment.

For small teams or agencies managing multiple client projects, the benefit gets lost in the noise of a single project but shows up at scale: dozens of variables per project, multiple people with access, and the difference between a visible and a hidden sk_live_ key is the difference between an incident and a normal day. The Separate Production Secret Values policy is also especially useful for anyone using preview deploys in a review workflow, a common scenario in teams working with Next.js and feature branches.

Where this doesn't make a difference

Let's be honest about the scope: for a solo developer with a personal project and three variables, this change is practically invisible, and there's no reason to touch anything, since the migration is automatic. The real value lies in teams with access control and in environments where preview deploys can be accessed by third parties.

It's also worth remembering that "Secret" on Vercel means members can't read the value after it's saved, not that it's end-to-end encrypted in a way that Vercel itself has no access to. For the most critical secrets, dedicated managers (such as an external secrets manager integrated via runtime) remain the recommended approach, and this change doesn't replace that. Vercel's full Environment Variables documentation covers the details for each environment and prefix.