Autoalojar Bitwarden: guía completa para tu propio servidor

Las contraseñas continúan siendo la puerta de entrada favorita de muchos ataques: se calcula que alrededor del 81 % de las brechas de datos tiene relación con credenciales débiles, reutilizadas o robadas. Además, solo una de cada tres personas en Estados Unidos utiliza un gestor de contraseñas, y el coste medio de una filtración en 2025 se sitúa en unos 4,44 millones de dólares. Bitwarden es un gestor de código abierto con aplicaciones para navegador, escritorio y móvil, y su versión autoalojada permite guardar las bóvedas cifradas del equipo en un servidor propio. La clave está en que tú decides dónde vive la bóveda y quién puede tocar la infraestructura.

Hay dos caminos principales: el servidor oficial de Bitwarden, que se despliega con Docker en Linux o Windows y ofrece el ecosistema completo de la marca, y Vaultwarden, una reimplementación no oficial escrita en Rust que consume muchísimos menos recursos. Ambos hablan el mismo protocolo y funcionan con los clientes oficiales, así que la compatibilidad con las apps de Bitwarden está garantizada en los dos casos, aunque cambian el soporte, el mantenimiento y algunas funciones disponibles.

Qué te aporta tener la bóveda en tu propio servidor

Al montar Bitwarden en un VPS o en una máquina propia ganas soberanía sobre los datos: el almacén cifrado no sale de una infraestructura que controlas. También obtienes disponibilidad continua, recursos dedicados de CPU, RAM y disco, y la posibilidad de escalar desde un uso personal hasta un equipo mediano sin cambiar de herramienta. A eso se suma un coste bastante contenido frente a mantener hardware físico y la ventaja de contar con protecciones habituales del proveedor, como mitigación DDoS, copias periódicas y seguridad de red. Control, disponibilidad y coste razonable van de la mano en este tipo de despliegue.

La diferencia práctica entre el Bitwarden oficial y Vaultwarden aparece cuando hablamos de soporte. El servidor oficial está pensado para entornos empresariales, con contratos, auditorías y garantías para integraciones con terceros; Vaultwarden es un proyecto comunitario sin SLA ni soporte comercial, pero desbloquea funciones que en Bitwarden suelen requerir plan de pago, como organizaciones, autenticación en dos pasos, Bitwarden Send, TOTP o adjuntos. Para una empresa con exigencias formales, el oficial suele encajar mejor; para un homelab o un grupo pequeño, Vaultwarden resulta muy tentador.

Si eliges un VPS, conviene buscar acceso root, compatibilidad con Docker y una IP pública estable. Hay proveedores que ofrecen procesadores AMD Ryzen 9 de hasta 5,7 GHz, almacenamiento NVMe, conexiones de hasta 40 Gbps, un SLA del 99,95 % y presencia en una docena de ciudades. Como referencia, para menos de diez usuarios suele bastar con 2 núcleos, 4 GB de RAM y 25 GB de NVMe; para equipos de entre 10 y 50 personas, apunta a 4 núcleos, 8 GB de RAM y 50 GB de disco.

Requisitos y preparación antes de instalar

Antes de lanzarte necesitas un dominio con un registro DNS de tipo A apuntando a la IP del servidor, por ejemplo vault.tudominio.com. Los puertos 80 y 443 deben estar libres y accesibles, porque el Nginx de Bitwarden los utiliza directamente; el 80 hace falta para validar y renovar certificados de Let’s Encrypt. También necesitarás un servidor SMTP para enviar verificaciones e invitaciones, y una cuenta con permisos de administración o sudo. El instalador pedirá un identificador y una clave de instalación que se generan gratis en bitwarden.com/host. Sin SMTP no podrás verificar correos ni invitar a otras personas, y sin dominio y puertos abiertos el certificado TLS no funcionará.

