Secrets at runtime: the case for an empty .env
Cloud Vault resolves environments when a service ignites — versioned, scoped, audited. Your repo never holds a secret again.
Every leaked credential we have ever helped rotate had the same origin story: it was written to a file, and the file traveled. Into a repo, into an image, into a laptop that left the building.
Cloud Vault starts from a different premise: configuration is a runtime concern, not a build artifact. Your .env stays empty. When a service calls ignite(), the runtime fetches the environment tree for this service in this environment — development, staging, production — and merges it into the read-only dependencies.config.
What that buys you
Nothing sensitive persists. Secrets live in process memory exactly as long as the service runs. Not in the repository, not in the image layer, not on disk.
Every read is audited. Who fetched the production payment key, when, from where — a query, not a forensic investigation.
Rotation stops being a deploy. Change the database password once in Vault; every consuming service picks it up on its next boot. No coordinated deploy train, no forty .env files drifting apart.
Environments are versioned. Diff staging against production. See what changed before the incident, not after.
The honest caveat
Local development still works with a plain .env — the SDK reads it when no Vault is configured. Same code, both paths. The vault is how the platform amplifies the runtime, never a wall between you and your laptop.
