Secrets-Management

Every project I’ve touched in the last decade has a .env file. Sometimes it’s .env.local. Sometimes .env.development. Sometimes it’s the same file, committed to the repo, with a # DO NOT COMMIT comment at the top. That comment has never once stopped anyone. .env files are a solved problem that everyone keeps solving badly. The file format is fine. The habit of scattering them across projects, laptops, and Docker volumes — and then treating them like source code — is where things go sideways. A committed .env is a leaked secret. A .env emailed to a new teammate is a secret with no single point of revocation. A .env that lives on your laptop for two years is a secret you’ve forgotten about. ...

Every secret has to live somewhere. The only real questions are where, and for how long. I recently wired up automated pushes to this blog’s repo — a coding agent that commits and pushes on my behalf (more on why I trust an agent with that another time). That meant a GitHub Personal Access Token had to be available to a git push command running on my machine. What it did not mean was scattering that PAT across .env files and shell profiles. I wanted it managed: stored once, fetched at runtime, scoped, and revocable on demand. ...

The Backstory and Where We All Come From Passwords, private keys, and API keys are spread across systems and easy to compromise — that’s the normal situation in many environments. Most have rogue credentials scattered across servers, and the workforce still relies on passwords rather than moving toward Zero Trust IAM. This must change, and fast. We all know this problem exists somewhere in our environment. It’s easier in cloud or PaaS; even OpenShift or Kubernetes make it more manageable. But a broad, system-wide architecture with support for a wide selection of runtimes, operating systems, and cloud or on-prem server farms makes it hard. So hard, in fact, that I regularly stumble upon servers with plaintext files containing passwords, API keys, and certificates. ...