Cómo alojar Vaultwarden por cuenta propia en 2026: dominios, SMTP y backups seguros

Hay dos versiones de “ejecutar Vaultwarden”: que exista un container o que el servicio cumpla realmente su función. Solo importa la segunda. Aquí, la prueba consiste en iniciar sesión desde una browser extension, crear un elemento, sincronizar un segundo cliente, subir un attachment y recuperar un Send después de reiniciar.

Vaultwarden cumple este propósito: es un password server compacto compatible con Bitwarden. El despliegue debe conservar los componentes que hacen posible ese comportamiento; un puerto, un volumen y un certificado son entradas, no el resultado.

Los volúmenes son solo la primera capa de recuperación

El conjunto de recuperación persistente incluye la base de datos, los attachments, los Sends, las claves y la configuración de /data. Monta /data antes del bootstrap, escribe datos de prueba inofensivos y reemplaza el container para demostrar que esa ruta es realmente persistente. Un volumen protege los datos frente al reemplazo del container, pero no frente a la pérdida del host, el borrado accidental o la corrupción a nivel de aplicación.

Haz backups que entiendan el origen de los datos: usa logical dumps para bases de datos activas cuando sea necesario y copia archivos únicamente desde un estado consistente. Mantén una copia cifrada fuera del host de Vaultwarden. El criterio de aceptación de una restauración es específico: los elementos del vault, los attachments, los Sends y la pertenencia a organizaciones deben sincronizarse correctamente con un cliente limpio después de la restauración. La guía de backups cuya restauración se ha probado explica por qué el éxito del job por sí solo no es suficiente.

Inicia Vaultwarden sin ocultar los componentes

Inicia Vaultwarden de forma que la ruta permanezca privada hasta completar el bootstrap.

docker run -d \
  --name vaultwarden \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v vaultwarden-data:/data \
  -e ADMIN_TOKEN=replace-with-a-long-random-value \
  vaultwarden/server:latest

Si el proceso entra en un bucle, compara el usuario esperado por la image con el propietario de cada ruta montada. Si permanece activo, prueba localmente el puerto 80 y pasa directamente al flujo de trabajo: inicia sesión desde una browser extension, crea un elemento, sincroniza un segundo cliente, sube un attachment y recupera un Send después de reiniciar. Fija la versión de la image solo después de superar esa comprobación end-to-end y registra la configuración exacta junto al servicio.

Define los límites de ejecución de Vaultwarden

Define tres límites alrededor de Vaultwarden: la entrada al puerto 80, el estado persistente y los requisitos de soporte. El container se puede reemplazar, pero los otros dos necesitan responsables explícitos. El requisito externo de Vaultwarden es disponer de SMTP operativo si se necesitan invitaciones y correos de emergency access. Prueba el DNS saliente, TLS y el comportamiento del proveedor sin publicar otro servicio entrante.

El diagrama está completo cuando un cliente limpio puede iniciar sesión desde una browser extension, crear un elemento, sincronizar un segundo cliente, subir un attachment y recuperar un Send después de reiniciar. Recopila datos de tiempos y recursos sobre el volumen de attachments, la contención de escritura de SQLite o los límites del pool de la base de datos, así como sobre la latencia de SMTP durante las invitaciones. Si la transacción falla, el primer límite que no se comporte como está documentado indica si debes investigar el routing, la capacidad local o un servicio de soporte.

Mantén separadas las URL internas y externas

Evita usar origins públicos temporales y permanentes para Vaultwarden. En su lugar, establece DOMAIN con el origin HTTPS externo exacto, apunta el nombre DNS elegido a la ruta de la plataforma y haz proxy únicamente al puerto 80.

Ejecuta esta acción desde fuera del host: inicia sesión desde una browser extension, crea un elemento, sincroniza un segundo cliente, sube un attachment y recupera un Send después de reiniciar. Si falla el ingress, la guía para solucionar errores 502 cubre los errores de puerto y listener. Si Vaultwarden recibe la solicitud, pero DOMAIN es HTTP mientras el navegador requiere un origin seguro para las funciones del vault, las pruebas ya apuntan más allá del proxy.

Una ejecución de aceptación de producción para Vaultwarden

Un production gate para Vaultwarden debe poder ejecutarlo alguien que no haya creado el despliegue. Entrega a esa persona la versión fijada, una cuenta de prueba sin datos sensibles y esta tarea: iniciar sesión desde una browser extension, crear un elemento, sincronizar un segundo cliente, subir un attachment y recuperar un Send después de reiniciar. Si las instrucciones requieren acceso al shell no documentado, el servicio aún no está listo desde el punto de vista operativo.

Repite el gate después de reemplazar únicamente el container. Luego restaura la base de datos, los attachments, los Sends, las claves y la configuración de /data en una infraestructura vacía, y demuestra que los elementos del vault, los attachments, los Sends y la pertenencia a organizaciones se sincronizan correctamente con un cliente limpio después de la restauración. Mide el volumen de attachments, la contención de escritura de SQLite o los límites del pool de la base de datos, así como la latencia de SMTP durante las invitaciones en ambas ejecuciones correctas; las diferencias inesperadas suelen revelar la ausencia de una caché, un índice, un worker o un montaje de datos.

