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.
.env with no secrets in it is just a file.Which means you can keep one, and copy it into every new project. Same OpenAI key, same Supabase project, same Stripe test keys — declared once, pointed at from everywhere, and never actually duplicated.
Rotate one of those keys and every project you've ever started picks it up. There is no list of old prototypes to go back through, because none of them ever had a copy.
Where this works today: anywhere you run the process — local dev, a container, CI, a coding agent on your machine.
Where it doesn't, yet: hosted builders like Lovable or v0 run your app in their environment, so they would have to resolve the reference on your behalf. That is the same thing we are asking vendors for, and it is not built. The design is public if you work on one of these and it sounds useful.
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.