Monta Vaultwarden con Caddy y HTTPS local en Docker Compose

Despliega Vaultwarden detrás de Caddy con versiones fijadas, registros cerrados, panel de administración con token hasheado y copias de seguridad restauradas.

Laboratorio · Self-hosting

50 min nivel medio configuración validada

Qué vas a montar y por qué

Vaultwarden es un servidor compatible con Bitwarden escrito en Rust: sirve para guardar tus contraseñas en tu propia máquina y usarlas desde los clientes oficiales de Bitwarden. En este laboratorio lo montas con Docker Compose junto a Caddy, que se encarga del HTTPS, con las imágenes fijadas a una versión exacta para que una actualización no te sorprenda.

Seguirás un orden defensivo: primero HTTPS (el panel de administración no debería activarse sin él), después registros cerrados tras crear tu cuenta, un token de administración guardado como hash argon2id y, al final, una copia de seguridad que arrancas en un contenedor temporal para comprobar que sirve. Todo vive en un único directorio y se elimina con un solo comando.

Sustituye siempre los marcadores CHANGE_ME_… por tus valores. Para uso doméstico sin dominio público, Caddy emite certificados de una CA local propia para hostnames internos como localhost; la primera vez puede pedirte una contraseña para instalar su certificado raíz en el almacén de confianza (solo ocurre una vez por certificado raíz), y los clientes que no confíen en esa CA mostrarán errores de seguridad.

Requisitos

Paso a paso

1. Crea el proyecto, el Caddyfile y el Compose con versiones fijadas

   Crea un directorio de trabajo y, antes de ejecutar nada con Compose, crea el Caddyfile: el Compose lo monta como fichero y, si no existe cuando haces docker compose up, Docker crea un directorio con ese nombre y Caddy no arranca. Por eso el Caddyfile va primero en este paso.

   Caddy sirve por HTTPS todo sitio con host definido y, para localhost, firma certificados con su propia CA local. El bloque log con roll_size y roll_keep rota el registro de acceso en el propio Caddy. header_up X-Real-IP pasa la IP real del cliente a Vaultwarden para que quede en sus registros. Las variables {$DOMAIN} y {$LOG_FILE} las lee Caddy de su entorno, definido en el servicio caddy del Compose.

   Las dos imágenes llevan una etiqueta exacta (vaultwarden/server:1.37.4 y caddy:2.11.7) en lugar de latest: así una actualización es una decisión tuya, no un efecto secundario de pull. Vaultwarden no publica ningún puerto en el host: solo Caddy lo alcanza por la red privada que Compose crea. SIGNUPS_ALLOWED arranca en true únicamente para que puedas crear tu cuenta; lo cerraremos en el paso 3. DOMAIN debe ser la URL https, porque Vaultwarden necesita saber que va sobre https para funcionar bien con los adjuntos. Si tienes un dominio propio, sustituye https://localhost en ambas variables DOMAIN por tu dominio (CHANGE_ME_DOMAIN); con un nombre DNS público Caddy usaría una CA pública, lo que exige puertos 80 y 443 accesibles desde fuera. El puerto 80 se publica para la redirección de HTTP a HTTPS, que Caddy aplica por defecto.

   $ mkdir -p ~/vaultwarden && cd ~/vaultwarden
   $ mkdir -p vw-data caddy-config caddy-data backups

   Fichero Caddyfile

   {$DOMAIN} {
   	log {
   		level INFO
   		output file {$LOG_FILE} {
   			roll_size 10MB
   			roll_keep 10
   		}
   	}
   
   	encode zstd gzip
   
   	reverse_proxy vaultwarden:80 {
   		header_up X-Real-IP {remote_host}
   	}
   }

   Fichero compose.yaml

   services:
     vaultwarden:
       image: vaultwarden/server:1.37.4
       container_name: vaultwarden
       restart: always
       environment:
         DOMAIN: "https://localhost"
         SIGNUPS_ALLOWED: "true"
       volumes:
         - ./vw-data:/data
   
     caddy:
       image: caddy:2.11.7
       container_name: caddy
       restart: always
       ports:
         - 80:80
         - 443:443
         - 443:443/udp
       volumes:
         - ./Caddyfile:/etc/caddy/Caddyfile:ro
         - ./caddy-config:/config
         - ./caddy-data:/data
       environment:
         DOMAIN: "https://localhost"
         LOG_FILE: "/data/access.log"

