Cómo autoalojar CloudBeaver en 2026: drivers de bases de datos, workspace y acceso
Autoalojar CloudBeaver con los puertos correctos, almacenamiento persistente, HTTPS, secretos, backups y comprobaciones de actualización. Aprende a solucionar los fallos de permisos del workspace.
La demo más breve de CloudBeaver demuestra que un proceso escucha en el puerto 8978. En producción se necesitan pruebas más sólidas. Debe superar este escenario incluso después de reemplazar el contenedor: completar la configuración del administrador, instalar el driver necesario, conectarse mediante un hostname privado y ejecutar una query de solo lectura.
CloudBeaver se está desplegando con un objetivo claro: ofrecer un cliente de bases de datos en el navegador para Postgres, MySQL y otros sistemas. El problema más habitual en su despliegue es que fallen los permisos del workspace o que el DNS del contenedor no pueda resolver los hosts de las bases de datos, por lo que el acceso mediante una URL pública y el estado persistente requieren la misma atención que el arranque de la imagen.
Restaurar CloudBeaver en un host vacío
Enumera el estado antes de crear el primer registro real: workspace, usuarios, definiciones de conexión y almacenamiento de credenciales. Monta /opt/cloudbeaver/workspace antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Confirma el montaje escribiendo datos inocuos, reemplazando CloudBeaver y volviendo a leerlos.
Los snapshots son útiles para hacer rollback rápidamente, pero necesitas un backup independiente si el host o el volumen desaparecen. Restaura en un entorno vacío con la imagen fijada y verifica que el workspace, los usuarios, los drivers y las conexiones regresan, mientras cada base de datos subyacente sigue su propio plan de backup. Usa volúmenes persistentes y snapshots para mantener diferenciados estos dos mecanismos de recuperación.
Lanzar CloudBeaver con valores predeterminados observables
El siguiente comando hace visible el límite del contenedor sin pretender aprovisionar todos los servicios externos.
docker run -d \
--name cloudbeaver \
--restart unless-stopped \
-p 127.0.0.1:8978:8978 \
-v cloudbeaver-data:/opt/cloudbeaver/workspace \
-e CB_SERVER_NAME=CloudBeaver \
dbeaver/cloudbeaver:latest
Antes de abrir el ingress, inspecciona el entorno resuelto, los montajes y el listener. Añade la configuración de conexión revisada para las rutas privadas y los drivers de bases de datos para cada base de datos de destino; usa nombres privados para los servicios privados. Un lanzamiento correcto termina cuando puedes completar la configuración del administrador, instalar el driver necesario, conectarte mediante un hostname privado y ejecutar una query de solo lectura, no cuando docker ps muestra Up.
De qué depende CloudBeaver
El proceso HTTP de CloudBeaver escucha en el puerto 8978; mantén ese puerto en la red de la aplicación y publica únicamente la ruta de la plataforma. El contrato de red de CloudBeaver consiste en rutas privadas y drivers de bases de datos para cada base de datos de destino. Mantén los endpoints privados en el DNS interno, permite únicamente las llamadas salientes necesarias y proporciona a CloudBeaver una credencial de servicio con permisos limitados.
Deja escrito el límite como un contrato breve: quién es responsable del requisito, qué credencial se utiliza, qué timeout es aceptable y cómo se manifiesta el fallo. Después ejecuta esta transacción: completa la configuración del administrador, instala el driver necesario, conéctate mediante un hostname privado y ejecuta una query de solo lectura. Durante la ejecución, observa el estado del workspace, las descargas de drivers, las sesiones simultáneas y la latencia de red hacia cada base de datos, porque esa carga proporciona un punto de partida más útil para dimensionar que un contenedor inactivo.
Mantener separadas las URL internas y externas
El límite público de CloudBeaver debería ser un único hostname canónico, TLS automático y un único destino interno en 8978. Configura la URL del servidor y los headers del proxy para el origen HTTPS público, de modo que los clientes regresen a una dirección que el servicio reconozca.
Si la transacción de aceptación falla, clasifica el primer error. Los problemas de DNS, certificados y 502 corresponden a la lista de comprobación de validación de TLS. La condición «fallan los permisos del workspace o el DNS del contenedor no puede resolver los hosts de las bases de datos» corresponde a la capa de aplicación, después de que una petición haya llegado correctamente a CloudBeaver.
Una ejecución de aceptación de producción para CloudBeaver
No utilices el tráfico del primer usuario como prueba de aceptación de CloudBeaver. Prepara un estado de ejemplo inocuo y ejecuta la acción completa «completar la configuración del administrador, instalar el driver necesario, conectarse mediante un hostname privado y ejecutar una query de solo lectura». Anota la URL pública exacta, el resultado, la referencia de la imagen y el intervalo de logs asociados a la ejecución.
Reemplaza el contenedor y repite la prueba sin reconstruir los datos. Después, recupera el servicio en un host vacío; la condición de recuperación es que el workspace, los usuarios, los drivers y las conexiones regresen, mientras cada base de datos subyacente sigue su propio plan de backup. Observa el estado del workspace, las descargas de drivers, las sesiones simultáneas y la latencia de red hacia cada base de datos en cada pasada, y define una alerta en torno a la degradación de la transacción, no en torno a las métricas de un contenedor inactivo.
Una última comprobación debe fallar intencionadamente: deniega temporalmente a la identidad de prueba el acceso a las rutas privadas y a los drivers de bases de datos para cada base de datos de destino. Verifica que el mensaje resultante de CloudBeaver identifica el límite relevante en lugar de activar un borrado de datos o un reinicio interminable. Restablece la condición válida y confirma que la misma transacción de ejemplo se completa correctamente. Incluye esta breve prueba en la checklist de release.
Diagnosticar un CloudBeaver que parece estar sano
La primera métrica operativa útil para CloudBeaver es si puede completar la configuración del administrador, instalar el driver necesario, conectarse mediante un hostname privado y ejecutar una query de solo lectura. Combínala con señales de saturación del estado del workspace, las descargas de drivers, las sesiones simultáneas y la latencia de red hacia cada base de datos. Una probe que solo compruebe el proceso no debe llamar a dependencias costosas ni reiniciar el contenedor porque un upstream no esté disponible temporalmente.
Trata las actualizaciones como cambios de datos, porque las migraciones del workspace de CloudBeaver y la compatibilidad de los drivers deben probarse antes de cambiar las versiones de la imagen. Fija las versiones, ensaya el procedimiento con el estado restaurado y conserva la imagen anterior hasta que el rollback siga siendo válido. Cuando fallen los permisos del workspace o el DNS del contenedor no pueda resolver los hosts de las bases de datos, conserva los logs anteriores al reinicio; normalmente contienen el mensaje causal.
Decisiones de seguridad específicas de CloudBeaver
No heredes las suposiciones de seguridad de un tutorial local. El riesgo específico de CloudBeaver consiste en permitir el acceso anónimo a conexiones de bases de datos de producción. Por tanto, en producción debes desactivar la administración anónima, utilizar usuarios individuales y conceder a las cuentas de base de datos únicamente los permisos que necesite cada conexión.
CB_SERVER_NAME controla el comportamiento, no la confidencialidad; valida su tipo y su valor, y almacena las credenciales reales de CloudBeaver por separado. Limita el acceso al sistema de archivos y a la red, protege los endpoints de configuración y define límites de upload, request o ejecución en torno al estado del workspace, las descargas de drivers, las sesiones simultáneas y la latencia de red hacia cada base de datos.
Un despliegue en Dockup también necesita una prueba de aceptación de CloudBeaver
El despliegue de CloudBeaver con un clic de Dockup debería hacer que el reemplazo sea seguro: la ruta debe seguir apuntando a 8978, los secretos no deben estar integrados en la imagen y las rutas persistentes deben recuperarse en el contenedor nuevo. El mismo despliegue puede ejecutarse en la infraestructura de Dockup o en una máquina conectada.
Completa el trabajo específico de la aplicación conectándote y probando las rutas privadas y los drivers de bases de datos para cada base de datos de destino, aplicando la dirección pública canónica y ejecutando esta comprobación de aceptación: completa la configuración del administrador, instala el driver necesario, conéctate mediante un hostname privado y ejecuta una query de solo lectura. Añade el resultado de la restauración al runbook antes de que lleguen los usuarios reales.
Preguntas frecuentes
¿Qué necesita CloudBeaver para un despliegue de producción?
Dirige el contenedor de CloudBeaver en el puerto 8978 a través de un único origen HTTPS. El requisito de red de soporte consiste en rutas privadas y drivers de bases de datos para cada base de datos de destino. No consideres que CloudBeaver está listo hasta que puedas completar la configuración del administrador, instalar el driver necesario, conectarte mediante un hostname privado y ejecutar una query de solo lectura.
¿Qué datos de CloudBeaver deben incluirse en un backup?
Haz persistente /opt/cloudbeaver/workspace e incluye el workspace, los usuarios, las definiciones de conexión y el almacenamiento de credenciales en el mismo manifiesto de recuperación. Una restauración limpia de CloudBeaver solo es correcta cuando el workspace, los usuarios, los drivers y las conexiones regresan, mientras cada base de datos subyacente sigue su propio plan de backup.
¿CloudBeaver necesita HTTPS detrás de un reverse proxy?
Usa HTTPS para el origen público de CloudBeaver y mantén el puerto 8978 en la ruta interna. Aplica correctamente la configuración de CloudBeaver: establece la URL del servidor y los headers del proxy para el origen HTTPS público. En CloudBeaver, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.
¿Cómo se debe probar una actualización de CloudBeaver?
Restaura el estado actual de CloudBeaver en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque las migraciones del workspace de CloudBeaver y la compatibilidad de los drivers deben probarse antes de cambiar las versiones de la imagen. Conserva la imagen anterior de CloudBeaver hasta comprender los límites de la migración de datos y del rollback.