Infisical

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. ...