2. Arranca los contenedores

   Con el Caddyfile y el compose.yaml ya en el directorio, levanta el proyecto. Compose crea la red privada, descarga las dos imágenes con la etiqueta fijada y arranca ambos servicios. Revisa los registros de Caddy para confirmar que no hay errores de configuración.

   $ docker compose up -d
   $ docker compose logs --tail 20 caddy

3. Crea tu cuenta, cierra los registros y protege el panel de administración

   Abre https://localhost, acepta el aviso del certificado local (o instala la CA de Caddy como de confianza) y crea tu cuenta con una contraseña maestra larga. Después cierra los registros: en el Compose siguiente SIGNUPS_ALLOWED pasa a "false", para que nadie más pueda registrarse.

   El panel /admin solo se activa si defines ADMIN_TOKEN. Se recomienda activar HTTPS antes (ya lo tienes) y guardar el token como hash argon2id (cadena PHC) en lugar de texto plano. Genera el hash con el comando integrado vaultwarden hash: te pide la contraseña dos veces e imprime el hash. La contraseña con la que lo creas será la que uses para entrar en /admin; la sesión del panel dura 20 minutos por defecto (ADMIN_SESSION_LIFETIME la modifica, pero no la alargues sin necesidad).

   Al poner el hash en environment, según la documentación de Vaultwarden hay que escapar cada $ del hash duplicándolo como $$; si no, Compose intenta interpolarlo. Escribe el hash directamente en el Compose con los $$, reemplazando CHANGE_ME_ARGON2_PHC_STRING por el hash generado con cada $ duplicado. Después aplica los cambios recreando el contenedor: sin este paso los registros seguirían abiertos y el panel desactivado.

   $ docker run --rm -it vaultwarden/server:1.37.4 /vaultwarden hash

   Fichero compose.yaml

   services:
     vaultwarden:
       image: vaultwarden/server:1.37.4
       container_name: vaultwarden
       restart: always
       environment:
         DOMAIN: "https://localhost"
         SIGNUPS_ALLOWED: "false"
         ADMIN_TOKEN: CHANGE_ME_ARGON2_PHC_STRING
       volumes:
         - ./vw-data:/data
   
     caddy:
       image: caddy:2.11.7
       container_name: caddy
       restart: always
       ports:
         - 80:80
         - 443:443
         - 443:443/udp
       volumes:
         - ./Caddyfile:/etc/caddy/Caddyfile:ro
         - ./caddy-config:/config
         - ./caddy-data:/data
       environment:
         DOMAIN: "https://localhost"
         LOG_FILE: "/data/access.log"

   Sustituye cada valor CHANGE_ME_… por uno tuyo antes de arrancar: no dejes contraseñas ni claves de ejemplo.

   $ docker compose up -d

