Alojar Vaultwarden en un VPS administrado: sus contraseñas en su servidor

Qué hace Vaultwarden

Vaultwarden es un servidor de gestión de contraseñas escrito en Rust, pensado para el autoalojamiento. Su wiki lo destina a particulares, familias y organizaciones de tamaño humano. La caja fuerte web se entrega dentro de sus imágenes Docker.

Implementa una API compatible con los clientes oficiales de Bitwarden, en el navegador, el ordenador y el teléfono. El README precisa que el proyecto no está asociado a Bitwarden ni a Bitwarden, Inc., y pide comunicarle directamente cualquier problema, sea cual sea el cliente utilizado, en lugar de dirigirse a los canales de asistencia oficiales.

• La caja fuerte: caja fuerte personal, archivos adjuntos, iconos de los sitios, clave de API personal, y Send para transmitir un texto o un archivo.
• Las organizaciones: colecciones, uso compartido de contraseñas, roles, grupos, registros de eventos y políticas.
• La doble autenticación: aplicación de autenticación, correo electrónico, FIDO2 WebAuthn, YubiKey y Duo.
• Los recursos de rescate: acceso de emergencia y recuperación de cuenta, esta última con el correo electrónico configurado.
• La administración: una página /admin para los ajustes, las cuentas y el diagnóstico.

El wiki enumera también lo que falta respecto al servidor oficial, como el inicio de sesión con clave de acceso, los roles personalizados y algunas políticas de empresa. Precisa que las funciones útiles sobre todo para las grandes organizaciones no son una prioridad del proyecto: lea esa lista si las necesita.

Lo que permite la licencia AGPL-3.0

Vaultwarden se publica bajo la GNU Affero General Public License, versión 3. El texto afirma un permiso ilimitado para ejecutar el programa sin modificar. Puede, por tanto, usar la imagen publicada por el proyecto para su empresa y su equipo, sin ninguna licencia que comprar.

El artículo 13 añade una condición propia de la AGPL: si modifica el programa, su versión debe ofrecer a todos los que la usan a distancia, por la red, el modo de obtener gratuitamente su código fuente.

La instalación con Docker Compose

El README recomienda las imágenes de contenedor. En un servidor con Docker instalado, cree una carpeta y coloque en ella este compose.yaml, tomado del README y del wiki:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

docker compose up -d

• Un puerto publicado en 127.0.0.1: como en el README, Vaultwarden solo es accesible a través del proxy inverso, colocado en el mismo servidor.
• DOMAIN: la dirección base de su instancia, en https. El wiki advierte de que sin ella se rompen funciones, entre ellas los archivos adjuntos y los enlaces de invitación.
• Una carpeta vw-data en un disco local: guarda todos los datos. El wiki señala los problemas de SQLite en un volumen CIFS o Samba, que no gestiona el bloqueo de archivos.
• La etiqueta latest sigue la última versión publicada, y el wiki la recomienda para la mayoría de los usos. Una etiqueta como 1.37.5 fija una versión, y latest-alpine ofrece lo mismo sobre una base Alpine.

Su nombre de dominio apunta al servidor con registros A y AAAA, y los visitantes llegan por los puertos 80 y 443. Mientras el proxy inverso no esté en su sitio, la caja fuerte web sigue siendo inutilizable: pase directamente a la sección siguiente.

El proyecto no cifra ni la memoria ni el procesador; se presenta solo como una solución para los casos en que el servicio oficial, exigente en recursos, no conviene. El tamaño depende del número de cuentas y del volumen de los archivos adjuntos. En un VPS administrado, descríbanos su uso y le recomendamos el tamaño adecuado.

HTTPS y WebSocket: el proxy inverso

La caja fuerte web se apoya en la API Web Crypto, que los navegadores reservan a los contextos seguros: el README indica que solo funciona una vez activado HTTPS, y el wiki considera HTTPS «pretty much required», es decir, casi obligatorio. El proyecto recomienda un proxy inverso delante de Vaultwarden y desaconseja el TLS integrado en su framework Rocket.

