StrideLabs/Writing/Syncing .env files across my machines
Syncing .env files across my machines
Why I built a small, single-user CLI to keep .env files in sync across my machines and sheds, and why it may stay a stopgap rather than a full secret manager.
Most of my projects have a .env file or two that I do not want to commit, and that I do want on every machine I work from. For a long time I moved them around by hand, or rebuilt them from memory on a new machine. Envsecrets is the small tool I wrote to stop doing that, especially now that sheds are part of the workflow too.
The whole idea is to treat secret files the way git treats code, but kept out of the repo. A .envsecrets manifest lists the files to track. envsecrets push encrypts them with age and stores them in a Google Cloud Storage bucket with a version history; envsecrets pull brings them down on another machine. envsecrets status tells you which way you are out of sync, and envsecrets sync does the safe thing, refusing to silently clobber a change another machine made.
I deliberately kept it small. It is single-user, GCS and age only, and focused on .env files rather than trying to be a full secret manager. There are better tools if you want local encryption, multiple users, or real policy: 1Password, SOPS, a cloud secret manager. What I wanted was something I could install with one command on any machine, including inside a container or a Shed environment, that keeps my secret files in sync with a little history behind them.
This is the newest and simplest tool in the lab, and the one most likely to change shape. I was on the fence about sharing it at all, because a stronger secrets story may replace it later. For now it does the small job I needed.