4. Haz una copia de seguridad y restáurala para comprobarla

   Los datos viven en ./vw-data: la base SQLite (db.sqlite3), los adjuntos (attachments), config.json si has usado el panel, los ficheros rsa_key* y, opcionalmente, sends. No copies la base en uso con cp: la documentación recomienda el respaldo de SQLite por su API de copia en línea. Desde la versión 1.32.1 hay un comando integrado, vaultwarden backup, que evita instalar sqlite3 (la imagen no lo incluye). El comando deja un fichero de respaldo de SQLite en la carpeta de datos.

   Copia a ./backups ese fichero de respaldo y los ficheros rsa_key*. Los directorios attachments y sends y el fichero config.json pueden no existir: según la documentación, attachments no está presente si nunca se creó un adjunto y config.json solo existe si se ha configurado desde el panel. Por eso se copian aparte y con una comprobación previa: omite los que no existan. Si cifras la copia, hazlo sobre todo por config.json, que puede contener el token de administración y credenciales SMTP en claro.

   Una copia que nunca has restaurado no es una copia. Para comprobarla, monta la copia como carpeta de datos de un contenedor temporal de Vaultwarden sin Caddy (Vaultwarden usa por defecto db.sqlite3, así que renombra el respaldo a ese nombre en la carpeta de prueba). El contenedor se lanza en segundo plano con -d; lee sus registros con docker logs y, al terminar, deténlo con docker stop (como se creó con --rm, se elimina solo).

   $ docker exec -it vaultwarden /vaultwarden backup
   $ ls -l vw-data
   $ mkdir -p backups/vw-copia
   $ cp vw-data/db_*.sqlite3 backups/vw-copia/
   $ cp -a vw-data/rsa_key* backups/vw-copia/
   # attachments, sends y config.json pueden no existir: copia solo los que veas en el listado
   $ [ -d vw-data/attachments ] && cp -a vw-data/attachments backups/vw-copia/
   $ [ -d vw-data/sends ] && cp -a vw-data/sends backups/vw-copia/
   $ [ -f vw-data/config.json ] && cp -a vw-data/config.json backups/vw-copia/
   $ ls -l backups/vw-copia

   Salida esperada (ilustrativa: el formato exacto puede variar)

   -rw-r--r-- 1 root root  ... db.sqlite3
   -rw-r--r-- 1 root root  ... db_<marca-de-tiempo>.sqlite3
   drwxr-xr-x 2 root root  ... icon_cache
   -rw------- 1 root root  ... rsa_key.pem

   Salida esperada (ilustrativa: el formato exacto puede variar)

   -rw-r--r-- 1 root root  ... db_<marca-de-tiempo>.sqlite3
   -rw------- 1 root root  ... rsa_key.pem

   $ mkdir -p backups/prueba-restauracion
   $ cp -a backups/vw-copia/. backups/prueba-restauracion/
   $ cp backups/prueba-restauracion/db_*.sqlite3 backups/prueba-restauracion/db.sqlite3
   $ docker run -d --rm --name vw-restore-test -v "$(pwd)/backups/prueba-restauracion:/data" vaultwarden/server:1.37.4
   $ docker logs vw-restore-test
   $ docker stop vw-restore-test

Comprueba que funciona

1. Comprueba que HTTPS responde

   Pide la cabecera de la web por HTTPS. Usa --insecure solo si aún no has confiado en la CA local de Caddy; con la CA instalada puedes omitirlo.

   $ curl --insecure --head https://localhost

   Salida esperada (ilustrativa: el formato exacto puede variar)

   HTTP/2 200

2. Comprueba que los registros están cerrados y que el cliente funciona

   Abre la web de Vaultwarden e intenta crear otra cuenta: no debería permitírtelo. Después, en el cliente (extensión de navegador o aplicación), elige «Autoalojado» y escribe https://localhost como URL del servidor. Inicia sesión con tu cuenta y guarda un elemento de prueba. Si el cliente no acepta el certificado, instala la CA raíz de Caddy como de confianza en ese dispositivo.

3. Verifica la copia de seguridad

   Comprueba que el respaldo con marca de tiempo existe y no está vacío, y que el contenedor temporal del paso 4 arrancó sin errores en los registros que mostró docker logs. Revisa también los registros del servicio principal.

   $ ls -l backups/vw-copia/db_*.sqlite3
   $ docker compose logs --tail 20 vaultwarden

$ find caddy-data -name root.crt

$ docker compose logs --tail 30 caddy

$ docker compose pull
$ docker compose up -d

$ cd ~/vaultwarden
$ docker compose down
$ cd ..
$ rm -rf vaultwarden

Fuentes

• Vaultwarden: Using Docker Compose github.com
• Vaultwarden: Enabling admin page github.com
• Vaultwarden: Backing up your vault github.com
• Caddy: Automatic HTTPS caddyserver.com
• Vaultwarden: Releases github.com

Artículos relacionados de LaRebelión

Monta Audiobookshelf con Caddy y HTTPS en Docker ComposeMonta tu propio router de modelos con Rebel Router

Artículo generado mediante AI.larebelion