Contexto
Hoy los secretos de este proyecto viven en .env/.env.copy local, sin gestión centralizada, rotación, ni auditoría de acceso. Es el patrón estándar en todos los repos del org — este issue propone resolverlo con un vault dedicado, empezando aquí.
Opción principal: Infisical
Infisical — open source (MIT), self-hosted o cloud, hecho para equipos de desarrollo (no tan pesado como Vault, más flexible que Doppler).
Por qué Infisical y no las alternativas:
- vs HashiCorp Vault: Vault es más potente (secretos dinámicos, PKI, transit encryption) pero requiere operar un cluster Raft y tiene curva de aprendizaje alta — sobra para el tamaño de estos proyectos.
- vs Doppler: Doppler es SaaS puro, sin opción self-hosted — no sirve si en algún momento hay requisito de soberanía de datos. Infisical sí se puede self-hostear en una VPS con 2GB RAM (corre sobre Postgres + Redis, nada propietario).
- Infisical tiene cifrado end-to-end del lado del cliente: aunque el servidor de Infisical se comprometa, un atacante solo obtiene blobs cifrados.
- SDKs nativos para Node/TypeScript, CLI para inyectar secretos en runtime (
infisical run -- <comando>), sin tocar código de la app.
Secretos que este proyecto manejaría en el vault
Basado en el stack (NestJS + Prisma + Postgres + JWT): DATABASE_URL, secreto de JWT, y cualquier credencial de terceros que se agregue a futuro. Actualmente todo vive en .env/.env.copy local sin rotación.
Beneficios concretos
- Un solo lugar para rotar credenciales (hoy: cambiar
.env a mano en cada máquina/entorno).
- Auditoría de quién accede a qué secreto y cuándo.
- Sincronización automática entre dev/staging/prod sin copiar
.env files a mano.
- Integración con CI (GitHub Actions) vía Infisical Action, sin guardar secretos como GitHub Secrets duplicados.
- Elimina el riesgo de
.env con credenciales reales terminando en un commit por accidente.
Alcance propuesto
- Levantar instancia de Infisical (self-hosted en Docker, o cloud free tier para validar primero).
- Migrar las variables de
.env/.env.copy al vault.
- Actualizar scripts de arranque (
dev, start, debug) para inyectar vía infisical run --.
- Documentar el flujo de onboarding (cómo un dev nuevo obtiene acceso a los secretos del proyecto).
No implementado — este issue es la propuesta/research, ejecutar bajo su propia rama cuando se priorice.
Contexto
Hoy los secretos de este proyecto viven en
.env/.env.copylocal, sin gestión centralizada, rotación, ni auditoría de acceso. Es el patrón estándar en todos los repos del org — este issue propone resolverlo con un vault dedicado, empezando aquí.Opción principal: Infisical
Infisical — open source (MIT), self-hosted o cloud, hecho para equipos de desarrollo (no tan pesado como Vault, más flexible que Doppler).
Por qué Infisical y no las alternativas:
infisical run -- <comando>), sin tocar código de la app.Secretos que este proyecto manejaría en el vault
Basado en el stack (NestJS + Prisma + Postgres + JWT):
DATABASE_URL, secreto de JWT, y cualquier credencial de terceros que se agregue a futuro. Actualmente todo vive en.env/.env.copylocal sin rotación.Beneficios concretos
.enva mano en cada máquina/entorno)..envfiles a mano..envcon credenciales reales terminando en un commit por accidente.Alcance propuesto
.env/.env.copyal vault.dev,start,debug) para inyectar víainfisical run --.No implementado — este issue es la propuesta/research, ejecutar bajo su propia rama cuando se priorice.