En Linux, el servidor oficial pide como mínimo unos 2 GB de RAM y 12 GB de disco, aunque lo recomendable es 4 GB de RAM y 25 GB libres. En Windows Server los requisitos suben bastante: 6 GB de RAM y 76 GB de almacenamiento como mínimo, con 8 GB y 90 GB recomendados para producción. Además, Windows Server necesita virtualización anidada; en Azure hay que usar máquinas Standard D2s v3 con el tipo de seguridad estándar, no Trusted Launch. Windows consume bastante más máquina y exige comprobar antes que el hipervisor permite virtualización anidada.

Vaultwarden cambia por completo la escala: con 512 MB de RAM puede funcionar correctamente, lo que lo hace apto para una Raspberry Pi o un VPS muy modesto. Esa es una de sus grandes bazas frente al servidor oficial .NET, que levanta una decena de contenedores, incluido SQL Server. Si tu prioridad es eficiencia de recursos, Vaultwarden parte con ventaja.

Antes de empezar, decide también cómo vas a gestionar el certificado SSL. Puedes dejar que Let’s Encrypt lo genere durante la instalación, usar un certificado comprado o emitido por una autoridad, o tirar de autofirmado solo para pruebas. Para el correo, reúne el host SMTP, el puerto, el usuario, la contraseña y la dirección del remitente. Un certificado autofirmado sirve para probar, pero no para producción.

Instalación del Bitwarden oficial en Linux

El punto de partida habitual es Ubuntu 24.04 LTS, aunque los pasos se adaptan a Debian 12 y Rocky Linux 9 cambiando el gestor de paquetes. Actualiza el sistema y abre los puertos necesarios en el cortafuegos. Con UFW sería algo tan sencillo como permitir 80/tcp, 443/tcp y recargar las reglas. No olvides mantener SSH accesible para no quedarte fuera del servidor.

Bitwarden se ejecuta sobre Docker, así que instala Docker Engine 26.0 o superior y el plugin Docker Compose V2. Puedes hacerlo desde los repositorios oficiales de Docker o, en Ubuntu, con el paquete docker.io y docker-compose-plugin. Después habilita el servicio para que arranque solo tras cada reinicio y comprueba las versiones con docker –version y docker compose version. Docker Engine 26+ y Compose 2+ son la base mínima para que todo funcione sin sorpresas.

La recomendación es ejecutar Bitwarden con un usuario dedicado sin privilegios de administrador. Crea el usuario bitwarden, añádelo al grupo docker y prepara el directorio /opt/bitwarden con permisos 700 y propietario bitwarden. Ese 700 impide que otros usuarios del sistema lean o modifiquen la base de datos de contraseñas. Un usuario sin privilegios limita mucho el daño si la aplicación se viera comprometida.

Descarga el script bitwarden.sh desde la URL oficial y dale permisos de ejecución. Antes de lanzarlo puedes revisar su contenido, y después ejecuta ./bitwarden.sh install. El instalador preguntará el dominio sin https://, si quieres usar Let’s Encrypt y un correo para avisos, el nombre de la base de datos, el identificador y la clave de instalación, y la región US o EU. Anota bien esos dos valores de bitwarden.com/host, porque son necesarios para completar el despliegue.

Al terminar, toda la configuración y los datos quedan en /opt/bitwarden/bwdata. Arranca los servicios con ./bitwarden.sh start y comprueba con docker ps que los contenedores están en marcha. Es normal que tarden uno o dos minutos en pasar a healthy. Deberías ver entre cinco y siete contenedores, como bitwarden-web, bitwarden-api, bitwarden-identity, bitwarden-attachments, bitwarden-icons, bitwarden-mssql y bitwarden-nginx. Espera a que estén sanos antes de dar la instalación por buena.

Correo, panel de administración y registro público

Los ajustes del servidor se sobrescriben en bwdata/env/global.override.env. Abre ese archivo con el usuario bitwarden y rellena las variables globalSettings__mail__smtp__host, port, ssl, startTls, username, password y from. Si usas el puerto 587 con STARTTLS, deja ssl=false; si tu proveedor exige TLS implícito en el 465, pon ssl=true. En adminSettings__admins incluye los correos que podrán entrar al panel de administración, separados por comas. Después de tocar el archivo, reinicia con ./bitwarden.sh restart.

