Vaultwarden en VPS: gestor de contraseñas autoalojado

¿Por qué autoalojar tu gestor de contraseñas?

Ventajas principales

• 100% compatible con todos los clientes oficiales de Bitwarden — sin fork, sin app personalizada, nada que reaprender
• Cifrado AES-256 de extremo a extremo: tu contraseña maestra nunca sale de tu dispositivo
• Menos de 50 MB de RAM en reposo — funciona sin problema en un VPS de 512 MB junto a otros servicios
• Todos los usuarios y bóvedas de organización, con uso compartido cifrado y acceso basado en roles
• Autenticador TOTP integrado: sustituye Google Authenticator por una alternativa autoalojada
• Acceso de emergencia — concede a un contacto de confianza acceso de lectura después de un período de espera configurable

Requisitos previos

Desplegar Vaultwarden en 5 pasos

1. 01

   Instalar Docker

   Si Docker no está instalado: curl -fsSL https://get.docker.com | sh && systemctl enable --now docker. Verifica con docker --version.

2. 02

   Arrancar Vaultwarden

   Lanza el contenedor: docker run -d --name vaultwarden --restart=always -v vaultwarden:/data -p 127.0.0.1:8000:80 -e WEBSOCKET_ENABLED=true vaultwarden/server:latest. El servidor arranca en menos de un segundo y escucha en el puerto 8000 en localhost.

3. 03

   Configurar HTTPS con Caddy

   Instala Caddy: apt install -y caddy. Crea /etc/caddy/Caddyfile con: passwords.tu-dominio.com { reverse_proxy localhost:8000 }. Recarga Caddy: systemctl reload caddy. Se provisiona automáticamente un certificado TLS de Let's Encrypt y se renueva indefinidamente — cero configuración.

4. 04

   Crear tu cuenta

   Abre https://passwords.tu-dominio.com en tu navegador. Haz clic en "Create Account", elige una contraseña maestra robusta (cifra todo localmente antes de que se envíe nada al servidor), y tu bóveda estará activa de inmediato.

5. 05

   Bloquear los registros

   Una vez creadas todas las cuentas, detén el contenedor y vuélvelo a lanzar añadiendo -e SIGNUPS_ALLOWED=false al comando docker run. Tu instancia ahora es solo por invitación. Para la gestión continua de usuarios, activa el panel de administración añadiendo -e ADMIN_TOKEN=$(openssl rand -base64 48).

6. 06

   Primer inicio de sesión

   Al abrir la URL por primera vez, Vaultwarden muestra la bóveda web de Bitwarden: haz clic en "Create account" y establece tu propio correo y contraseña maestra (no es recuperable por nadie, ni siquiera por nosotros). Hazlo INMEDIATAMENTE: el registro está abierto.

Configurar SMTP y 2FA por correo electrónico

Configurar SMTP correctamente

1. 07

   Elige puerto y seguridad según tu proveedor

   Consulta la documentación de tu relé SMTP (Gmail, Brevo, Postmark, SendGrid…). Regla práctica: si tu proveedor indica el puerto 465 → SMTP_SECURITY=force_tls; si indica el puerto 587 → SMTP_SECURITY=starttls. Nunca los mezcles.

2. 08

   Pasa las variables SMTP al contenedor

   Vuelve a lanzar el contenedor con las variables necesarias:

   docker run -d --name vaultwarden --restart=always \
     -v vaultwarden:/data \
     -p 127.0.0.1:8000:80 \
     -e SMTP_HOST=smtp.tu-proveedor.com \
     -e [email protected] \
     -e SMTP_PORT=587 \
     -e SMTP_SECURITY=starttls \
     -e SMTP_USERNAME=tu_login \
     -e SMTP_PASSWORD=tu_contraseña \
     vaultwarden/server:latest

3. 09

   Prueba el envío desde el panel de administración

   Abre https://passwords.tu-dominio.com/admin, desplázate hasta la sección SMTP Email Settings y usa el botón Send test email. Si el correo no llega en 60 segundos, revisa los registros del contenedor: docker logs vaultwarden 2>&1 | grep -i smtp. Un mensaje Connection refused indica un puerto incorrecto; TLS handshake error indica un conflicto de seguridad.

