SecRefs expands declarative sec:// URIs directly in memory, at the moment they're used. Your vault stays the system of record - SecRefs resolves secrets, and never stores one.
Every plaintext secret that leaves your vault - into a .env file, a CI variable, a teammate's clipboard - is a copy you now have to track, rotate, and eventually leak. SecRefs replaces the copy with a pointer.
Put sec://aws/prod/db#password in .env instead of the plaintext password. It's safe to commit.
secrefs run -- node server.js intercepts your environment before your app boots.
Every sec:// value is fetched from its real vault concurrently, entirely in the CLI's memory.
The child process inherits a fully-hydrated environment. Nothing was ever written to disk - and a reference resolved at use time picks up a rotation without a restart.
Paste a mock .env, pick which lines are mock provider secrets, and watch SecRefs validate and expand them entirely in your browser's memory. Nothing here ever leaves your machine - there's no backend behind this sandbox.
Hit Expand to simulate resolving every sec:// reference above.
sec://aws/prod/db#passwordAmbient AWS credentials or an IAM role - never a static key in your config.
sec://vault/kv/stripe#keyKV v1 & v2, authenticated via VAULT_ADDR / VAULT_TOKEN already in your environment.
sec://bitwarden/stripe-keyEnd-to-end encrypted, decrypted client-side via a machine account token. Address a secret by name or UUID. Self-hosted instances supported.
sec://local/mock-db#passwordA gitignored .secrefs.local.json for teammates who don't have vault access yet.
A reference works just as well when the thing reading it isn't yours. Give a vendor sec://acme/stripe#key instead of the key, and they resolve it when they use it - so rotating at the source never breaks their integration, and revoking their access never touches anyone else's.
Their database stops holding your credentials. Yours stays the only place the value lives.