Abre tu dominio en el navegador, crea una cuenta y verifica el correo desde el enlace que recibirás. La contraseña maestra cifra la bóveda en tu dispositivo: el servidor no la conoce y no puede recuperarla si la olvidas. Elige una frase larga y guárdala en un lugar seguro. Si el correo de verificación llega, la configuración SMTP está bien encaminada. La contraseña maestra no se puede recuperar por diseño.

Cuando ya se haya registrado la gente necesaria, o si prefieres añadir usuarios solo mediante invitaciones de organización, desactiva el registro público. Añade globalSettings__disableUserRegistration=true en global.override.env y reinicia. Comprueba en una ventana privada que la opción de crear cuenta ya no permite registrarse. Dejar el registro abierto en internet es una invitación a que cualquiera use tu instancia.

El panel del sistema está en https://tu_dominio/admin. No usa contraseña al uso: introduces uno de los correos de adminSettings__admins y recibes un enlace de acceso de un solo uso. Desde ahí puedes ver y desactivar usuarios, forzar la eliminación de cuentas y consultar organizaciones. Las organizaciones, colecciones y permisos se gestionan desde la bóveda web, en Nueva organización. El acceso al panel es cómodo, pero conviene tratarlo con mucho cuidado.

Organizaciones, licencias y facturación

Para autoalojar una organización de pago, primero hay que crearla en la bóveda web en la nube de Bitwarden y recuperar la licencia desde la cuenta. Después se sube esa licencia al servidor propio para crear una copia autoalojada de la organización. Solo las organizaciones Familia y Empresa pueden importarse a servidores autoalojados. La facturación nace en la nube, aunque luego la bóveda viva en tu servidor.

Opcionalmente, puedes configurar la sincronización de facturación y licencias entre la organización en la nube y la autoalojada. Esto facilita actualizar la licencia cuando cambia el número de asientos, hacer renovaciones sin líos y desbloquear organizaciones familiares patrocinadas para miembros de organizaciones empresariales. La sincronización no es obligatoria, pero ahorra bastante trabajo administrativo.

Una vez creada la organización, invita primero a un equipo administrador con miembros de alto privilegio. Por redundancia, conviene incluir al menos a otro propietario. Establece cuanto antes políticas como exigir SSO o inscribir a los miembros en el restablecimiento de contraseña del administrador. Si vienes de otro gestor de secretos, importa esos datos directamente para evitar copiar y pegar. Después invita al resto del equipo; si usas un proveedor de identidad o un directorio como Azure Active Directory, puedes apoyarte en SCIM o Directory Connector para sincronizar usuarios automáticamente. Definir políticas y un segundo propietario desde el principio evita sustos.

Algunas funciones de pago, como determinadas organizaciones o características premium, requieren cargar un archivo de licencia generado desde tu cuenta de bitwarden.com. Los clientes oficiales se configuran igual que en la nube, pero antes de iniciar sesión hay que cambiar la región o servidor a Autoalojado e introducir la URL exacta, por ejemplo https://tu_dominio. Si la URL no coincide al milímetro, el cliente no conectará.

Instalación en Windows Server

En Windows Server 2025 el acceso se hace por RDP y necesitas Docker Desktop con Hyper-V, no con WSL2. El instalador oficial de Bitwarden para Windows es un script PowerShell llamado bitwarden.ps1. Ojo: Docker Desktop no tiene soporte oficial para Windows Server y puede dar problemas de estabilidad, así que Linux sigue siendo la opción más fiable. Además, Windows Server requiere virtualización anidada. Antes de instalar, comprueba que el hipervisor permite esa virtualización.

Abre PowerShell como administrador y crea reglas de cortafuegos para los puertos 80 y 443. Luego crea un usuario local Bitwarden, añádelo al grupo docker-users y prepara C:/Bitwarden. En Docker Desktop, entra en Ajustes, Recursos, Compartir archivos y añade C:/Bitwarden; aplica y reinicia. Asigna al menos 4 GB de RAM a Docker. Docker Desktop tiene que ver la carpeta C:/Bitwarden para poder arrancar los contenedores.

