What Is Secrets Management? Protecting API Keys in AI-Built Apps

Why AI Coders Need This

Here's a pattern every vibe coder knows: You ask Claude or ChatGPT to build something that connects to Stripe, or OpenAI, or Supabase. The AI generates working code with placeholders like sk-your-api-key-here. You swap in your real key, the app works, and you move on to the next feature.

But where does that key live now? It's sitting right there in your source code. And if you git push that code to GitHub — even to a private repo that you later make public — that key is now on the internet. Forever.

Secrets management is the practice of keeping sensitive credentials out of your codebase and storing them safely. It's not complicated. It's not a "senior developer" topic. It's something you need from the very first time you use a real API key.

AI tools are incredibly good at building functional code. They are not good at thinking about what happens after you deploy. That's where you come in.

Real Horror Stories

These aren't hypothetical. These happen every single day.

GitHub's own security team reports that they detect millions of secrets leaked in public repos every year. In 2024, GitHub's secret scanning found over 39 million leaked secrets across public repositories. This isn't a niche problem — it's an epidemic.

What Counts as a Secret?

If someone could use this value to access your systems, charge your accounts, or read your data — it's a secret. Here's what you're probably handling:

Secret Type	Example	What Happens If Leaked
API Keys	sk-proj-abc123... (OpenAI)	Someone racks up charges on your account
Database Credentials	postgresql://user:pass@host/db	Full read/write access to all your data
JWT Secrets	jwt-signing-secret-xyz	Attackers forge authentication tokens, impersonate any user
OAuth Client Secrets	GOOGLE_CLIENT_SECRET=abc...	Attackers impersonate your app to OAuth providers
Webhook Signing Secrets	whsec_abc123... (Stripe)	Attackers send fake webhook events to your app
Encryption Keys	ENCRYPTION_KEY=aes256...	All encrypted data can be decrypted
SMTP Credentials	SENDGRID_API_KEY=SG.abc...	Spam sent from your email domain

Not secrets (safe to commit): PORT=3000, NODE_ENV=production, NEXT_PUBLIC_SITE_URL=https://myapp.com. These are configuration, not credentials. The test: would it cause damage if someone saw this value?

The .env File: Your First Line of Defense

A .env file is a simple text file that stores key-value pairs. Your app reads these values as environment variables at startup. Here's what it looks like:

# .env — NEVER commit this file
OPENAI_API_KEY=sk-proj-abc123def456ghi789
STRIPE_SECRET_KEY=sk_live_abc123def456
DATABASE_URL=postgresql://admin:s3cureP4ss@db.example.com:5432/myapp
JWT_SECRET=super-secret-jwt-signing-key-change-this
SENDGRID_API_KEY=SG.abc123.def456ghi789

Your code reads these variables instead of having keys hardcoded:

// ❌ NEVER do this
const openai = new OpenAI({ apiKey: "sk-proj-abc123def456ghi789" });

// ✅ Do this instead
const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

For this to work, you need to do two critical things:

Step 1: Add .env to .gitignore

Your .gitignore file tells Git which files to ignore. Add .env so it never gets committed:

# .gitignore
.env
.env.local
.env.production
.env*.local

Step 2: Create a .env.example file

This file does get committed. It shows your team (or future you) what variables the app needs — without the actual values:

# .env.example — Commit this. Copy to .env and fill in real values.
OPENAI_API_KEY=your-openai-api-key-here
STRIPE_SECRET_KEY=your-stripe-secret-key-here
DATABASE_URL=postgresql://user:password@localhost:5432/myapp
JWT_SECRET=generate-a-random-string-here
SENDGRID_API_KEY=your-sendgrid-api-key-here

When someone clones your repo, they copy .env.example to .env and fill in their own values. The code works, the secrets stay secret.

Platform-Specific Secrets: Where Your Production Keys Live

On your local machine, .env files work great. But when you deploy to production, you don't upload a .env file — you use your hosting platform's built-in secrets management. Every major platform has this:

Platform	Where to Set Secrets	How It Works
Vercel	Project Settings → Environment Variables	Set per-environment (Development, Preview, Production). Automatically injected at build time and runtime.
Railway	Service → Variables tab	Supports shared variables across services. Auto-generates DATABASE_URL when you add a database.
Netlify	Site Settings → Environment Variables	Available at build time. For serverless functions, use the same UI — they're injected automatically.
Supabase	Project Settings → API	Provides anon key (safe for client) and service role key (server-only). Never use the service role key in frontend code.
Render	Service → Environment tab	Supports environment groups for sharing secrets across services.
Fly.io	fly secrets set KEY=value	CLI-based. Secrets are encrypted at rest and injected as env vars.

The pattern is the same everywhere: you set secrets in the platform's dashboard or CLI, and the platform injects them as environment variables when your app runs. Your code uses process.env.SECRET_NAME the same way it reads from a .env file — it doesn't know or care where the value came from.

What AI Gets Wrong About Secrets

Tools for Secrets Management

For most vibe-coded projects, .env files plus your platform's environment variables are enough. But as your project grows, here's what the next level looks like:

Tool	What It Does	When You Need It
Doppler	Centralized secrets dashboard. Syncs secrets to all your environments and platforms automatically.	When you're managing secrets across multiple services (frontend, backend, workers) and tired of updating each one manually.
Infisical	Open-source secrets management. Similar to Doppler but self-hostable. Has a CLI, SDKs, and integrations.	When you want Doppler-like features but prefer open-source or need to self-host for compliance.
1Password Secrets Automation	Injects secrets from your 1Password vault into your app's environment. Great if you already use 1Password.	When your team already uses 1Password and you want one place for both personal passwords and app secrets.
HashiCorp Vault	Enterprise-grade secrets management with automatic rotation, audit logs, and fine-grained access control.	When you're running production infrastructure, need compliance audit trails, or manage secrets for multiple teams.

The Vibe Coder's Secrets Checklist

Every project. Every time. No exceptions:

✅ .env is in .gitignore BEFORE the first commit
✅ .env.example exists with placeholder values (committed to git)
✅ No API keys or passwords hardcoded anywhere in source files
✅ Secret keys are only used in server-side code (never in the browser)
✅ Different keys for development vs production
✅ Platform environment variables set for production deployment
✅ Keys rotated immediately if ever exposed
✅ ChatGPT/Claude conversations don't contain real API keys

That last one catches people off guard. When you paste your code into an AI chat to debug something, make sure you've redacted any real keys first. Replace them with sk_test_REDACTED or similar. AI doesn't need your real key to help you debug.

Quick Reference: The Complete .env Workflow

# 1. Create your project
npx create-next-app my-app
cd my-app

# 2. FIRST THING: Make sure .env is in .gitignore
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.production" >> .gitignore

# 3. Create .env with your real secrets (local only)
cat > .env << 'EOF'
OPENAI_API_KEY=sk-proj-your-real-key
DATABASE_URL=postgresql://admin:password@localhost:5432/myapp
STRIPE_SECRET_KEY=sk_test_your-test-key
EOF

# 4. Create .env.example for others (committed to git)
cat > .env.example << 'EOF'
OPENAI_API_KEY=your-openai-key-here
DATABASE_URL=postgresql://user:password@localhost:5432/myapp
STRIPE_SECRET_KEY=sk_test_your-stripe-test-key
EOF

# 5. Verify .env is ignored
git status
# .env should NOT appear in the list

# 6. Safe to commit
git add -A
git commit -m "Initial commit with .env.example"

Frequently Asked Questions