Vercel Redacts Secrets in Build Logs: What It Misses

If you deploy on Vercel, your build logs just got a bit safer: Vercel now replaces the value of any Environment Variable marked Sensitive with [REDACTED] before it prints to the deployment log, as long as that value is 32 characters or longer. I read the change on Vercel's own changelog, Build logs now redact Sensitive Environment Variable values, and I think the detail everyone will skip is the length rule.

Here's my take: this is a solid default, but it is not a shield. If you treat it as one, you will still leak keys. Let me explain what it actually does and where it stops.

---

🔍 What Vercel actually changed

The behaviour is narrow and specific. Three things happen when a value qualifies:

• The value is swapped for [REDACTED] in the Build Logs view.
• The log view tells you redaction happened, so you're not confused about why output looks masked.
• The Activity Log records the Environment Variable key, the project, and the deployment, but never the value itself.

Vercel also redacts some system Environment Variables it uses for deployment security. That part is automatic.

Key takeaway: Redaction only fires for variables you explicitly mark Sensitive whose value is 32+ characters. Nothing else is touched.

That last line is the whole story. This is opt-in, per-variable, and length-gated.

---

📏 The 32-character rule is the catch

Most real API keys and tokens are long, so the 32-character floor sounds harmless. But a lot of the things that leak in Sri Lankan side projects and small-team apps are shorter than that.

Secret type	Typical length	Covered by redaction?
Stripe / payment secret key	100+ chars	✅ Yes
JWT signing secret (generated)	64 chars	✅ Yes
OpenAI / Anthropic API key	~50+ chars	✅ Yes
Short DB password	8–16 chars	❌ No
6-digit OTP / PIN in config	6 chars	❌ No
Legacy 4-char service code	4 chars	❌ No

A weak database password like admin123 is exactly the kind of secret you most want hidden, and it is exactly the kind this feature ignores. The fix is not to complain about the threshold. The fix is to stop using short secrets. If a value is worth marking Sensitive, generate a long random one. A quick way is our password generator set to 32+ characters, which also clears the redaction bar by design.

---

🛠️ Why this matters more on free tiers

If you're a student or a two-person team, you probably do everything through the dashboard and copy-paste your build logs into a chat when something breaks. That copy-paste is where secrets escape. You share a failing log with a friend, a Discord server, or an AI assistant, and the key rides along.

Here's the honest risk order for a small builder:

1. Log sharing — pasting build output into public or semi-public channels.
2. Screenshots — a red error line with a full connection string in it.
3. console.log(process.env) in your own code during a panic debug.

Redaction helps with the first case, and only when your variable qualifies. It does nothing for the third, because that output comes from your application at runtime, not from Vercel's build system.

Marking a variable Sensitive changes how it's stored and shown, but it does not stop your own code from printing it. If you write console.log(apiKey), you own that leak.

---

💡 How to set this up properly

Turning it on is a one-time habit, not a big migration. My checklist:

1. In Project Settings, open Environment Variables.
2. For anything that is a real secret (keys, tokens, DB credentials), toggle it to Sensitive.
3. Make sure the value is long and random, not a memorable string.
4. Never log process.env wholesale. Log the keys you need, never the values.
5. If you must share a secret with a teammate, don't paste it in chat.

For that last point, I built a one-shot link tool for exactly this: one-time secret creates a link that self-destructs after a single view, so a leaked scrollback doesn't equal a leaked key. It's the safer alternative to dropping a token into WhatsApp.

And if you already suspect a key hit a log somewhere, rotate it. Redaction going forward does nothing for a secret that was printed last week before you enabled it.

---

🌐 The bigger pattern: platforms guessing at your intent

I like this change, but I want to name the trade-off. Vercel is inferring "this looks like a secret" partly from length. That is a heuristic, and heuristics have edges. A 20-character password sails through unmasked; a 40-character non-secret gets hidden. The platform is doing reasonable work on your behalf, and reasonable work is not the same as correct work for your specific case.

The lesson for anyone building on managed platforms:

• Defaults are floors, not ceilings. Good defaults reduce accidents; they don't remove the need to think.
• Know the exact rule. "Vercel hides secrets" is wrong. "Vercel hides Sensitive-marked values of 32+ chars in build logs" is right, and the difference is where you get burned.
• Own the runtime. No platform can stop your code from printing what you tell it to print.

---

What this means for you

If you ship on Vercel, spend ten minutes today marking your real secrets as Sensitive and confirming each value is long enough to trigger redaction. It's free, it's a genuine safety improvement, and it costs you nothing but a few toggles.

But keep the boundary clear in your head. This protects build logs, for long, explicitly marked values. It does not protect against short secrets, runtime logging, or careless sharing. Those are still your job.

Bottom line: Vercel just made it harder to leak long secrets by accident during builds. Use it, then generate proper secrets and stop logging values, because the platform's default only covers the mistakes it can guess at.