Descarga el script con Invoke-RestMethod y ejecuta bitwarden.ps1 -install. Las preguntas son equivalentes a las de Linux: dominio, Let’s Encrypt o certificado propio, correo, identificador, clave y región. Después edita C:/Bitwarden/bwdata/env/global.override.env con los datos SMTP y reinicia con bitwarden.ps1 -restart. Visita el dominio y crea la cuenta maestra. Los datos de instalación y el SMTP se configuran igual que en el despliegue Linux.

Docker Desktop solo arranca automáticamente al iniciar sesión si hay una sesión RDP abierta. Para evitarlo, crea una tarea programada que se ejecute al inicio, con un retraso de un minuto, usando la cuenta Bitwarden y la opción de ejecutar tanto si el usuario ha iniciado sesión como si no. Sin esa tarea, Docker Desktop puede quedarse apagado tras un reinicio. El script bitwarden.ps1 admite comandos como -start, -restart, -updateself, -update y -renewcert.

Algunos escenarios, como instalar detrás de un proxy con puertos alternativos, requieren tocar bwdata/config.yml y aplicar los cambios con un reinicio. En Linux ocurre lo mismo. Si cambias puertos o el proxy, revisa config.yml además de las variables de entorno.

Vaultwarden, la alternativa ligera

Vaultwarden es una reimplementación no oficial del servidor de Bitwarden escrita en Rust. Mantiene el mismo protocolo y funciona con las apps oficiales, la extensión de navegador y el CLI sin modificaciones. El proyecto lo mantiene dani-garcia, antes se llamaba bitwarden_rs y se renombró para evitar confusión con la marca. Su gran atractivo es que desbloquea funciones premium de forma gratuita al ser un servidor propio, pero no ofrece soporte comercial ni SLA. Es una opción excelente para uso personal o grupos pequeños, no tanto si necesitas garantías contractuales.

El despliegue típico con Docker Compose declara un servicio vaultwarden con la imagen vaultwarden/server:latest, container_name vaultwarden, restart always, la variable DOMAIN con tu URL HTTPS, SIGNUPS_ALLOWED a true, un volumen ./vw-data:/data y el puerto 11001:80. DOMAIN no es un adorno: sirve para generar bien las URLs de los adjuntos y para que el cliente entienda que habla HTTPS a través del proxy inverso. Si lo omites o lo dejas en http, algunas funciones fallan de forma poco intuitiva. Vaultwarden necesita HTTPS real de cara al cliente, porque las apps y los navegadores rechazan sincronizar contra un origen sin TLS válido.

Lo habitual es publicar el contenedor detrás de un proxy inverso con certificado, como Nginx, y usar Certbot y Let’s Encrypt si no tienes ya uno. Vaultwarden incluye un panel /admin para gestionar usuarios y organizaciones desde el navegador, protegido por ADMIN_TOKEN. En versiones recientes se recomienda generar un hash argon2id con docker run –rm -it vaultwarden/server:latest /vaultwarden hash. El comando devuelve una cadena PHC que empieza por $argon2id$ y esa cadena, no la contraseña original, es la que va en el compose. Como Docker Compose interpreta cada $ como variable de entorno, hay que duplicar cada $ de la cadena a $$. Nunca guardes el token en texto plano ni lo subas a un repositorio Git, aunque sea privado.

SIGNUPS_ALLOWED a true es necesario la primera vez para crear tu propia cuenta desde el cliente. En cuanto la tengas, cámbialo a false y reinicia con docker compose up -d. Dejar el registro abierto en un servidor expuesto a internet significa que cualquiera que encuentre la URL puede crearse una cuenta y usar tu instancia como su propio gestor. Cerrar el registro tras crear las cuentas es un paso de seguridad básico.

