Three files, three owners
secretenv.toml in the repo lists alias names. Machine config names backend instances. The registry โ inside a backend you control โ maps aliases to backend URIs.
Read the model
One registry. Every repo. Every backend. Migrate without touching a single repo.
# macOS
brew install secretenv
# Linux / macOS (universal)
curl -sfS https://secretenv.io/install.sh | sh
# Cargo
cargo install secretenvsecretenv setup aws-ssm:///secretenv/registry --region us-east-1Output:
โ Registry configured as [registries.default]
โ Registry reachable: 12 aliases found
โ AWS credentials detected (profile: default)secretenv.toml to your project โ[secrets]
STRIPE_KEY = { from = "secretenv://stripe-key" }
DATABASE_URL = { from = "secretenv://db-url" }
LOG_LEVEL = { default = "info" }secretenv run -- npm startSecrets are fetched from whichever backends the registry points to, injected as env vars into the child process, and gone when it exits. No secret values written to disk.
The manifest says what the project needs. The machine config says which backends this machine has. The registry says which backend URI each alias resolves to.
Why the indirection?
Repos commit alias names like secretenv://stripe-key. The registry maps each alias to its current backend location. Migrating from 1Password to Vault becomes one secretenv registry set โ every repo picks it up on the next run, no PRs.
For the full schemas, validation rules, and 5-phase resolution flow: The Three-File Model โ Deep Reference.
.env, fnox, op-run, direnvTry it now
secretenv doctor is the front door for validating your config against any backend. Run it after install, after every config change, and as a CI pre-deploy gate.