4. 10

   Activa la 2FA por correo solo después de validar el envío

   Solo activa _ENABLE_EMAIL_2FA=true una vez confirmado el envío de prueba. Si lo activas antes, los usuarios cuyo cliente solicita un código no reciben nada y quedan bloqueados. Para desbloquear una cuenta bloqueada: abre /admin, localiza al usuario y haz clic en Deactivate TOTP para desactivar temporalmente la 2FA.

Compatibilidad cliente/servidor y errores silenciosos

Síntomas de un desajuste de versión cliente/servidor

• Imposible iniciar sesión en un nuevo dispositivo o navegador, mientras los dispositivos existentes funcionan con normalidad
• Mensaje de error genérico sin indicación de causa ("An error has occurred" o "Invalid username or password")
• La extensión de Chrome o Firefox recién instalada falla, pero la misma versión en otro equipo funciona
• La bóveda web de Bitwarden alojada en tu instancia devuelve 404 en /identity/accounts/prelogin/password
• Sin errores en los registros de Vaultwarden en el servidor — el endpoint no existe, no hay nada que registrar
• El problema apareció tras una actualización automática del cliente Bitwarden en el nuevo dispositivo

Diagnosticar y resolver el desajuste

1. 11

   Verifica la versión de tu servidor

   Consulta el endpoint de versión: curl https://your-domain.com/api/version. Si la respuesta muestra una versión anterior a 1.36.0, tu servidor no soporta el nuevo flujo de autenticación de los clientes recientes.

2. 12

   Actualiza a la imagen más reciente

   La solución más segura es usar siempre vaultwarden/server:latest y mantener la imagen actualizada. Para actualizar: docker pull vaultwarden/server:latest && docker stop vaultwarden && docker rm vaultwarden, luego vuelve a ejecutar el mismo docker run que usaste en la instalación. Vaultwarden preserva los datos en el volumen — no se necesita migración manual.

3. 13

   Verifica que la actualización surtió efecto

   Tras reiniciar, consulta de nuevo curl https://your-domain.com/api/version y confirma que la versión es 1.36.0 o superior. Luego prueba el inicio de sesión desde una nueva pestaña de navegación privada.

4. 14

   Fija una versión si la estabilidad es la prioridad

   Si prefieres controlar las actualizaciones manualmente, usa una etiqueta versionada: vaultwarden/server:1.37.2 por ejemplo. En ese caso, monitorea las releases en GitHub y actualiza cuando se despliegue una nueva versión del cliente Bitwarden — ambas están acopladas.

Caja fuerte vacía tras actualizar a los clientes Bitwarden 2026.8.0: diagnóstico y solución

Síntomas de este fallo de compatibilidad

