How to Secure Environment Variables in Vibe-Coded Apps

Quick answer

To secure environment variables in vibe-coded apps, never hardcode secrets or commit .env files. Use platform-native secret storage (e.g., Vercel Environment Variables, GitHub Secrets), validate with a secret leak scanner, and rotate exposed keys immediately. AI coding tools often generate code that references secrets directly—catch this before deployment.

What to check first

Before diving into fixes, run through this checklist to identify immediate risks:

Step-by-step fix

1. Remove hardcoded secrets from code

AI tools like Cursor or v0 often generate code with inline API keys. Replace them with environment variables:

// ❌ Bad: hardcoded secret
const stripe = require('stripe')('sk_live_1234567890abcdef');

// ✅ Good: use environment variable
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

2. Set up .env files correctly

Create a .env.local file for local development and add all keys there. Never commit it.

# .env.local (never committed)
STRIPE_SECRET_KEY=sk_live_...
OPENAI_API_KEY=sk-...
DATABASE_URL=postgresql://...

Add a .env.example to your repo with placeholder values so other developers know what's needed:

# .env.example (committed)
STRIPE_SECRET_KEY=your_stripe_secret_key
OPENAI_API_KEY=your_openai_api_key
DATABASE_URL=your_database_url

3. Use platform secret managers

If you're deploying on Vercel, use Vercel security scanner integration to monitor secrets. For local development, consider dotenv or direnv.

4. Rotate compromised keys

If you suspect a leak, revoke the key immediately and generate a new one. For example, with Stripe:

5. Add continuous monitoring

Set up continuous security monitoring to scan every commit and deployment for exposed secrets. This catches accidental leaks before they reach production.

Common mistakes

Mistake 1: Committing .env files

AI-generated projects often include a .env file in the initial commit. Always check your .gitignore before pushing.

Mistake 2: Using `.env` in production

Some developers copy .env to production servers. Instead, use the platform's environment variable configuration (e.g., Vercel, Heroku config vars).

Mistake 3: Exposing secrets in client-side code

In Next.js, variables prefixed with NEXT_PUBLIC_ are exposed to the browser. Never put secret keys there. AI code generation sometimes misses this distinction.

Mistake 4: Storing secrets in Docker images

Building a Docker image with secrets baked in makes them accessible to anyone who pulls the image. Use Docker secrets or environment variables at runtime.

Mistake 5: Sharing secrets via chat or email

AI assistants might suggest pasting keys into prompts. Never share secrets in plaintext—use a password manager or secure sharing service.

FAQ

How do I check if my .env file was committed?

Run git log --oneline -- .env in your repo. If you see commits, the file was committed. Use git filter-branch or BFG Repo-Cleaner to remove it from history.

What's the difference between .env and .env.local?

.env is typically used for default values and committed, while .env.local is for local overrides and should never be committed. Most frameworks load .env.local first.

Can I use .env in production on Vercel?

No—Vercel doesn't read local .env files in production. You must add environment variables through the Vercel dashboard or CLI. Use the Vercel security scanner to verify they're set correctly.