Use un certificado reconocido, como los de Let’s Encrypt, que recomienda el wiki: con un certificado autofirmado, algunas plataformas rechazan la conexión. El certificado debe incluir su cadena completa, sin lo cual los dispositivos Android no se conectan.

Las notificaciones WebSocket, activas por defecto, avisan al navegador, a la aplicación de escritorio y a la extensión de que una entrada ha cambiado. Pasan por el puerto HTTP principal, y el proxy debe transmitir las cabeceras Upgrade y Connection. Las aplicaciones móviles usan las notificaciones nativas de su sistema, que se configuran aparte.

Con Caddy

El wiki aconseja mirar primero Caddy si no tiene preferencia: activa HTTPS por sí mismo, obtiene el certificado de Let’s Encrypt y admite WebSocket. El ajuste del wiki transmite además a Vaultwarden la dirección real del visitante, para sus registros:

vault.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Con Nginx y Certbot

Este bloque recoge el ejemplo de Nginx del wiki, reducido al puerto 80 para dejar que Certbot instale HTTPS:

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8000;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;
    server_name vault.example.com;

    client_max_body_size 525M;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    location / {
      proxy_pass http://vaultwarden-default;
    }
}

Certbot instala después el certificado y se encarga de renovarlo:

sudo certbot --nginx

Comprobar WebSocket

Abra las herramientas de desarrollo del navegador, pestaña de red, filtro WS, y vuelva a conectarse a la caja fuerte: una respuesta 101 en /notifications/hub confirma la conexión. Otra prueba del wiki: abra la caja fuerte en dos navegadores, cambie el nombre de una entrada en uno y el cambio aparece enseguida en el otro.

Cerrar los registros

Por defecto, cualquier persona que llegue a su instancia puede crear en ella una cuenta. Es útil para su primera cuenta, y el wiki recomienda cerrar después los registros, para impedir que un atacante cree una.

1. Abra su dirección HTTPS y cree su cuenta; después, conecte sus aplicaciones a esa dirección.
2. Cambie SIGNUPS_ALLOWED a "false" en compose.yaml.
3. Reinicie con docker compose up -d: una variable de entorno está ligada al contenedor, que debe recrearse para tenerla en cuenta.

SIGNUPS_ALLOWED: "false"

• Las invitaciones siguen abiertas tras el cierre: los propietarios y los administradores de una organización pueden invitar a nuevas personas. INVITATIONS_ALLOWED en "false" retira esa posibilidad, y el wiki deja esa decisión según la confianza que tenga en sus usuarios.
• Una lista de dominios: SIGNUPS_DOMAINS_WHITELIST limita el registro a ciertos dominios de correo, y SIGNUPS_VERIFY en true impone entonces verificar la dirección. Cuando se define esta lista, SIGNUPS_ALLOWED se ignora.
• La página de administración permite invitar a cualquiera, sean cuales sean estas restricciones.

En cuanto guarda la configuración desde la página de administración, nace un archivo config.json en la carpeta de datos y prevalece sobre las variables de entorno. Los ajustes afectados se cambian entonces desde esa página: modificar compose.yaml ya no basta.

La página de administración y su token

La página /admin sirve para configurar Vaultwarden, ver y eliminar las cuentas y las organizaciones, retirar la doble autenticación de un usuario, invitar y leer el diagnóstico. Sin ADMIN_TOKEN, permanece desactivada: si no la necesita, déjela así.

El wiki recomienda encarecidamente activar HTTPS antes de usar esta página. El token hace de contraseña, y puede guardarse en forma de hash, en argon2id, en lugar de en claro en la configuración. Vaultwarden proporciona el comando: pide la contraseña dos veces y devuelve una cadena PHC.

docker run --rm -it vaultwarden/server /vaultwarden hash

Coloque esa cadena en un archivo .env, junto a compose.yaml, entre comillas simples, y llámela después desde el servicio:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Compruebe el resultado, reinicie y conéctese después a /admin con su contraseña, y no con la cadena PHC:

