Skip to main content
The second line is safe to commit. SecRefs resolves it from your own vault at runtime — the value never lands on disk, in shell history, or in a CI log.

Bring your own vault

SecRefs is not a place to store secrets and never holds a copy of one. Your AWS Secrets Manager, Bitwarden, or HashiCorp Vault instance stays the single source of truth. SecRefs just knows how to read from it, and gives you a stable name for a value that’s free to change underneath.

Node.js quickstart

Install, write a reference, run your app through it.

Python quickstart

The same thing, for pip install secrefs.

Reference syntax

What sec://aws/prod/db#password actually means.

Troubleshooting

Start here when a reference won’t resolve.

Why a reference beats a copy

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. You cannot rotate what you cannot find. A reference inverts that. Rotate the value at the source and every consumer holding the reference picks it up, with no redeploy and no coordination. The name is stable; the value moves.
That guarantee depends on when you resolve. init() reads once at boot; expandString() reads at the moment of use. Only the second picks up a rotation without a restart — see Load time vs use time.