Environment Variables and Secrets in AI-Built Apps
I tested this myself. Here is the honest take.
Why does the AI always hardcode secrets?
Security first: Learn how to properly manage environment variables and secrets.
The AI hardcodes secrets because that is what training data shows — public repos with hardcoded keys. It does not think about security. I found hardcoded database URLs in 8 out of 15 AI-generated projects. The fix: always add “use environment variables, never hardcode” to every prompt.
How do you set up env vars properly?
Proper setup: .env file for local development (gitignored), .env.example for documentation (committed), production env vars set through deployment platform UI. The AI can generate .env.example if you prompt for it. It will never generate it unprompted.
What is the .env.example pattern?
The .env.example pattern documents what variables your app needs without exposing values. The AI knows this pattern but only uses it if you ask. Add to your .cursorrules: “Always create a .env.example file with all required environment variables documented.”
AI hardcodes secrets in 53% of projects. Fix: “use environment variables” in every prompt. Setup: .env (local, gitignored) + .env.example (docs, committed) + platform UI (production).
The .env.example file is the single most impactful security practice for AI-built apps. It forces you to document what secrets exist. Without it, you will eventually forget a secret and hardcode it. I caught myself doing this 3 months into vibe coding. The file costs 2 minutes. It prevents incidents.
I need to [task]. Give me the exact steps and common mistakes.
References
- Production readiness
- Vercel deploy
- Railway deploy
- Deployment guide
How do you rotate compromised secrets safely?
If a secret leaks, immediate rotation is critical. Steps: (1) Generate a new secret value. (2) Update the deployment platform’s environment variables first (Vercel, Railway, etc.). (3) Restart the application so the new value takes effect. (4) Only then update the .env file locally. (5) Revoke the old secret in the service provider’s dashboard. This order prevents downtime — the server always has a valid secret during rotation. Never delete the old secret until you confirm the new one works across all environments.
What are the risks of committing .env files to version control?
Even with .gitignore, .env files leak constantly through three paths: accidental commits before .gitignore is set up, sharing screenshots of terminal output showing env vars, and CI/CD logs that print environment configuration. Mitigation: always use .env.example as your documentation source. Never commit actual .env files. In CI/CD pipelines, inject secrets through platform-native secret management (GitHub Actions secrets, Vercel environment variables). Add a pre-commit hook that scans for potential secret patterns (API_KEY=, SECRET=, TOKEN=) and blocks commits containing them.
How do you manage different environment configurations?
Every project needs at least three environments: development (local), staging (preview), and production (live). Each has different values for the same keys. Use environment-specific files: .env.development, .env.staging, .env.production. Most deployment platforms handle this natively — Vercel has separate environment tabs, Railway has separate projects per environment. The key principle: never share secrets between environments. Production database credentials should never exist in your development machine.
What are the best practices for documenting environment variables?
Your .env.example file is the most important documentation for other developers. Include: the variable name, its purpose (as a comment), the expected format, and whether it’s required or optional. Example: “# DATABASE_URL – PostgreSQL connection string. Required. Format: postgresql://user:pass@host:port/dbname. Get this from your hosting provider.” This reduces onboarding time from hours to minutes. Also document which variables can be left blank (optional features) versus which must always be set (core dependencies).
How do you prevent AI from hardcoding secrets in generated code?
Set explicit guardrails in your prompts: “Never hardcode API keys, passwords, or secrets. Always use environment variables from process.env or config files.” Add this to every prompt that generates code touching external services. If the AI still hardcodes something, catch it with a linting rule or pre-commit hook. My personal rule: if I see API_KEY= directly in source code, I reject the PR immediately regardless of how well the feature works. Security is non-negotiable.
What are the best practices for sharing env vars in team projects?
Use a shared secret manager for team projects instead of .env files. Tools like Doppler, 1Password CLI, or HashiCorp Vault provide secure, auditable secret sharing. Each developer gets temporary access to secrets through the CLI. Never share .env files via Slack, email, or chat. If someone needs to set up locally, they should run the secret manager’s auth flow, not receive credentials directly. For small teams without a secret manager, at minimum use encrypted .env files (git-crypt or sops) that decrypt on pull.
How do you audit secrets in your codebase regularly?
Schedule monthly secret audits. Use tools like gitleaks, trufflehog, or detect-secrets to scan your entire repository history for leaked credentials. These tools check every commit, not just the current state, catching secrets that were committed and later removed. Run the scan in your CI/CD pipeline to prevent future leaks automatically. Additionally, manually review any .env files, configuration files, and hardcoded strings in source code. For AI-generated code specifically, add a step to the code review checklist: “Verify no secrets appear in generated code.” This catches the most common AI mistake of hardcoding API keys and passwords.
What are the common patterns where AI leaks secrets?
AI leaks secrets in predictable ways. Pattern 1: Hardcoded API keys in example code (“Here’s how to call the API: const key = ‘sk-abc123’…”). Pattern 2: Including database connection strings in mock data. Pattern 3: Generating .env files with placeholder values that look like real credentials. Pattern 4: Copy-pasting from public repos that contain actual keys in training data. Prevention: Always review AI-generated code for credential-like strings before committing. Set up pre-commit hooks to catch these patterns automatically. When in doubt, replace any string that looks like a key with a placeholder and fill in the real value from your secret manager.
Leave a Reply