docker compose config
docker compose up -d

• La sesión dura 20 minutos por defecto, ajustables con ADMIN_SESSION_LIFETIME. Una sesión abierta sigue siendo válida tras cambiar el token. Para cerrarlas todas, elimine rsa_key.pem de la carpeta de datos y reinicie, lo que desconecta también a los usuarios y anula las invitaciones pendientes.
• Un acceso reducido: los ejemplos de proxy del wiki muestran cómo abrir /admin solo a ciertas direcciones, o añadirle una autenticación HTTP.
• DISABLE_ADMIN_TOKEN elimina todo control: está previsto para una capa de autenticación separada colocada delante, y el wiki lo reserva a quienes saben lo que hacen.

Lo que protege la caja fuerte

La primera protección es la contraseña maestra. Los datos de la caja fuerte se cifran con claves personales o de organización: quien obtiene una copia de la base o fuerza una sesión debe aún descifrar esa contraseña para leerlos. Su solidez cuenta, por tanto, ante todo. Una sesión de administración permite por sí sola eliminar una cuenta o retirar una doble autenticación, sin dar acceso a los datos de la caja fuerte.

Prepare el olvido de la contraseña maestra antes de que ocurra: active el acceso de emergencia de su cuenta y, en una organización, la recuperación de cuenta, que requiere el correo electrónico configurado.

Tres ajustes más, tomados de la guía de refuerzo

• Una cuenta sin privilegios de root: la imagen se ejecuta como root por defecto, y el wiki considera preferible darle los mínimos derechos. Añada user: 1000:1000 al servicio, con una carpeta vw-data que pertenezca a ese usuario.
• Los registros del proxy: la conexión WebSocket pasa un token en la dirección, en access_token. Si su proxy conserva sus registros o los envía a un servicio externo, el wiki recomienda ocultar ese valor.
• El mínimo de montajes: monte la carpeta de datos y nada más, ni su carpeta personal ni /var/run/docker.sock.

SQLite, MariaDB o PostgreSQL

La misma imagen admite las tres bases de datos. El wiki describe SQLite como la más usada y la más probada, y la recomienda para la mayoría de los usos, salvo que necesite otra por una razón concreta.

DATABASE_URL: "postgresql://user_name:user_password@db_host:5432/vaultwarden"

Cree una base vacía y su usuario: al arrancar, Vaultwarden crea en ella su propio esquema. Una contraseña con caracteres especiales se escribe con codificación porcentual en esta dirección.

Tome esta decisión antes de llenar la caja fuerte. El wiki describe un paso de SQLite a PostgreSQL con pgloader, precisando que el proyecto no admite esa vía, que se hace bajo su responsabilidad y que empieza por una copia de seguridad.

Los correos electrónicos: la configuración SMTP

Vaultwarden arranca sin correo electrónico, pero varias funciones dependen de él: las invitaciones, la verificación de las direcciones, el envío de las pistas de contraseña, la doble autenticación por correo y la recuperación de cuenta.

En un VPS de Simafri, el envío pasa por un relé SMTP autenticado, en el puerto 587: la dirección de una cuenta de correo que ya tenga, o Simafri Suite. La contraseña se coloca en el archivo .env, como el token de administración:

SMTP_HOST: "smtp.example.com"
SMTP_FROM: "vault@example.com"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "vault@example.com"
SMTP_PASSWORD: ${VAULTWARDEN_SMTP_PASSWORD}

• Los enlaces de invitación se construyen a partir de DOMAIN y siguen siendo válidos 5 días.
• Microsoft: el wiki indica que Hotmail, Outlook y Office 365 exigen ahora OAuth2, que Vaultwarden aún no admite. El error que hay que reconocer es No compatible authentication mechanism was found.
• Gmail: prevea una contraseña de aplicación, según el wiki.
• La prueba: la página de administración envía un correo de prueba. Si cambia en ella un ajuste SMTP, guarde primero, porque la prueba usa los ajustes guardados, y ese guardado crea config.json.

