Vaultwarden en producción: backups, passkeys, 2FA y endurecimiento razonable

Vaultwarden es una de esas piezas de self-hosting que entran demasiado fácil. Un contenedor, un volumen, un dominio, HTTPS delante y en una tarde tienes un gestor de contraseñas compatible con los clientes de Bitwarden. Eso es parte de su encanto. También es parte del peligro.

Cuando lo pruebas con cuatro credenciales de laboratorio, Vaultwarden parece otro servicio más. Como Uptime Kuma, FreshRSS o Linkding. Algo útil, ligero y agradecido. Pero el día que importas contraseñas reales, notas seguras, TOTP, claves de recuperación y accesos de la familia, deja de ser un juguete. Pasa a ser una de las piezas más sensibles de todo el homelab.

Por eso no lo dejaría en un simple docker compose up -d. Tampoco hace falta una infraestructura de gran empresa. Hay una configuración doméstica razonable entre ambos extremos.

Mi criterio es este: Vaultwarden merece producción doméstica. Debo poder restaurarlo, revocar sesiones de un equipo robado y recuperar el vault si falla el host. La familia, además, tiene que poder usarlo sin pelearse con la infraestructura.

Qué significa producción en un homelab

#

Para mí, “en producción” no significa que algo esté publicado en internet. Significa que alguien depende de ello.

Si un dashboard de métricas cae durante una semana, no pasa nada. Si el servidor de contraseñas cae justo cuando necesitas entrar al banco, al panel del dominio o a la cuenta de Apple, la cosa cambia. Ahí descubres rápido si tenías una arquitectura o una colección de buenas intenciones.

En Vaultwarden separo cuatro responsabilidades:

• disponibilidad razonable
• recuperación probada
• acceso seguro
• mantenimiento sencillo

No necesito alta disponibilidad para un gestor familiar. Es fácil añadir más problemas intentando conseguirla. Sí necesito poder levantar el servicio en otro host con rutas y documentación conocidas, sin guardar el único procedimiento dentro del propio Vaultwarden.

Ese último punto parece obvio hasta que te pasa. Si el procedimiento de restauración vive como nota segura dentro del gestor que está caído, acabas de fabricar una broma bastante mala.

Dónde lo pondría

#

No pondría Vaultwarden en el servidor más experimental de la casa. Tampoco lo metería en el NAS lleno de plugins raros si ese NAS ya hace demasiadas cosas.

Mi sitio favorito es una VM pequeña o un contenedor en un host estable, con almacenamiento persistente claro y backups fuera de ese host. Puede vivir en Proxmox, en Debian con Docker o en una VM sencilla. La tecnología de debajo importa menos que el hábito operativo.

Lo que evitaría:

• correrlo en el mismo Docker donde pruebo contenedores cada dos días
• dejar el volumen persistente en una ruta improvisada
• depender de una única copia local
• exponer el puerto del contenedor directamente
• mezclarlo con servicios públicos sin una frontera clara

Me gusta que el contenedor solo escuche en loopback o en una red interna de Docker. Delante, un reverse proxy con HTTPS válido. Caddy, Traefik o Nginx Proxy Manager me valen. No necesito pelearme con TLS dentro de Vaultwarden si el proxy ya lo hace bien.

La configuración mínima que busco no es espectacular:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://passwords.tu-dominio.com"
      SIGNUPS_ALLOWED: "false"
      WEBSOCKET_ENABLED: "true"
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"

Ese 127.0.0.1 no es decoración. Si el proxy vive en la misma máquina, no necesito regalar un puerto a toda la red. Menos exposición, menos tonterías.

Registros cerrados desde el minuto uno

#

SIGNUPS_ALLOWED=false debería ser el estado normal de un Vaultwarden personal o familiar.

No quiero que alguien pueda crear cuentas porque encontró el dominio. Si necesito añadir a una persona, la invito. Si necesito compartir contraseñas, creo una organización y controlo permisos. Cerrar registros no arregla todo, pero elimina una puerta que casi nadie necesita abierta.

También revisaría el SMTP pronto. Mucha gente lo deja para luego porque el servidor arranca igual. Error menor, pero error. El correo saliente sirve para invitaciones, avisos y flujos de cuenta. No lo consideraría opcional si vas a meter más usuarios que tú.

Eso sí, el SMTP no debe convertirse en otro secreto tirado por cualquier lado. Si la contraseña de correo acaba en un compose dentro de un repo, en un backup sin cifrar y en el historial de la terminal, el problema no es Vaultwarden. Es higiene básica.

El panel de admin, con correa corta

#

El panel de administración es útil. También es una pieza que no quiero enseñar al mundo.

Vaultwarden permite proteger el panel con ADMIN_TOKEN. Mi recomendación es usar un token largo y, si puedes, guardarlo hasheado con Argon2id en formato PHC. El propio proyecto permite generar ese hash con su utilidad. Así reduces el daño si alguien ve la variable de entorno.