Todo el estado de Vaultwarden vive en el volumen /data: la base de datos SQLite, los adjuntos y los iconos cacheados. Un backup consistente puede ser tan simple como copiar ese directorio con el contenedor detenido, o usar sqlite3 para un volcado en caliente sin parar el servicio: docker exec vaultwarden sqlite3 /data/db.sqlite3 ‘.backup /data/db-backup.sqlite3’. Si ya tienes una estrategia de backups incrementales con rsync y hardlinks, el mismo enfoque funciona apuntando a vw-data. Como aquí guardas credenciales, para la copia fuera del servidor merece más la pena un remoto cifrado de rclone que un rsync sin cifrar hacia otro disco. Los backups de Vaultwarden son sencillos, pero deben salir del servidor.

Antes de actualizar el contenedor, revisa el changelog de Vaultwarden. Al seguir de cerca los cambios de protocolo de Bitwarden, alguna actualización mayor puede requerir migrar el formato de la base de datos. No actualices a ciegas si no has probado antes la nueva versión.

Copias de seguridad, actualizaciones y monitorización

El Bitwarden oficial hace una copia nocturna automática de la base de datos en bwdata/mssql/backups. A esas copias hay que sumar los archivos adjuntos en bwdata/core/attachments, la configuración de bwdata/env y bwdata/config.yml, y los certificados. Los archivos vivos de SQL Server en bwdata/mssql/data no se deben copiar con el servicio en marcha, así que se excluyen. Lo que debes guardar fuera del servidor es la base de datos, los adjuntos, la configuración y los certificados.

Puedes crear un script que comprima bwdata con tar, lo deje en una carpeta de backups y borre las copias de más de 30 días con find. Programarlo en cron para las 2 de la mañana es una forma sencilla de no olvidarlo. Después copia esos archivos a otro servidor o a un almacenamiento externo mediante SFTP, FTPS o una herramienta cifrada. Una copia que solo vive en el mismo servidor no te salva de un fallo de hardware. En Windows puedes hacer algo equivalente con Compress-Archive y una tarea programada, borrando los ZIP antiguos.

Las actualizaciones del servidor oficial se hacen con el mismo script, como usuario bitwarden. Primero actualiza el propio script con ./bitwarden.sh updateself y después los contenedores con ./bitwarden.sh update y ./bitwarden.sh start. En Windows serían bitwarden.ps1 -updateself, bitwarden.ps1 -update y bitwarden.ps1 -start. El orden importa: primero el script, luego las imágenes.

Monitoriza el estado de los contenedores, el espacio libre en disco, la caducidad del certificado y los registros de errores. Un disco lleno puede corromper la base de datos, y un certificado caducado deja a los clientes sin sincronizar. Revisa los logs semanalmente y prueba la restauración de una copia cada trimestre: detén Bitwarden, renombra bwdata, restaura la copia, arranca y verifica que todo funciona. Probar la restauración es tan importante como hacer la copia.

Seguridad y problemas habituales

Activa la autenticación en dos factores en la cuenta de administrador cuanto antes. Restringe SSH en Linux o RDP en Windows a direcciones IP conocidas y valora fail2ban para bloquear intentos de fuerza bruta. Comprueba la renovación de Let’s Encrypt con ./bitwarden.sh renewcert o bitwarden.ps1 -renewcert, deshabilita el registro público y autoriza solo los correos necesarios en el panel de administración. 2FA y una buena restricción de acceso remoto evitan muchos disgustos.

Si el instalador no obtiene el certificado, revisa que el DNS apunte al servidor y que el puerto 80 no esté ocupado por otro servicio; sudo ss -tlnp | grep ‘:80 ‘ ayuda a salir de dudas. Si Docker devuelve permission denied, el usuario bitwarden no está en el grupo docker o no ha vuelto a iniciar sesión; sal y entra de nuevo con sudo -iu bitwarden. Si no llegan los correos, revisa las variables SMTP y los logs con docker logs bitwarden-api. Si los clientes no conectan, confirma que has elegido servidor autoalojado y que la URL es exactamente https://tu_dominio. La mayoría de fallos se resuelven revisando DNS, puertos, permisos y logs.

Un consumo alto de memoria puede aliviarse reiniciando Bitwarden, pero si el problema persiste probablemente toque subir a un plan con 4 GB o más. Si una actualización rompe la instalación, restaura el directorio bwdata y vuelve a la versión anterior; antes de reintentar, consulta las notas de la versión para detectar cambios incompatibles. No improvises una actualización sin copia de seguridad.

