El simulacro de fuga que nunca ocurre
Se pierde una laptop, un repo se hace público. No hay nada que rotar en pánico — el repo nunca tuvo un secreto.
Cloud Vault
Secretos resueltos en runtime. Nunca en tu repo.
Tu .env queda vacío. Cuando un servicio hace ignite, su entorno llega desde Cloud Vault — versionado por entorno, delimitado por servicio, auditado en cada lectura.
La configuración es un asunto de runtime, no un artefacto de build. Vault mantiene cada entorno — development, staging, production — como árboles de configuración versionados. En el ignite(), el runtime trae el árbol de este servicio en este entorno y lo funde en el dependencies.config de solo lectura.
Los secretos nunca persisten donde no deben: ni en el repositorio, ni en la imagen, ni en disco. Viven en la memoria del proceso exactamente mientras el servicio corre, y cada lectura deja un registro de auditoría — quién, qué, cuándo, desde dónde.
La rotación deja de ser un deploy. Cambias una credencial en Vault y el siguiente boot la toma — en todos los servicios que la consumen. Una fuente de verdad en vez de cuarenta .env divergiendo.
// El .env queda vacío — este es todo el setup
const loom = new Loom({ root: __dirname });
// ignite() resuelve el entorno desde Cloud Vault
const deps = await loom.ignite();
const stripeKey = deps.config.providers.stripe.key;
// solo en memoria. auditado al leer.Qué obtienes
- Fetch en runtime durante el ignite — secretos jamás escritos a disco
- Entornos versionados — compara staging contra production
- Lecturas auditadas — cada acceso atribuido y registrado
- Rotación sin redeploys — el próximo boot toma el cambio
Hecho para
Cuarenta servicios, una rotación
La contraseña de la base de datos cambia una vez, en Vault. Todos los servicios que la consumen la toman en el siguiente boot. Sin tren de deploys coordinado.
La pregunta del auditor
«¿Quién accedió a la llave de pagos de producción en marzo?» — una consulta, no una investigación.