Thanks for mentioning this, a coworker also pointed me to that feature after reading my post. I've since updated the top of the post with two things that stood out to me in the feedback here and on lobste.rs
Nice. One more benefit of this is when using LLM tools like Claude Code or Codex to do something and run tests on a worktree, this solution would work seamlessly.
> They sit on disk as plaintext, readable by any process running as your user
The proposed solution:
> Instead of loading secrets from a file, you use a wrapper script that fetches secrets from a secure store and injects them as environment variables into your process
Now they sit "on disk" as plaintext, in /proc/self/environ, still readable by any process running as your user.
This matches exactly what we've been building with KeyEnv (keyenv.dev). The core idea: secrets should never live in files on disk at all.
The CLI does `keyenv pull` to fetch encrypted secrets from the server, then `keyenv run` injects them as environment variables into your process. No .env file written, no plaintext ever touches disk, and your app reads process.env exactly like before.
The advantage over 1Password's approach (mentioned in another comment) is that KeyEnv is purpose-built for dev teams: secrets are scoped per project and environment (dev/staging/prod), team members get granular access, and there's a full audit trail. 1Password is great for personal secrets but gets awkward when you need per-project scoping across a team.
For the shell history concern someone raised: `keyenv run` never exposes the actual secret values to the shell — they go straight into the child process environment.
13 comments
[ 4.6 ms ] story [ 31.7 ms ] threadIt’s a whole toolkit for this - with built in validation, type safety, and extra protection for sensitive secrets.
The proposed solution:
> Instead of loading secrets from a file, you use a wrapper script that fetches secrets from a secure store and injects them as environment variables into your process
Now they sit "on disk" as plaintext, in /proc/self/environ, still readable by any process running as your user.
The CLI does `keyenv pull` to fetch encrypted secrets from the server, then `keyenv run` injects them as environment variables into your process. No .env file written, no plaintext ever touches disk, and your app reads process.env exactly like before.
The advantage over 1Password's approach (mentioned in another comment) is that KeyEnv is purpose-built for dev teams: secrets are scoped per project and environment (dev/staging/prod), team members get granular access, and there's a full audit trail. 1Password is great for personal secrets but gets awkward when you need per-project scoping across a team.
For the shell history concern someone raised: `keyenv run` never exposes the actual secret values to the shell — they go straight into the child process environment.