Vaultwarden — gestor de contraseñas self-hosted

Instancia self-hosted de Vaultwarden (implementación compatible con el protocolo de Bitwarden) en vm-personal, publicada en vault.estebanalcocer.cloud detrás del túnel hub-ehalsou — el mismo túnel que sirve hub.estebanalcocer.cloud, ver Túneles de Cloudflare § vm-personal.

Cómo se confirmó

No estaba documentada en ningún lado de esta wiki. Salió a la luz el 2026-08-15 durante una auditoría de los 21 registros DNS de la zona estebanalcocer.cloud, al identificar 8 subdominios huérfanos (túneles muertos o sin conexiones, sin ninguna mención en la wiki) y borrarlos — vault. no encajaba en ese patrón: a diferencia de los huérfanos, responde 200 con normalidad y su túnel (hub-ehalsou) tiene conexiones activas. Confirmado con Esteban en conversación que es Vaultwarden real y en uso, no un resto — se documenta acá para que no vuelva a aparecer como sorpresa en la próxima auditoría.

Sin Cloudflare Access delante

A diferencia de hub. (mismo túnel, protegido con la policy reusable “google project-vm-personal” — ver Cloudflare Access), vault.estebanalcocer.cloud no tiene ninguna Access Application configurada. Mismo razonamiento que Infisical: Vaultwarden ya exige su propio login (contraseña maestra de la bóveda) antes de exponer cualquier dato, así que una segunda capa de Access encima sería redundante sobre una que ya es fuerte — no es un descuido, es el mismo criterio aplicado consistentemente.

Véase también

• Túneles de Cloudflare — túnel hub-ehalsou, compartido con hub.estebanalcocer.cloud
• Infisical — mismo razonamiento de “auth propio del servicio es suficiente, sin Cloudflare Access encima”
• Cloudflare Access — por qué este hostname no está protegido ahí, a diferencia de hub.