• El inicio de sesión se acepta, pero la caja fuerte está vacía o no termina de cargar tras la sincronización
• Sin sugerencias de autorrelleno, aplicación de escritorio que se cierra o extensión que muestra «failed to fetch»
• En la consola del navegador, el error RangeError: Invalid time value en toSdkPolicyView (visto en la incidencia #7612)
• Ningún error en los registros del servidor Vaultwarden
• Casos reportados sobre todo en cuentas de una organización con al menos una política configurada, incluso desactivada; la web vault servida por Vaultwarden funciona

Diagnosticar y reparar una caja fuerte vacía

1. 15

   Comprobar la versión del servidor

   Abre /admin/diagnostics o ejecuta docker exec vaultwarden /vaultwarden --version. Hace falta la 1.37.2 como mínimo para los clientes 2026.8.0+. Asegúrate también de que solo hay una instancia en marcha: un archivo compose duplicado ya causó síntomas idénticos.

2. 16

   Actualizar el servidor si hace falta

   Usa el mismo procedimiento que para cualquier actualización (descargar la imagen, recrear el contenedor sobre el mismo volumen). Ve directamente a la última versión: consulta la sección sobre la 1.37.4 más abajo.

3. 17

   Limpiar el estado local del cliente

   Cierra sesión por completo y vuelve a iniciarla. Si la caja sigue vacía, vaciar el almacenamiento de la extensión (las entradas policies) o desinstalarla y reinstalarla resuelve la mayoría de los casos. En macOS, algunos usuarios tuvieron que borrar los datos del contenedor de la aplicación de escritorio antes de volver a entrar.

4. 18

   Revisar el entorno antes de bajar de versión

   Consulta /admin/diagnostics por si faltan cabeceras (un fallo de TOTP se corrigió así), mantén el panel de administración y la caja fuerte en el mismo dominio y prueba sin bloqueadores de anuncios. Solo como último recurso, vuelve los clientes a la 2026.7.0, la versión que funcionaba para los primeros afectados, hasta actualizar el servidor.

Actualización 1.37.4: siete correcciones de seguridad y cambios incompatibles

Los siete avisos de seguridad de la 1.37.4

• Revocación de miembros de una organización: gravedad alta, 8.1 (GHSA-69q9-v8p6-xvx3)
• Autenticación en dos pasos: gravedad media, 6.8 (GHSA-7jg8-8m5x-6j9r)
• Invitaciones de organización: gravedad media, 6.8 (GHSA-v576-3wvq-xh3c)
• Archivos adjuntos: gravedad media, 6.5 (GHSA-q5x6-grh5-fqgc)
• Registros de eventos de organización: gravedad media, 4.3 (GHSA-64mc-4p6f-r7x9)
• Compartición de elementos: gravedad media, 4.3 (GHSA-7ccc-c43j-4p36)
• Clave de API de organización: gravedad baja, 3.8 (GHSA-qwx4-wcv4-mpcv)

Antes de pasar a la 1.37.4: lo que puede romperse

1. 19

   Proxy inverso e IP del cliente

   Con IP_HEADER=X-Forwarded-For, la dirección que se conserva es ahora la más a la derecha que no figura en IP_HEADER_TRUSTED_PROXIES (antes era la más a la izquierda). Si hay varios proxies seguidos delante de Vaultwarden, enuméralos todos en IP_HEADER_TRUSTED_PROXIES; si no, tus registros y límites de tasa verán una dirección equivocada.

2. 20

   Sends y CLI

   bw send receive ya no funciona con el CLI 2026.4.2 y anteriores. Crear y gestionar Sends sigue funcionando en todos los clientes: actualiza el CLI si recibes Sends por línea de comandos.

3. 21

   MariaDB o MySQL sin TLS

   Si tu servidor de base de datos no admite conexiones TLS nativas, la imagen Alpine puede no conseguir conectarse. Añade MARIADB_TLS_DISABLE_PEER_VERIFICATION=1 al entorno de Vaultwarden. Con SQLite, la opción por defecto de esta guía, no te afecta.

4. 22

   Opciones y puntos de acceso eliminados

   Se han eliminado varios indicadores experimentales (por ejemplo ssh-agent o mutual-tls): si siguen en EXPERIMENTAL_CLIENT_FEATURE_FLAGS, el arranque registra una advertencia y guardar los ajustes del panel de administración falla hasta que los quites. DUO_USE_IFRAME se elimina y se ignora. Los antiguos puntos de acceso POST /identity/accounts/register y POST /api/accounts/prelogin desaparecen; las notas indican que ningún cliente actual los usa.

5. 23

   Rotar la clave de API de la organización

   Antes de esta versión, los administradores de una organización también podían ver su clave de API. Si alguno no es de plena confianza, rota la clave tras actualizar (consola de administración, Ajustes, Rotar clave de API).

Bitwarden pasa a doble licencia: qué cambia y qué no

Qué cambia y qué no para Vaultwarden

• No cambia: Bitwarden afirma que no hay cambios para el autoalojamiento; el servidor Vaultwarden es un proyecto independiente, bajo licencia AGPL-3.0, y no le afecta la licencia de los clientes
• No cambia: las funciones actuales siguen disponibles en ambas versiones de los clientes, plan gratuito incluido; no se pide ninguna acción a los usuarios existentes
• A vigilar: Bitwarden avisa de que algunos componentes futuros solo se publicarán bajo licencia comercial y de que cada función nueva se evaluará caso por caso; los clientes de las tiendas y la versión GPLv3 podrían divergir
• A vigilar: si una función futura solo existe en la compilación comercial, nada garantiza que funcione con un servidor de terceros; prueba cada actualización de cliente en una cuenta secundaria antes de generalizarla
• Si quieres seguir con código GPLv3, puedes compilar los clientes desde el repositorio de GitHub, a costa de mantenerlos tú mismo