Añade un failure drill: deniega temporalmente la ruta de prueba utilizada por el SMTP operativo cuando se necesitan invitaciones y correos de emergency access. Vaultwarden debe emitir un error útil, conservar el estado existente y recuperarse cuando vuelva a cumplirse la condición válida. Guarda las marcas de tiempo y las líneas de log relevantes, con los secrets redactados. Estas pruebas se convierten en la referencia para el siguiente cambio de image o configuración.

Supervisa la carga de trabajo, no solo el container

Un container en estado correcto es necesario, pero no suficiente. El indicador de nivel de servicio es completar correctamente “iniciar sesión desde una browser extension, crear un elemento, sincronizar un segundo cliente, subir un attachment y recuperar un Send después de reiniciar”, mientras que las señales de presión más probables son el volumen de attachments, la contención de escritura de SQLite o los límites del pool de la base de datos, y la latencia de SMTP durante las invitaciones.

El control de cambios es importante porque las migraciones de la base de datos de Vaultwarden y la compatibilidad con los clientes de Bitwarden deben comprobarse conjuntamente; la rotación de ADMIN_TOKEN es un cambio de acceso administrativo, no una migración de los datos del vault. Conserva la image anterior, prueba las migraciones con una copia del estado y documenta si se admite el rollback después de mover el schema. Si DOMAIN es HTTP mientras el navegador requiere un origin seguro para las funciones del vault, diagnostica el primer límite que difiera del entorno operativo.

Cierra el acceso temporal de configuración

Un despliegue seguro de Vaultwarden empieza eliminando privilegios. Evita usar un admin token débil o dejar los sign-ups abiertos; en su lugar, desactiva el sign-up abierto cuando termine el enrollment, protege la página de administración con un token robusto y exige HTTPS para cada cliente del vault.

Sustituye inmediatamente el ADMIN_TOKEN de ejemplo, guárdalo fuera de la image y rótalo como una credencial de administrador si queda expuesto. Restringe las rutas administrativas, usa DNS privado para las dependencias y revisa cada bind mount. Cuando los logs se envíen de forma centralizada, filtra los secrets y el contenido privado antes de que salgan del servidor.

Usa Dockup para la capa de plataforma

Dockup elimina el trabajo manual de reverse proxy y lifecycle alrededor de Vaultwarden. Durante los reemplazos, el servicio recibe una ruta HTTPS estable al puerto 80, configuración inyectada y almacenamiento persistente. Un customer server conectado sigue el mismo modelo que el compute alojado en Dockup.

Después del lanzamiento, cumple el contrato de la aplicación: establece DOMAIN con el origin HTTPS externo exacto, permite y verifica que SMTP funcione cuando se necesiten invitaciones y correos de emergency access, y ejecuta esta prueba: inicia sesión desde una browser extension, crea un elemento, sincroniza un segundo cliente, sube un attachment y recupera un Send después de reiniciar. Así, la experiencia de un solo clic sigue siendo útil sin ocultar los detalles que hacen que Vaultwarden sea recuperable y seguro.

Preguntas frecuentes

¿Qué necesita Vaultwarden para un despliegue de producción?

Enruta el container de Vaultwarden en el puerto 80 a través de un único origin HTTPS. El requisito externo de entrega es disponer de SMTP operativo cuando se necesiten invitaciones y correos de emergency access. No consideres que Vaultwarden está listo hasta que puedas iniciar sesión desde una browser extension, crear un elemento, sincronizar un segundo cliente, subir un attachment y recuperar un Send después de reiniciar.

¿Qué datos de Vaultwarden deben incluirse en un backup?

Haz persistente /data e incluye la base de datos, los attachments, los Sends, las claves y la configuración de /data en el mismo recovery manifest. Una restauración limpia de Vaultwarden solo es válida cuando los elementos del vault, los attachments, los Sends y la pertenencia a organizaciones se sincronizan correctamente con un cliente limpio después de la restauración.

¿Vaultwarden necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origin público de Vaultwarden y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de Vaultwarden: establece DOMAIN con el origin HTTPS externo exacto. En Vaultwarden, HTTPS protege las credenciales y el contenido del usuario durante el tránsito, y mantiene coherente el comportamiento del cliente sensible al origin.

¿Cómo se debe probar una actualización de Vaultwarden?

Restaura el estado actual de Vaultwarden en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las migraciones de la base de datos de Vaultwarden y la compatibilidad con los clientes de Bitwarden deben comprobarse conjuntamente; la rotación de ADMIN_TOKEN es un cambio de acceso administrativo, no una migración de los datos del vault. Conserva la image anterior de Vaultwarden hasta comprender los límites de la migración de datos y del rollback.