Si no sale nada, el wiki propone probar la conexión al relé desde el servidor. El comando devuelve 0 cuando el relé responde:

timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587'; echo $?

Las copias de seguridad

El README recuerda que el proyecto no puede responsabilizarse de una pérdida de datos y recomienda encarecidamente copias de seguridad periódicas. El wiki las aconseja automáticas, con al menos una copia en otro lugar. Esto es lo que contiene la carpeta de datos con SQLite:

La base, con el servicio en marcha

Desde la versión 1.32.1, Vaultwarden sabe copiar él mismo su base SQLite, sin detener el servicio:

docker exec -it vaultwarden /vaultwarden backup

El comando escribe un archivo db_AAAAMMJJ_HHMMSS.sqlite3 junto a la base, en vw-data. La imagen no contiene ni sqlite3 ni cron: el wiki aconseja programar la tarea en el servidor, al menos una vez al día. Quite entonces -it, porque una tarea programada no tiene terminal, y haga limpieza entre esos archivos, que se acumulan.

Toda la carpeta, con el servicio detenido

Cuando la base no se está usando, basta una simple copia de todos sus archivos. Es el método con el servicio detenido que el wiki da como ejemplo para Docker, y se lleva también los archivos adjuntos:

docker compose down
tar -czf vaultwarden-$(date +%F).tar.gz vw-data
docker compose up -d

El wiki considera útil una capa de cifrado, sobre todo cuando la copia contiene el token de administración y los accesos SMTP, y cita rclone, restic y rustic para enviar las copias lejos. Con MariaDB o PostgreSQL, añada una exportación de la base a la carpeta vw-data.

El wiki pide no confiar únicamente en las instantáneas de disco, más delicadas de restaurar. Conserve, por tanto, estas copias propias de la aplicación: colocadas en el disco del servidor, entran también en sus copias de seguridad nocturnas.

Restaurar

1. Detenga Vaultwarden.
2. Sustituya cada archivo o carpeta de vw-data por su versión guardada.
3. Si la base procede de /vaultwarden backup, llámela db.sqlite3 y elimine antes cualquier archivo db.sqlite3-wal existente: un registro que no corresponda puede corromper la base. Si procede de una copia directa, restaure juntos db.sqlite3 y su db.sqlite3-wal.
4. Reinicie y compruebe que puede abrir la caja fuerte.

El wiki aconseja repetir este ejercicio de vez en cuando, conservando una copia de los datos en su sitio: así comprueba que una copia de seguridad funciona.

Las actualizaciones

El wiki da dos comandos, desde la carpeta del compose.yaml. La carpeta de datos se queda en su sitio:

docker compose pull
docker compose up -d

Estas actualizaciones cuentan más que en otros casos. Las aplicaciones móviles y las extensiones del navegador se actualizan por sí solas, y el wiki advierte de que una diferencia de versión con el servidor puede provocar fallos repentinos. La caja fuerte web, entregada en la imagen, siempre queda acorde con su servidor.

El proyecto no tiene calendario de versiones: siga sus notas de versión y haga una copia de seguridad justo antes de cada actualización. Algunas incluyen correcciones de seguridad, como la 1.37.5 del 1 de noviembre de 2026, cuyas notas recomiendan actualizar cuanto antes. Esas notas advierten además de que, desde la 1.37.5, un valor de configuración no válido impide que Vaultwarden se inicie: revise su archivo de entorno antes de actualizar. La página de diagnóstico de /admin indica si existe una versión más reciente.

Quién hace qué en un VPS administrado

El autoalojamiento exige mantener el servidor además de la aplicación. En un VPS administrado, nuestros equipos se encargan del servidor y siguen su instancia de forma proactiva; Vaultwarden sigue siendo su software, con sus ajustes y sus datos.

Si prefiere que nuestros equipos intervengan en la propia aplicación, ese servicio se factura por horas o a precio cerrado, con un presupuesto comunicado antes de la intervención.