• Certificado SSL: comprueba el candado en el navegador y fuerza la renovación si ha caducado.
• Contenedores: revisa docker ps y los logs si alguno aparece como Exited.
• Correo: prueba el SMTP por separado y revisa los rechazos en los logs de identidad.
• Disco y memoria: vigila el espacio y usa docker stats para detectar contenedores que se desbocan.
• Clientes: revisa la URL de servidor autoalojado antes de iniciar sesión.
• Restauración: ensaya una recuperación completa de bwdata al menos una vez por trimestre.

Preguntas frecuentes y dudas habituales

Sí, se puede alojar Bitwarden en macOS, pero requiere un Mac dedicado, acceso remoto y es menos eficiente que Linux o Windows. La comunidad ofrece menos recursos y la configuración es más compleja, así que no es la opción más recomendable para producción.

Las funciones principales de Bitwarden son gratuitas e incluyen almacenamiento ilimitado y sincronización entre dispositivos. El plan premium personal cuesta unos 19,80 dólares al año y añade opciones avanzadas de 2FA; el plan familiar ronda los 47,88 dólares anuales, y los equipos necesitan licencia empresarial. Para empezar, la versión gratuita suele ser más que suficiente.

Como alternativas están Vaultwarden, más ligero; 1Password, con interfaz en la nube; KeePassXC, sin conexión; y Passbolt, orientado a equipos. Si el autoalojamiento te parece demasiado, Bitwarden Cloud ofrece una seguridad parecida sin mantenimiento. La elección depende de cuánto quieras controlar y cuánto quieras administrar.

Bitwarden es muy seguro si se configura bien. Usa cifrado AES-CBC de 256 bits y admite derivación de claves con PBKDF2 SHA-256 o Argon2id. La contraseña maestra nunca sale del dispositivo sin cifrar. Alojarlo tú mismo elimina al proveedor cloud de tu modelo de amenazas. El cifrado de extremo a extremo es la base de su diseño.

Puedes migrar desde Bitwarden Cloud exportando la bóveda desde Ajustes, Exportar bóveda, e importándola en tu instancia desde Ajustes, Importar datos. Se conservan contraseñas, notas y la estructura de la organización. Exportar e importar es rápido y evita copiar a mano.

Para añadir usuarios, crea una organización desde la bóveda web y envíales una invitación por correo. Necesitarán recibir el correo, así que el SMTP debe estar bien configurado, y deberán aceptar la invitación para unirse. Las invitaciones sin correo configurado no llegan a ninguna parte.

Si olvidas la contraseña maestra, no hay recuperación posible. La bóveda permanece cifrada e inaccesible por diseño. Guárdala en un lugar físico seguro, sin conexión, y no confíes solo en un archivo digital. La contraseña maestra es la llave que no se puede duplicar desde el servidor.

Para la mayoría de despliegues, Docker es suficiente y más fácil de gestionar. Kubernetes solo tiene sentido en empresas grandes que necesiten alta disponibilidad, balanceo de carga y conmutación automática entre nodos. No montes Kubernetes si con Docker ya cubres la necesidad.

Linux consume aproximadamente un tercio de la RAM que requiere Windows Server, se actualiza con gestores de paquetes y tiene más comunidad de autoalojamiento. Windows resulta familiar a administradores de AD y ofrece herramientas de gestión y soporte comercial de Microsoft. Linux es la apuesta eficiente; Windows, la familiar.

Queda claro que montar tu propia bóveda de Bitwarden o Vaultwarden exige preparar bien el terreno: dominio, TLS, SMTP, Docker, copias externas y una política de acceso sensata. La recompensa es una bóveda cifrada bajo tu control, con clientes oficiales y la tranquilidad de saber dónde están los datos. HTTPS, SMTP, backups fuera del servidor y 2FA son los cuatro pilares que no deberías descuidar, y probar una restauración cada trimestre te evitará más de un sofoco.