The leaked-key drill that never happens
A laptop is lost, a repo goes public. Nothing to rotate in panic — the repo never held a secret to begin with.
Cloud Vault
Secrets resolved at runtime. Never in your repo.
Your .env stays empty. When a service ignites, its environment arrives from Cloud Vault — versioned per environment, scoped per service, audited on every read.
Configuration is a runtime concern, not a build artifact. Vault holds every environment — development, staging, production — as versioned config trees. At ignite(), the runtime fetches the tree for this service in this environment and merges it into the read-only dependencies.config.
Secrets never persist where they should not: not in the repository, not in the image, not on disk. They are held in process memory for exactly as long as the service runs, and every retrieval leaves an audit record — who, what, when, from where.
Rotation stops being a deploy. Change a credential in Vault and the next boot picks it up — across every service that consumes it. One source of truth instead of forty .env files drifting apart.
// .env stays empty — this is the whole setup
const loom = new Loom({ root: __dirname });
// ignite() resolves the environment from Cloud Vault
const deps = await loom.ignite();
const stripeKey = deps.config.providers.stripe.key;
// in memory only. audited on read.What you get
- Runtime fetch at ignite — secrets never written to disk
- Versioned environments — diff staging against production
- Audited reads — every retrieval attributed and logged
- Rotation without redeploys — next boot picks up the change
Built for
Forty services, one rotation
The database password changes once, in Vault. Every consuming service picks it up on next boot. No coordinated deploy train.
The auditor’s question
"Who accessed the production payment key in March?" — a query, not an investigation.