Stop Trusting Developers to Remember .env Files

I've seen this play out twice now. A junior dev commits .env to Git. A bot scrapes it. Your API credits evaporate before you notice.

The problem isn't stupidity. It's that we keep designing systems that require perfect human behavior at scale. That doesn't work.

What Actually Happened

One client was running an AI-powered ERPNext module I built. Some developer pushed credentials to GitHub. Within 40 minutes, someone had spun up 200 API calls using their OpenAI key. $8K gone.

They blamed the dev. I blamed the architecture.

The Proxy Approach

I started injecting secrets at the application level instead of storing them anywhere near the code.

With Node.js projects now, I run a middleware layer that intercepts requests and injects credentials just-in-time. The application never sees actual API keys. It requests through a proxy that:

• Fetches secrets from a vault (AWS Secrets Manager, HashiCorp Vault, whatever)
• Validates the request origin
• Rate-limits per service
• Logs access (not the key, just that it was used)
• Rotates credentials automatically

For PHP projects in Seven CMS, I do something similar with environment variable managers and wrapper classes. The core never directly touches raw secrets.

For Startups

Don't get cute with security. Use:

• Pre-commit hooks that scan for secrets (git-secrets, detect-secrets)
• Vault systems from day one (free tier HashiCorp is enough)
• API keys as vault-fetched values, never in code or .env
• Automated credential rotation
• Alert on any vault access

The Red Hat model I use for my open source applies here: the core is hardened, security is baked in, not bolted on.

The Real Cost

It's not about one leaked key. It's about trust. Clients see a leak, they start auditing everything. I've lost projects over this.

Build systems that don't require developers to remember security theater. Make the secure path the path of least resistance.

Your developers aren't careless. Your architecture is just fighting them.