envault: A Boring Little Vault for .env Files
All projects (big, small, pocs, your-never-ending-project-thats-never-a-real-thing) deal with .env's.
The obvious answer is "store secrets properly", but local development is never that clean.
A .env file is often a messy, per-repo snapshot of how I currently run that specific thing on that specific machine at that specific time.
Some values are sensitive. Some are just annoying to reconstruct again. Most are not worth pushing through a whole organizational secret-management pipeline.
What I wanted was much smaller:
envault put dev
envault get dev
Store this repo's current .env file somewhere local, encrypted, and easy to recover later.
That is exactly what envault does.
"just use X"
There are already tools in this space, and many of them are good! The problem is that most of them solve a slightly different problem than the one I kept having.
direnv is great if you want environment variables to appear automatically when you enter a directory. I did not want that. I do not want shell hooks deciding when my process environment changes. I do not want a tool wired into every cd. I just want to say "save this env file" and later "put it back".
Automatic loading is cool, sure, but it also means the tool is always part of the shell session. For what I need most of the time thats unnecessary.
git-crypt is useful when encrypted files belong in the repo. That is also not what I wanted. My local .env files usually describe my local state, not the project's state.
If the secret belongs to the repo, sure, put it behind a repo-level encryption workflow and whatnot.
But if it is just my development database, my local ngrok callback URL, my local token for a test account, I do not want to teach Git aboit it.
pass and gopass can absolutely store this kind of data. They are super maturem flexible. But they also come with the shape of a password store: setup, sync decisions, key management, naming schemes, and a bigger mental model.
I wanted something self-contained. No separate password-store. No deciding where a blob named after this repo should live. No general-purpose secret manager either.
Then there is the oldest option: keep backups manually. Copy .env to .env.dev, zip it, paste it into notes, throw it into a private gist, or leave it in a random folder called old-envs-final-3.
That works until it does not, and when it fails it fails in the most boring possible way because you spend forty minutes reconstructing credentials instead of building anything.
envault
envault is narrow, dumb. It stores and retrieves per-repo environment files in a local encrypted vault.
The commands are boring on purpose:
envault put dev
envault get dev
envault get dev --force
envault list
envault where dev
The vault lives under:
~/.envault/<repo>/
The files are encrypted with age, using your SSH key by default:
ENVAULT_ROOT=~/.envault
ENVAULT_IDENTITY=~/.ssh/id_ed25519
ENVAULT_RECIPIENT=~/.ssh/id_ed25519.pub
It does not try to become a password manager.
It does not try to become a shell integration framework.
It does not try to become a deployment secret source.
It is a local encrypted shelf for the .env files I need to recover.
No hooks
It does not autoload variables.
It does not edit shell config.
It does not edit Git config.
It does not silently overwrite .env.
Restoring a local env file should be explicit. If there is already a .env in the repo, envault get dev should not casually replace it. When I really mean it, I can say:
envault get dev --force
Why local encryption is enough here
There is a specific kind of local development secret that lives in an awkward middle ground.
It is too sensitive to leave as plaintext in random backup folders. It is too specific and disposable to deserve a heavyweight shared secret-management flow. It belongs to me, to this machine, and to this repo.
Also, with all the supply-chain attacks targeting local dev machines, leaving a .env in a repo is 100% an avoidable risk.
If I want to back up ~/.envault, I can. If I want to keep it machine-local, I can. The important part is that the .env files are no longer floating around as plaintext accidents.
- I have a repo.
- The repo has a
.env. - I want to save that file under a name.
- I want it encrypted.
- I want to restore it later without surprises.
I appreciate programs that do not try to own the entire workflow.
envault put dev
envault get dev