Vercel Stops Printing Your Secrets Into Build Logs

Vercel now redacts Sensitive Environment Variable values from build logs automatically, the company said in a changelog entry dated July 9, 2026. A value 32 characters or longer that would otherwise print to the log is replaced with [REDACTED], closing off a leak that could hand a database password or API key to anyone with log access (Vercel changelog, July 9, 2026).

---

What changed

Sensitive Environment Variables aren’t new. Vercel introduced the variable type in February 2024 so a value could be encrypted and locked from readback outside of builds (Vercel changelog, Feb 1, 2024). What was missing was log hygiene: if a build script echoed a sensitive value, printed it while debugging, or a dependency dumped its environment on a crash, that value still landed in plain text in the build log, ready to be copy-pasted into a support ticket or a Slack thread.

The new redaction closes that gap during the build step itself. Two system variables, VERCEL_AUTOMATION_BYPASS_SECRET and VERCEL_OIDC_TOKEN, are always redacted regardless of length. The Build Logs view flags when a redaction happened, so a team can tell the difference between a masked secret and a build that silently failed. Vercel also writes an Activity Log entry recording which variable key was redacted, and in which project and deployment, never the value itself (Vercel docs, Sensitive environment variables).

Team owners can go further with an org-wide policy: under Settings, then Security and Privacy, an “Enforce Sensitive Environment Variables” toggle makes every newly created Production and Preview variable sensitive by default. With the policy on, the Vercel CLI applies the same rule before it creates a variable and prints a one-line notice confirming it did.

---

Why this matters

Build logs are one of the more casually shared artifacts in a deploy pipeline: pasted into a bug report, screenshotted for a teammate, retained by CI for weeks after anyone remembers what’s in them. A secret that leaks there doesn’t need a breach to become a liability; it just needs someone with legitimate log access and bad judgment, or a log retention policy nobody thought to scope. Automatic redaction moves the fix from “hope developers never echo $DATABASE_URL” to a platform guarantee that doesn’t depend on any one script behaving.

The 32-character floor is a reasonable line for API keys and tokens, most of which clear it by design, but it also means a short, high-value secret, a 16-character API key or a PIN-style credential, still prints unmasked. Teams with those should still avoid intentionally logging any Sensitive Environment Variable and lean on the enforce policy so new variables get the encryption-at-rest protection by default, not just the log redaction.

Key Takeaways

• Vercel now replaces Sensitive Environment Variable values of 32+ characters with [REDACTED] in build logs, effective July 9, 2026.
• Two system variables are always redacted regardless of length; every redaction is logged to the Activity Log by key, project and deployment, never by value.
• An org-wide “Enforce Sensitive Environment Variables” policy, in Settings under Security and Privacy, makes new Production and Preview variables sensitive by default and extends the same behavior to the CLI.
• The redaction only covers values 32 characters or longer. Shorter secrets still need to stay out of logs by discipline, not by platform guarantee.