---
episode_id: "383754cf-789b-48db-b5f5-2370eaa4f825"
puente_flat: "TRAZA_mi-recomendacin_S20260616.R23_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260616.LOOP_WRITE_BACKLOG_DISCARD"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "NONE"
fase_proyecto: "operations"
tipo_semantico: "design"
summary_one_line: "EPISODIO 23 — Vaultwarden: Mi recomendación"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-06-17T21:21:02.759342+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---

Primero una corrección de precisión (PROCEDENCIA), porque importa para decidir bien: verifiqué ambos este `S20260616` — **Docker file-secrets NO está aún en todos los stacks**, solo en `ember-cc-server` (el resto usa `env_file`); y **Vaultwarden corre pero standalone** (no en el flujo de secretos de servicio). O sea: no es elegir entre dos cosas ya generalizadas, es **decidir cuál generalizar**.

Y la clave para responderte bien: **resuelven problemas distintos**, no son rivales directos.

| | **Vaultwarden** | **Docker file-secrets** |
|---|---|---|
| Qué es | gestor de secretos (catálogo + UI + control de acceso) | mecanismo de **inyección** del secreto al container |
| Pensado para | **humanos** (logins de John) | **máquinas** (procesos en containers) |
| Exposición | secreto en su DB (no en `printenv`) | archivo en `/run/secrets/` 0400, **NO en `printenv`/`inspect`** |
| Dependencia runtime | sí — si cae, no hay secretos | no — el secreto es un archivo local |
| Bootstrap | necesita una master/API key para desbloquear = **secreto nuevo de alto valor** (problema huevo-gallina) | ninguno |
| Ya probado aquí | standalone, sin integrar al flujo | **sí, en `ember-cc-server`** |

## Mi recomendación

**Docker file-secrets como estándar para los secretos de SERVICIO (máquina); Vaultwarden conservado para los secretos HUMANOS de John + como catálogo maestro legible.** No es "uno u otro" — es **cada uno en su capa**.

**Por qué file-secrets para servicio (la decisión principal):**
1. **Mata la exposición real que encontramos:** `env_file` deja el secreto visible en `docker inspect`/`printenv` (y por eso el riesgo del socket-proxy que `ember-mcp` podría explotar). file-secrets **no aparecen ahí**. Ataca la causa raíz #1.
2. **Cero dependencia nueva ni SPOF:** el secreto es un archivo; no hay un servicio que pueda caerse y dejar 61 containers sin credenciales.
3. **Ya está probado en tu ecosistema** (`ember-cc-server`) — no hay que aprender/desplegar nada nuevo.
4. **Nativo de Docker Compose** (`secrets:` + convención `_FILE`).

**Por qué NO Vaultwarden como fuente runtime de servicio:**
1. **Bootstrap venenoso:** para que un container lea de Vaultwarden necesita una key/master para desbloquearlo → creas un **secreto nuevo de máxima criticidad** para proteger el resto (huevo-gallina).
2. **Lo vuelves SPOF + dependencia:** Vaultwarden caído = memoria de Ember sin poder autenticar.
3. **Está diseñado para uso humano interactivo**, no para inyectar a decenas de containers.
4. **Peso operativo** que un operador solo no quiere mantener.