No es magia. Si alguien controla el host, tienes un problema grande igualmente. Pero entre tener un secreto en claro y tener un hash fuerte, prefiero lo segundo.

También limitaría /admin en el reverse proxy. Acceso solo desde LAN, desde VPN o desde una red concreta. No me obsesiona ocultar rutas, pero sí me gusta que el panel ni siquiera responda a medio internet.

También guardaría fuera de Vaultwarden la forma de invalidar sesiones de admin y restaurar acceso. No como una novela. Dos líneas claras bastan. El día que necesitas esa información, agradeces que no esté enterrada en una conversación antigua.

2FA no es una opción estética

#

La cuenta principal debe tener 2FA. Punto.

Yo usaría TOTP como base porque funciona en casi todas partes y no depende de hardware concreto. Aegis, ente Auth o una app similar sirven bien. Si usas iPhone y estás cómodo con el llavero, también es una opción práctica, aunque mezclar contraseñas y segundo factor en el mismo ecosistema tiene sus matices.

Para una cuenta crítica, me gusta separar:

• contraseña maestra fuerte
• TOTP fuera del propio Vaultwarden
• códigos de recuperación impresos o guardados fuera del servicio
• al menos un dispositivo ya probado antes de cerrar la sesión antigua

El detalle importante es no usar Vaultwarden como único sitio donde guardas el segundo factor de Vaultwarden. Es cómodo, sí. También es una trampa. Si pierdes acceso, te quedas mirando la puerta con la llave dentro.

Para usuarios familiares, no siempre impondría el mismo nivel desde el día uno. Hay que ser práctico. Si haces que el acceso sea demasiado incómodo, la gente vuelve a guardar contraseñas en notas del móvil. Seguridad perfecta, resultado lamentable.

Mi enfoque sería distinto según el usuario:

• cuenta administradora con 2FA obligatorio y recovery probado
• familiares con 2FA si lo toleran bien
• colecciones compartidas con permisos mínimos
• nada de dar acceso de escritura por defecto

La seguridad doméstica buena no es la más dura. Es la que la gente usa sin odiarla.

Passkeys: útiles, pero no montaría la casa sobre ellas todavía

#

Las passkeys me gustan. Reducen phishing, evitan muchas contraseñas malas y encajan muy bien en servicios modernos. En un gestor como Bitwarden tienen sentido porque el propio gestor puede guardar y sincronizar passkeys.

Con Vaultwarden sería más cauto.

La compatibilidad depende de la versión del servidor, de los clientes de Bitwarden y de cómo evoluciona la API. Algunas funciones nuevas llegan primero al servidor oficial de Bitwarden y después van madurando en Vaultwarden. Es normal. Vaultwarden es una implementación alternativa, no el producto oficial de Bitwarden.

¿Usaría passkeys en Vaultwarden? Sí, pero no para todo desde el primer día.

Empezaría por cuentas poco críticas. Probaría extensión de navegador, móvil y recuperación. Vería cómo se comportan los backups y la exportación. Y solo después empezaría a mover accesos importantes.

Lo que no haría es borrar alegremente métodos alternativos de acceso en servicios críticos porque “ya tengo passkey”. Para bancos, dominios, Apple, Google, correo principal y proveedores importantes, mantendría una vía de recuperación documentada.

Las passkeys son una mejora, no una excusa para dejar de pensar en recuperación.

Backups: copiar la carpeta no siempre basta

#

El directorio /data de Vaultwarden es el corazón del servicio. Ahí viven la base de datos, adjuntos, claves, configuración y otros ficheros que puedes necesitar para restaurar bien.

Si usas SQLite, la base suele ser db.sqlite3. Copiar ese archivo mientras el servicio está escribiendo puede funcionar muchas veces, hasta que justo no funciona. Para copias consistentes prefiero usar la función de backup de SQLite.

Ejemplo:

1

sqlite3 ./data/db.sqlite3 ".backup './backup/db-$(date +%F-%H%M).sqlite3'"

Después de eso, copiaría también:

• adjuntos
• ficheros rsa_key.*
• config.json si existe
• configuración del compose
• configuración relevante del reverse proxy
• notas de restauración

No todo tiene que estar en el mismo paquete, pero sí tiene que existir. Un backup de la base sin adjuntos puede dejarte con el vault arrancando y parte de la información rota. Un backup sin claves puede darte más trabajo del necesario. Un backup sin procedimiento puede obligarte a improvisar cuando peor estás.

Mi regla es simple: backup local para recuperación rápida, backup remoto cifrado para desastre real.

El backup local puede vivir en el NAS. El remoto puede ser otro servidor, un disco rotado o almacenamiento en la nube. Me da igual la herramienta mientras cumpla tres cosas:

• cifrado antes de salir de casa
• retención suficiente para errores humanos
• restauración probada

Restic, Borg y Kopia son opciones serias. Un rsync a pelo puede servir para una copia secundaria, pero no lo elegiría como única estrategia para contraseñas.

Restaurar antes de confiar

#

Aquí es donde separo un backup real de una estampita.

Una vez montado Vaultwarden, haría una restauración en un entorno temporal. No hace falta hacerlo cada semana. Pero al menos una vez, sí.

El ejercicio es este:

1. Levantar una VM o contenedor temporal.
2. Restaurar /data o la base y ficheros necesarios.
3. Arrancar Vaultwarden con un dominio local o entrada de hosts.
4. Entrar con una cuenta de prueba.
5. Confirmar que aparecen elementos, adjuntos y organizaciones.
6. Apagar y borrar el entorno temporal.

Si esa prueba falla, mejor descubrirlo un martes tranquilo que una noche con prisa.

También escribiría un mini runbook fuera del propio gestor:

• dónde están los backups
• cómo se descifran
• qué fichero restaurar primero
• cómo arrancar el compose
• qué comprobar al final

Cinco pasos feos salvan más que una documentación preciosa que nadie lee.

Actualizaciones sin ruleta

#

No dejaría Vaultwarden seis meses quieto. Tampoco actualizaría cada imagen nueva a ciegas en cuanto aparece.

Mi rutina ideal:

1. Leer notas de release.
2. Hacer backup.
3. Actualizar imagen.
4. Probar login web.
5. Probar extensión de navegador.
6. Probar móvil.
7. Revisar panel de admin.
8. Confirmar que el backup siguiente se genera.

Son diez minutos si todo va bien. Y si no va bien, tienes backup fresco.

Para un servicio cualquiera puedo aceptar más alegría. Para el gestor de contraseñas, no. No porque Vaultwarden sea frágil, sino porque el impacto de una mala actualización es mayor.

Organizaciones y familia

#

Compartir contraseñas con familia es una de las funciones más útiles. También es una de las formas más rápidas de liarla si das permisos de más.

Mi modelo sería:

• cada persona con su vault personal
• una organización familiar
• colecciones por contexto
• lectura por defecto
• edición solo a quien realmente la necesite

Por ejemplo, una colección para streaming, otra para suministros, otra para cosas de casa. No metería todo en una colección gigante llamada “familia”. Eso termina siendo un cajón sin dueño.

También explicaría una cosa básica: borrar o editar una contraseña compartida afecta a otros. Parece tonto. No lo es. La mayoría de problemas domésticos no vienen de atacantes sofisticados. Vienen de alguien tocando algo que no sabía que era compartido.

Qué no metería en Vaultwarden

#

Aunque lo use mucho, no metería todo sin pensar.

No guardaría el único procedimiento para recuperar Vaultwarden dentro de Vaultwarden. No guardaría la única copia de los códigos de recuperación ahí. No guardaría la única clave para descifrar backups del propio Vaultwarden dentro del mismo servicio.

Tampoco usaría el vault como archivo documental general. Para eso prefiero Paperless-ngx, un NAS o una estructura de documentos cifrada. Vaultwarden está para secretos, no para convertirse en trastero.

Y tendría cuidado con adjuntos grandes. Funcionan, pero si empiezas a guardar PDFs, imágenes y documentos pesados, tu estrategia de backup cambia. No es malo, solo hay que saberlo.

Mi checklist final

#

Si tuviera que revisar una instalación antes de decir “esto ya puede guardar cosas serias”, miraría esto:

• HTTPS válido delante
• contenedor no expuesto directamente
• registros cerrados
• SMTP configurado
• admin token fuerte y preferiblemente hasheado
• /admin limitado por red o VPN
• 2FA en cuenta principal
• códigos de recuperación fuera del servicio
• backup consistente de SQLite
• copia completa de ficheros importantes
• copia remota cifrada
• restauración probada
• procedimiento escrito fuera del vault
• actualización documentada
• permisos familiares revisados

Son medidas normales para un servicio que guarda credenciales importantes.

Conclusión

#

Vaultwarden sigue siendo una de las mejores piezas que puedes montar en un homelab. Consume poquísimo, se integra con clientes excelentes y te da control sobre un dato muy sensible.

Pero precisamente por eso no lo pondría en la misma categoría que un lector RSS o un dashboard bonito.

Antes de dar la instalación por terminada, probaría 2FA, cerraría los registros, limitaría el panel de administración y restauraría un backup en limpio.

Vaultwarden guarda las llaves de casi todo lo demás. Su procedimiento de recuperación merece estar escrito y accesible aunque el servidor esté caído.

Para seguir afinando la arquitectura, encaja muy bien con la guía básica de Vaultwarden, el post sobre Vaultwarden sin jugar con fuego y el enfoque de backups que sí miro.