Vaultwarden en tu propio servidor: qué cuesta mantenerlo

Qué es Vaultwarden

Vaultwarden es un servidor de contraseñas escrito para ser compatible con las aplicaciones de Bitwarden. Tú usas las apps de siempre (navegador, móvil, escritorio) y apuntas a tu propio servidor en lugar de al de otra empresa. Es un proyecto de código abierto, ligero, y se distribuye como una imagen de contenedor lista para arrancar.

Instalarlo lleva un rato. Lo que lleva tiempo es lo de después: que siga actualizado, que tenga HTTPS válido, que las copias existan de verdad y que alguien sepa restaurarlas un martes a las nueve de la mañana. Esta guía no te explica solo cómo se instala. Te cuenta qué hay que mantener para que un gestor de contraseñas propio sea una buena idea y no un riesgo.

Un gestor de contraseñas es la pieza más sensible de una empresa. Si se cae, nadie entra a nada. Si se pierde sin copia, se pierde todo a la vez. Por eso conviene mirar el coste real antes de empezar.

¿Te compensa tenerlo en tu propio servidor?

La pregunta correcta no es "¿es gratis?". El programa lo es, pero tu tiempo no. Esta tabla compara las dos opciones por lo que cambia en el día a día.

	Bitwarden en la nube	Vaultwarden en tu servidor
Dónde viven los datos	En la infraestructura del proveedor	En un servidor que controlas tú
Quién actualiza	El proveedor	Tú, o quien administre tu servidor
Quién vigila que esté activo	El proveedor	Tú, con tu propia monitorización
Copias de seguridad	Las gestiona el proveedor	Las montas tú y las pruebas tú
Compatibilidad con las apps	Total, es el producto oficial	Alta, con las apps oficiales de Bitwarden
Qué pasa si algo se rompe	Abres una incidencia con el proveedor	Lo resuelves tú o quien te administre el servidor
Control sobre dónde está el dato	El que ofrezca el proveedor	Total

Cuándo suele compensar

• Quieres que las contraseñas de tu equipo estén en un servidor que controlas, por política interna o por exigencia de un cliente.
• Ya tienes un servidor con Docker y alguien que lo cuida.
• Te importa decidir dónde se guardan las copias y quién puede verlas.
• Eres un equipo pequeño y estable, con pocas altas y bajas de usuarios.

Cuándo suele no compensar

• Nadie en la empresa tiene tiempo para revisar el servidor de forma regular.
• No hay un segundo sitio donde guardar copias cifradas.
• Tu equipo es grande y necesita funciones de organización avanzadas que quizá no estén en la versión ligera. Compruébalo en la documentación del proyecto antes de decidir.
• Lo quieres porque "así no pago", y no porque necesites el control.

Si dudas, empieza por lo segundo: ¿quién se entera si el servicio se cae un sábado? Si la respuesta es "nadie", todavía no estás listo para alojarlo tú.

Qué se instala de verdad

Una instalación sensata de Vaultwarden tiene cinco piezas. Ninguna es complicada por separado. El trabajo está en que las cinco estén bien a la vez y se mantengan así.

El contenedor Docker

Vaultwarden se ejecuta como un contenedor, a partir de la imagen vaultwarden/server. Todo lo que debe sobrevivir (la base de datos, los adjuntos y las claves) se guarda en la carpeta /data del contenedor, que tú montas desde el disco del servidor. Así, si borras o actualizas el contenedor, los datos siguen ahí.

Si es la primera vez que trabajas con contenedores, antes de seguir te conviene leer la guía de Docker en VPS. Un ejemplo mínimo con Docker Compose queda así (parte del que explica el README oficial del proyecto):

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

La línea ports es la que importa: al poner 127.0.0.1 delante, el contenedor solo es accesible desde el propio servidor, y el mundo exterior llega únicamente a través del proxy que verás a continuación. Es una decisión de configuración nuestra, no un requisito del programa: el puerto 8080 es un ejemplo y puedes elegir otro.

Una decisión que te toca tomar es qué etiqueta de la imagen usar. Con latest recibes lo último cada vez que lo descargas, y con una versión fija controlas tú cuándo cambias. Para un servicio de contraseñas, lo prudente es fijar una versión concreta y actualizarla a propósito, tras leer las notas de cambios.

Proxy inverso y HTTPS

