Secrets Management for a Vibe-Coded App
July 2026
When to use this: Your app has API keys, database credentials, or third-party tokens somewhere in it, and you're about to onboard real users — or you already have, and you've never actually checked where those secrets live.
Why this matters
AI coding tools default to the path of least resistance: a key gets pasted directly into a file during a debugging session, or dropped into a .env file that looks safe but was never actually checked against version control.
A leaked key isn't a cosmetic problem. It can mean a compromised database, someone else running up your OpenAI or AWS bill on your account, or direct access to customer data — and once a key has been pushed anywhere, even to a repository you've since made private, it has to be treated as compromised. Deleting it from the latest commit doesn't remove it from history.
Find every secret currently in your codebase
Search your source files directly, not just your .env file — AI-generated code sometimes hardcodes a key inline during a debugging session and it never gets cleaned up. Check config files, test files, and anything that looks like a script you ran once and forgot about.
Move every secret out of source code
Secrets belong in environment variables injected at runtime, never in a file that gets committed. If a value can unlock a database or an API account, it doesn't belong in a file that lives in version control.
Confirm your .env file is actually excluded from version control — don't assume it
This is the step people skip. The file can be correctly ignored right now while an earlier commit still has an older version of it sitting in your repository's history.
If a secret has ever been committed, rotate it — don't just remove it
Treat "it was in a commit at some point" the same as "it's compromised," regardless of whether the repository is private or how long ago it happened. Rotating the key is the only action that actually closes the exposure.
Use a secrets manager once you're past a single-developer project
Environment variables are fine for one person working locally. The moment you have more than one environment (dev, staging, production) or more than one person with access, a proper secrets manager is worth the small setup cost — it's far cheaper than the cost of a leak.
Keep secrets separated per environment
Development and production should never share the same database credentials or API keys. If a development key leaks, it should be able to touch development data only — not production.
Treat rotation as an ongoing habit, not a one-time cleanup
Decide now how often keys get rotated and who owns it. Most teams only start rotating keys after an incident, which is exactly backwards.
Common mistakes
Assuming .env was always gitignored. It's correctly excluded today, but nobody checked whether an earlier commit already leaked it into history. Check the history, not just the current state.
Sharing one set of credentials across every environment. It's simpler in the moment and it means a single leaked key can reach production, which defeats the entire point of having separate environments.
Treating this as done once it's fixed. Secrets management is a practice, not a task you complete. Without a rotation habit, you're one leaked key away from being back where you started.
Free Tool
Security Readiness Assessment — the full security picture beyond secrets
Continue reading
How to Add Authentication and Authorisation to a Vibe-Coded App
The Production Deployment Blueprint
Want the full security picture? Run the Security Readiness Assessment →
TechTekGo Newsletter
AI engineering insights — from prototype to production.
No noise. Published when there's something worth reading.