It’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.
That’s why I prefer programs that read all configuration from a file: this file can be dumped with fresh secrete value, read by the program and deleted right away once consumed.
Environment variables tend to be messy IMO
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.
The huge benefit is that if you are already using it for other stuff, there is no additional "secret zero" to set up - plus you get biometric unlock for your secrets.
Easiest way to use it for dev purposes is varlock (although I'm biased since I created it).
Where we saw friction was in CI/CD and multi-service setups. 1Password's op CLI adds ~2-3s per secret fetch, which compounds in pipelines with dozens of env vars. KeyEnv batches the pull so it's one round-trip regardless of how many secrets you need.
The other gap we kept hitting: onboarding a new team member. With 1Password you need to set up vault access, service accounts, and teach them the op run workflow. With KeyEnv it's `keyenv pull` and you're done — access is scoped per project and environment, so you grant access once and they get exactly the secrets they need.
Varlock's approach of bridging 1Password into dotenv workflows is clever though. For teams already deep in the 1Password ecosystem, that's probably the lowest-friction path.
Usually I do ^ while setting it as a variable, then I can still save the regular command to the history without the secret.