Las aplicaciones de Bitwarden y los navegadores exigen HTTPS para trabajar con un servidor de contraseñas. Sin un certificado válido, el navegador no te deja usar las funciones de cifrado que necesita la aplicación web. No es un detalle opcional.

Por eso delante del contenedor va un proxy inverso: un programa que recibe las visitas en el puerto 443, presenta el certificado y reenvía el tráfico al contenedor, que solo escucha en local. Lo explicamos paso a paso en la guía de proxy inverso en VPS. El certificado se obtiene y se renueva con Let's Encrypt, como cuentas en SSL en VPS con Let's Encrypt.

Lo que debes vigilar aquí:

• Que el certificado se renueve solo, y que alguien se entere si deja de hacerlo.
• Que el dominio apunte siempre al servidor correcto.
• Que el valor de DOMAIN coincida con la dirección real con la que entran los usuarios.

Registro cerrado y doble factor

Un servidor de contraseñas abierto a cualquiera que encuentre la dirección es una mala idea. Vaultwarden permite cerrar el registro de usuarios nuevos con la variable SIGNUPS_ALLOWED=false. Una práctica habitual es abrirlo el tiempo justo para crear las cuentas de tu equipo, cerrarlo, y dar de alta a las personas nuevas por invitación cuando haga falta.

Añade el doble factor a cada usuario. Se activa por cuenta, desde los ajustes de seguridad de cada persona, y exige un segundo paso (una app de códigos, por ejemplo) además de la contraseña maestra. Si una contraseña maestra se filtra, el segundo factor es lo que separa el susto del desastre.

    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"

Panel de administración apagado

Vaultwarden incluye un panel de administración en la ruta /admin. Mientras no definas la variable ADMIN_TOKEN, ese panel no existe. Y la mejor decisión suele ser dejarlo así: lo que no está encendido no se puede atacar.

Si algún día lo necesitas, la página de la documentación del proyecto explica cómo activarlo y cómo proteger el token, que funciona como una contraseña del panel. Actívalo, haz lo que tengas que hacer y apágalo de nuevo.

Copia cifrada fuera del servidor

Aquí está la pieza que más se subestima. La base de datos de Vaultwarden es un fichero SQLite que está en uso mientras la gente trabaja. Copiarlo "a pelo" con cp puede dar una copia inconsistente. La documentación del proyecto recomienda usar el comando .backup de sqlite3, que usa la API de copia en caliente de SQLite.

Después, esa copia se envía cifrada a un sitio que no sea el propio servidor. Para eso usamos restic, una herramienta de copias que cifra, deduplica y guarda versiones. Un esquema sencillo, como script de ejemplo (ajusta rutas y destino a tu caso):

#!/usr/bin/env bash
set -euo pipefail

DATOS=/srv/vaultwarden/vw-data
TEMPORAL=/srv/vaultwarden/copia-temporal
export RESTIC_REPOSITORY="sftp:usuario@destino.example.com:/copias/vaultwarden"
export RESTIC_PASSWORD_FILE=/root/.restic-clave

mkdir -p "$TEMPORAL"
sqlite3 "$DATOS/db.sqlite3" ".backup '$TEMPORAL/db.sqlite3'"

restic backup "$DATOS" "$TEMPORAL" --exclude "$DATOS/db.sqlite3*"
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

rm -rf "$TEMPORAL"

El script copia la carpeta de datos (adjuntos y claves incluidos), deja fuera los ficheros vivos de la base de datos y guarda en su lugar la copia consistente. Se programa con cron o con un temporizador de systemd y se ejecuta cada noche.

Dos reglas que no son negociables: la clave de restic se guarda también fuera del servidor (si la pierdes, las copias no se pueden abrir) y el destino debe estar en otro sitio distinto del servidor que protege. Para el marco general, la guía de backups en VPS explica la regla 3-2-1.

Lo que cuesta mantenerlo: el tiempo

Instalar es una tarde. Mantener es una suma de tareas pequeñas que se repiten. Esta tabla es orientativa: depende del número de usuarios y de lo exigente que sea tu política de seguridad.

