¿Por qué autoalojar tu gestor de contraseñas?
Los gestores de contraseñas en la nube cobran por usuario y mes, almacenan tu bóveda cifrada en servidores que no controlas, y pueden desaparecer o subir precios de un día para otro. Vaultwarden invierte este modelo: un contenedor en tu VPS, un volumen Docker que respaldar, y un número ilimitado de cuentas de usuario con un coste de infraestructura fijo. Dado que Vaultwarden habla el protocolo Bitwarden, cada cliente Bitwarden — extensión de Chrome, complemento de Firefox, iOS, Android, Windows, Linux, CLI — se conecta a tu instancia autoalojada sin ninguna modificación.
Ventajas principales
- 100% compatible con todos los clientes oficiales de Bitwarden — sin fork, sin aplicación propia, 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 problemas en un VPS de 512 MB junto a otros servicios
- Usuarios y bóvedas de organización ilimitados, con compartición cifrada 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 tras un período de espera configurable
Requisitos previos
Necesitas un VPS con al menos 1 vCPU y 512 MB de RAM, con Docker instalado (se recomienda Ubuntu 22.04 LTS). También necesitas un nombre de dominio que apunte al VPS — los clientes Bitwarden rechazan las bóvedas sin HTTPS, por lo que HTTPS es obligatorio. Abre los puertos 80 y 443 en tu cortafuegos: ufw allow 80 && ufw allow 443.
Desplegar Vaultwarden en 5 pasos
Instalar Docker
Si Docker no está ya instalado:
curl -fsSL https://get.docker.com | sh && systemctl enable --now docker. Verifica condocker --version.Iniciar 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.Configurar HTTPS con Caddy
Instala Caddy:
apt install -y caddy. Crea/etc/caddy/Caddyfilecon:passwords.your-domain.com { reverse_proxy localhost:8000 }. Recarga Caddy:systemctl reload caddy. Se provisionará automáticamente un certificado TLS de Let's Encrypt y se renovará indefinidamente — sin configuración.Crear tu cuenta
Abre
https://passwords.your-domain.comen tu navegador. Haz clic en "Create Account", elige una contraseña maestra robusta (cifra todo localmente antes de que nada se envíe al servidor), y tu bóveda estará activa de inmediato.Bloquear los registros
Una vez creadas todas las cuentas, detén el contenedor y reinícialo añadiendo
-e SIGNUPS_ALLOWED=falseal comandodocker run. Tu instancia es ahora 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).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 define 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
Vaultwarden puede enviar correos para la verificación de dirección, el restablecimiento de contraseña, las invitaciones de organización y la autenticación de dos factores por correo (_ENABLE_EMAIL_2FA=true). Este último punto merece atención especial: si SMTP no está configurado o está mal configurado, la 2FA por correo se declara activa pero nunca envía nada — el código no llega, el usuario ya no puede iniciar sesión, y Vaultwarden no muestra ningún error visible.
La confusión más frecuente concierne a los puertos y el cifrado. Dos valores coexisten y no son intercambiables:
- Puerto 465 con SMTP_SECURITY=force_tls — conexión TLS desde el inicio (antes llamado «SMTPS»). Compatible con la mayoría de ISP y relés corporativos.
- Puerto 587 con SMTP_SECURITY=starttls — conexión en texto plano que sube a TLS mediante el comando STARTTLS. Valor esperado por la mayoría de proveedores SMTP modernos (SendGrid, Brevo, Postmark, Gmail SMTP).
Usar force_tls en el puerto 587 — o starttls en el 465 — falla silenciosamente la conexión SMTP: Vaultwarden no registra nada, los correos no salen, y la interfaz muestra «enviado» si haces la prueba desde el panel admin. La única señal es la ausencia del correo en el destinatario.
Configurar SMTP correctamente
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. No los mezcles.Pasa las variables SMTP al contenedor
Reinicia 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.your-provider.com \ -e [email protected] \ -e SMTP_PORT=587 \ -e SMTP_SECURITY=starttls \ -e SMTP_USERNAME=your_login \ -e SMTP_PASSWORD=your_password \ vaultwarden/server:latestPrueba el envío desde el panel de administración
Abre
https://passwords.your-domain.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, comprueba los registros del contenedor:docker logs vaultwarden 2>&1 | grep -i smtp. Un mensajeConnection refusedindica el puerto incorrecto;TLS handshake errorindica una incompatibilidad de seguridad.Activa la 2FA por correo solo después de validar el envío
Solo activa
_ENABLE_EMAIL_2FA=trueuna 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
Los clientes Bitwarden recientes introdujeron un nuevo flujo de autenticación inicial que llama al endpoint /identity/accounts/prelogin/password. Las instancias de Vaultwarden fijadas en una versión anterior a 1.36.0 no conocen este endpoint y devuelven un 404 sin mensaje explícito — el cliente simplemente muestra un fallo de conexión genérico. La trampa es insidiosa: los dispositivos ya conectados antes de la actualización del cliente siguen funcionando normalmente, porque su sesión ya está establecida y no pasa por la nueva ruta de autenticación. Solo los dispositivos nuevos fallan. Si ejecutas curl https://your-domain.com/identity/accounts/prelogin/password -X POST -d '{"email":"[email protected]"}' -H 'Content-Type: application/json' y obtienes un 404, tu servidor es demasiado antiguo.
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
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.Actualiza a la imagen más reciente
La solución más segura es usar siempre
vaultwarden/server:latesty mantener la imagen actualizada. Para actualizar:docker pull vaultwarden/server:latest && docker stop vaultwarden && docker rm vaultwarden, luego vuelve a ejecutar el mismodocker runque usaste en la instalación. Vaultwarden preserva los datos en el volumen — no se necesita migración manual.Verifica que la actualización surtió efecto
Tras reiniciar, consulta de nuevo
curl https://your-domain.com/api/versiony 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.Fija una versión si la estabilidad es la prioridad
Si prefieres controlar las actualizaciones manualmente, usa una etiqueta versionada:
vaultwarden/server:1.37.2por 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.
Regresión en 1.37.1: cambio de contraseña maestra bloqueado
La versión 1.37.1 contiene una regresión conocida (issue de GitHub #7659): la solicitud de cambio de contraseña maestra devuelve HTTP 422 con el mensaje missing field newMasterPasswordHash. La operación falla en el servidor sin que el cliente proporcione información útil. La corrección está en la versión 1.37.2, publicada poco después. Si has fijado la versión 1.37.1, actualiza directamente a 1.37.2 — el comando es el mismo que para cualquier actualización: docker pull vaultwarden/server:1.37.2 && docker stop vaultwarden && docker rm vaultwarden, luego reinicia el contenedor con la nueva etiqueta.
Trampa SIGNUPS_ALLOWED=false: solo ponlo después de crear la primera cuenta de administrador
Un error común en la instalación: poner -e SIGNUPS_ALLOWED=false antes de crear la cuenta de administrador. Resultado — tu propia instancia rechaza la creación de cuenta y ya no puedes iniciar sesión. El orden es imperativo: (1) inicia sin este parámetro, (2) crea inmediatamente tu cuenta de administrador desde la interfaz web, (3) solo entonces reinicia el contenedor con SIGNUPS_ALLOWED=false. Si ya te has bloqueado, la salida de emergencia es activar el panel de administración con -e ADMIN_TOKEN=$(openssl rand -base64 48) e invitar al usuario administrador desde /admin.
Copias de seguridad diarias en una línea de cron
Añade esto al crontab de root (crontab -e): 0 3 * * * docker run --rm -v vaultwarden:/data -v /backup:/out busybox tar czf /out/vaultwarden-$(date +%F).tar.gz /data. Ejecútalo cada noche a las 3 AM — el contenido completo de la bóveda (fichero SQLite + adjuntos) aterrizará en /backup como un archivo con marca de tiempo. Envía este directorio a S3 o Backblaze B2 con rclone para protección fuera del sitio.
Documentación oficial
Para la configuración avanzada y las opciones específicas de la herramienta, consulta la documentación oficial de Vaultwarden. Esta guía cubre el despliegue en VPS; la documentación del editor sigue siendo la referencia para ajustes finos, actualizaciones mayores y casos de uso específicos.
