How to Store Vercel Environment Variables Secrets Safely

How to Store Vercel Environment Variables Secrets Safely

TL;DR: To store secrets safely in Vercel environment variables, never hardcode them in your codebase. Use Vercel's dashboard or CLI to add sensitive values as "Secret" environment variables, prefix them with a naming convention (e.g., SECRET_), and limit access by environment (Production, Preview, Development). For added security, use Vercel's built-in encryption at rest and rotate secrets regularly. Avoid committing .env files to version control and consider integrating a security scanner like OverMCP to detect leaked secrets early.

Why Vercel Environment Variables Are Not Automatically Secure

Vercel makes it easy to set environment variables via its dashboard, CLI, or vercel.json. However, many developers unknowingly expose secrets by:

While Vercel encrypts environment variables at rest (using AWS KMS), the real risk lies in how you handle them in your code. If a secret ends up in a client bundle, anyone can extract it from the browser's dev tools. For server-side secrets, a compromised dependency or a misconfigured next.config.js can leak them.

Step-by-Step Guide to Storing Secrets Safely

1. Identify Which Variables Are Secrets

Not all environment variables are secrets. Public values like NEXT_PUBLIC_ANALYTICS_ID are meant to be exposed. Secrets include:

2. Add Secrets via Vercel Dashboard (Recommended)

Vercel automatically encrypts the value. You can verify by editing the variable later — the value will be masked.

3. Use Naming Conventions

Prefix secret variables with SECRET_ or PRIVATE_ to differentiate them from public ones. For example:

This makes it clear which values should never be exposed to the client.

4. Access Secrets Only on the Server

In Next.js (the most common framework on Vercel), ensure secrets are only used in server-side code:

// ✅ Good: used in API route (server-side)
export default function handler(req, res) {
  const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
  // ...
}

// ❌ Bad: used in a component that runs on client
function CheckoutButton() {
  const stripe = Stripe(process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY); // public key is okay
  // NEVER use process.env.STRIPE_SECRET_KEY here
}

5. Never Commit `.env` Files

Add .env*.local and .env*.production to your .gitignore. For local development, use .env.local (which is gitignored by default in Next.js). Never commit .env files that contain real secrets.

6. Rotate Secrets Regularly

Set a calendar reminder to rotate secrets every 90 days. For critical secrets (e.g., database passwords), rotate immediately if you suspect a leak. Vercel makes it easy — just update the value in the dashboard.

7. Limit Access to the Vercel Team

Only give team members access to the Vercel project if they absolutely need it. Use Vercel's role-based access control (Owner, Member, Viewer) to restrict who can view or edit environment variables.

Common Mistakes and How to Fix Them

Mistake 1: Using Secrets in Client Components

// ❌ This exposes the secret in the browser
const secret = process.env.SECRET_API_KEY;

Fix: Ensure the component is a Server Component, or fetch the data from an API route that uses the secret.

Mistake 2: Committing `.env` with Real Values

# .env (committed to GitHub)
STRIPE_SECRET_KEY=sk_live_abc123

Fix: Use a .env.example file with placeholder values, and add .env to .gitignore.

Mistake 3: Using the Same Secret for All Environments

If your Preview environment gets compromised, an attacker could use the same secret in production.

Fix: Use different secrets per environment. Vercel allows you to set different values for Production, Preview, and Development.

How to Detect Leaked Secrets

Even with best practices, mistakes happen. A leaked secret can be detected by monitoring your codebase and public repositories. Tools like OverMCP can automatically scan your Vercel deployments and GitHub repos for exposed secrets, API keys, and tokens. They alert you before a breach occurs.

Frequently Asked Questions

Can I view a Vercel environment variable value after it's set?

No, once saved, the value is masked (shown as ********). You can only replace it, not view it. If you need to see the value, you must set it again.

Are Vercel environment variables encrypted at rest?

Yes, Vercel encrypts all environment variables at rest using AWS Key Management Service (KMS). They are decrypted only when needed by your application during runtime.

What's the difference between "Secret" and "Plain Text" environment variables in Vercel?

Vercel treats all environment variables as encrypted at rest. The "Secret" type (used when adding via CLI with --secret) is simply a flag that marks the variable as sensitive in the dashboard UI, but both types are encrypted. The main difference is that "Secret" values are masked in the dashboard and cannot be viewed after creation.

Conclusion

Storing secrets safely in Vercel environment variables is straightforward if you follow the principles: never expose secrets to the client, use naming conventions, limit access by environment, and rotate regularly. By combining Vercel's built-in encryption with good development practices, you can significantly reduce the risk of secret leaks. For an extra layer of protection, consider using a security scanner like OverMCP to continuously monitor your projects for exposed secrets.