Tarea	Frecuencia	Qué se mira
Actualizar Vaultwarden y el sistema	Cada mes, y antes si hay un aviso de seguridad	Notas de cambios, copia hecha justo antes, que el servicio arranque y se pueda entrar
Vigilar el servicio	De forma continua, con avisos	Que responda, que el certificado no caduque, que el disco no se llene
Simulacro de restauración	Cada trimestre como referencia	Que la copia más reciente se abre, que la base de datos está completa y que alguien sabe hacerlo
Revisar accesos	Cada trimestre y en cada baja	Usuarios que ya no trabajan contigo, doble factor activo, registro cerrado
Revisar las copias	Cada semana	Que la última se hizo, que pesa lo esperable y que no hay errores en el registro

Fíjate en que ninguna de esas filas es difícil. Lo caro es que haya una persona con la costumbre de hacerlas, y que siga haciéndolas dentro de dos años.

Hay un coste que no aparece en la tabla: la continuidad. Si la persona que montó el servicio cambia de trabajo, de vacaciones o de prioridades, las tareas se quedan sin dueño. Con un gestor de contraseñas eso se nota tarde y de golpe. Antes de empezar, decide quién se encarga, quién lo sustituye y dónde está escrito cómo se hace cada cosa.

Y piensa también en el día de la incidencia. Si Vaultwarden falla un lunes a primera hora, el equipo no puede entrar a sus herramientas hasta que alguien lo arregle. Pregúntate cuánto tiempo puede esperar tu empresa y qué plan alternativo tenéis mientras tanto. Una lista impresa de accesos de emergencia, guardada en un sitio físico seguro, ha sacado de apuros a más de un equipo.

El simulacro de restauración

Una copia que nunca se ha restaurado no está probada. Puede estar vacía, cifrada con una clave que nadie encuentra o incompleta. Lo descubres el día que más la necesitas, que es el peor momento posible.

El simulacro se hace en un entorno aparte, nunca sobre el servidor en producción. Puede ser una máquina de pruebas o un directorio temporal en otro equipo.

1. Comprueba qué copias hay disponibles:

restic snapshots

2. Restaura la última en una carpeta nueva:

restic restore latest --target /tmp/prueba-restauracion

3. Verifica que la base de datos se abre y no está dañada:

sqlite3 /tmp/prueba-restauracion/srv/vaultwarden/copia-temporal/db.sqlite3 "PRAGMA integrity_check;"

La respuesta correcta es ok. La ruta exacta depende de dónde guardaste la copia temporal, así que ajústala.

4. Arranca un Vaultwarden de prueba con esos datos, apuntando a una dirección distinta y sin tráfico real, y entra con una cuenta de prueba. Si ves tus carpetas y tus entradas, la copia sirve.
5. Borra el entorno de prueba cuando termines. Esa carpeta contiene contraseñas.

Apunta cuánto has tardado y qué ha ido mal. Esa nota es lo más valioso del ejercicio: el día de la verdad, tendrás un procedimiento escrito y comprobado en lugar de una intención.

Vigilancia y actualizaciones

Un servicio de contraseñas caído es un problema inmediato para todo el equipo. Necesitas enterarte antes que tus usuarios. La guía de herramientas de monitorización para VPS recoge opciones; lo esencial es vigilar que la dirección responda, que el certificado tenga margen y que el disco no se llene.

Las actualizaciones tienen su ritmo propio. Una rutina razonable:

1. Haz una copia justo antes de tocar nada.
2. Lee las notas de cambios de la versión nueva.
3. Cambia la etiqueta de la imagen y recrea el contenedor.
4. Comprueba que entras, que se sincroniza y que el doble factor sigue funcionando.

docker compose pull
docker compose up -d
docker compose logs --tail 50 vaultwarden

El propio servidor también necesita cuidado. Acceso por clave, sin contraseña, y sin usuario administrador abierto al mundo: lo tienes en la guía de ssh hardening. Y si en tu empresa estás valorando montar más servicios propios, la guía sobre qué instalar para una IA privada en la empresa sigue la misma lógica: lo que se aloja en casa se cuida en casa.

Preguntas frecuentes

Si prefieres no encargarte tú

Lo instalamos en un servidor nuestro o en el tuyo y lo administramos nosotros. Tú usas tus contraseñas, y de las actualizaciones, la vigilancia, las copias y los simulacros nos encargamos nosotros.

Si quieres saber cómo trabajamos, mira la página de administración de servidores. Y si ya tienes claro lo que necesitas, cuéntanoslo.