Cómo alojar Beszel por cuenta propia en 2026: agentes, redes privadas y backups

La demo más sencilla de Beszel demuestra que un proceso escucha en el puerto 8090. En producción hace falta una evidencia más sólida. Debe superar este escenario incluso después de reemplazar el container: registrar un agente, observar los gráficos de CPU, memoria y disco, activar una alerta por umbral y volver a conectar el agente después de reiniciar el hub.

Beszel se implementa con un propósito claro: monitorizar servidores ligeros en un container pequeño. El problema de despliegue más habitual es que el hub no puede acceder al puerto 45876 de un agente o que su clave SSH ha cambiado, por lo que la gestión de la URL pública y el estado persistente deben recibir la misma atención que el arranque de la image.

Delimita el runtime de Beszel

La salud del proceso y la salud del producto son cosas distintas en Beszel. El puerto 8090 puede responder mientras la transacción que usa el usuario sigue fallando. El contrato de red de Beszel requiere un agente de Beszel en cada máquina monitorizada. Mantén los endpoints privados en el DNS interno, permite solo las llamadas salientes necesarias y asigna a Beszel una credencial de servicio con permisos limitados.

Usa este ejercicio de readiness después de cambios de configuración importantes: registra un agente, observa los gráficos de CPU, memoria y disco, activa una alerta por umbral y vuelve a conectar el agente después de reiniciar el hub. Evita incluir comprobaciones externas costosas en las sondas de liveness para que una caída de un proveedor no provoque un bucle de reinicios. El trabajo de capacity planning debe seguir el número de agentes, la retención de métricas, el almacenamiento del hub y la conectividad de red con cada agente en su puerto dedicado, aspectos más cercanos a la presión real de Beszel que las solicitudes a páginas.

Haz que el origen público sea inequívoco

El navegador, el cliente de API y Beszel deben coincidir en un único origin. Para conseguirlo, sirve el hub mediante HTTPS y mantén privados los puertos de los agentes. Conserva el host y el protocolo originales, y evita que el puerto 8090 quede disponible como una dirección pública alternativa.

La guía para solucionar problemas cuando el sitio está caído ayuda a distinguir entre una ruta inaccesible y una aplicación que responde. Esa diferencia importa aquí: el hub no puede acceder al puerto 45876 de un agente o su clave SSH ha cambiado. Solo el primer problema se soluciona modificando el ingress; el segundo requiere inspeccionar los logs, el estado o el workload de Beszel.

Ejecuta la primera instancia con forma de producción

El primer container debe poder eliminarse y recrearse fácilmente. Mantén los datos fuera de la writable layer, publica el puerto 8090 solo donde el proxy pueda acceder a él y pasa la configuración en runtime.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

Fija la image después de la prueba inicial. Lee el primer error de arranque en lugar del mensaje final de reinicio, verifica cada mount con docker inspect y sigue los logs mientras registras un agente, observas los gráficos de CPU, memoria y disco, activas una alerta por umbral y vuelves a conectar el agente después de reiniciar el hub. Esta secuencia permite distinguir un comando incorrecto de la image de un problema de dependencias o permisos.

Logs que responden a la siguiente pregunta

Un container en estado green es necesario, pero no suficiente. El indicador de nivel de servicio es completar correctamente «registrar un agente, observar los gráficos de CPU, memoria y disco, activar una alerta por umbral y volver a conectar el agente después de reiniciar el hub», mientras que las señales de presión más probables son el número de agentes, la retención de métricas, el almacenamiento del hub y la conectividad de red con cada agente en su puerto dedicado.

El change control es importante porque las versiones del hub y de los agentes deben probarse juntas: los cambios de protocolo pueden parecer interrupciones silenciosas de la monitorización. Conserva la image anterior, prueba las migraciones con una copia del estado y documenta si el rollback es compatible después de mover el schema. Si el hub no puede acceder al puerto 45876 de un agente o su clave SSH ha cambiado, diagnostica primero el boundary que difiere del entorno operativo.

Un acceptance run de Beszel para producción

Antes de que lleguen usuarios reales, prepara una release worksheet para Beszel. Debe indicar la image fijada, el puerto 8090, el origin canónico, las rutas persistentes y la persona responsable de un agente de Beszel en cada máquina monitorizada. Adjunta el resultado esperado de esta transacción: registrar un agente, observar los gráficos de CPU, memoria y disco, activar una alerta por umbral y volver a conectar el agente después de reiniciar el hub.

Usa la worksheet después de un reemplazo normal y de una restauración limpia. La recuperación solo se acepta si vuelven los sistemas, el historial y las alertas, y cada agente restaurado reanuda el envío de métricas actuales. Recopila también un breve resource trace que cubra el número de agentes, la retención de métricas, el almacenamiento del hub y la conectividad de red con cada agente en su puerto dedicado; guárdalo junto a la release para comparar los futuros cambios de capacidad con el mismo workload.

Incluye un fallo controlado: deniega temporalmente al identity de prueba el acceso a un agente de Beszel en cada máquina monitorizada. Confirma que Beszel informa del problema en el boundary correcto, restablece la condición válida y vuelve a ejecutar la transacción. Así se comprueba la visibilidad de los errores, no solo el éxito, y se evita que una interfaz con aspecto saludable oculte un worker, callback o conexión a base de datos averiados.

Diseña la restauración de Beszel antes del lanzamiento

Haz inventario de todos los artefactos duraderos: los datos del hub, los usuarios, los sistemas y la configuración de alertas. Monta /beszel_data antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el container para demostrar que esa ruta es realmente persistente. Incluye también la configuración que cambia la forma en que se interpretan los datos almacenados, no solo el directorio más grande.

Configura la retención, copia los backups fuera del host y ejecuta una restauración en un entorno limpio. El drill de Beszel termina cuando vuelven los sistemas, el historial y las alertas, y cada agente restaurado reanuda el envío de métricas actuales. Si los snapshots forman parte del plan, usa la guía sobre PITR frente a snapshots para documentar qué puede recuperar cada mecanismo.

Cierra el acceso temporal de configuración

Analiza las amenazas de la acción que realiza Beszel, no solo de su formulario de login. En este caso, el error de mayor riesgo es publicar los listeners de los agentes en internet sin controles de red. Implementa este boundary: mantén los listeners de los agentes en redes privadas y protege la cuenta del hub y las claves de enrollment.

Beszel no tiene un bootstrap secret obligatorio en esta configuración base; protege su cuenta de administrador real o la autenticación del upstream. No resuelvas un error de permisos ejecutando el container como root ni montando el host de forma amplia. Los límites de recursos también forman parte del diseño de seguridad cuando los usuarios pueden provocar cambios en el número de agentes, la retención de métricas, el almacenamiento del hub y la conectividad de red con cada agente en su puerto dedicado.

Traslada el trabajo de infraestructura repetible a Dockup

En el caso de Beszel, Dockup resulta más útil en el boundary entre una image y un servicio duradero. Mantiene asociadas la ruta al puerto 8090, TLS, los valores secretos y el almacenamiento durante los reemplazos del container, tanto si el cómputo pertenece a Dockup como si pertenece a tu servidor conectado.

Termina con el conocimiento de la aplicación: sirve el hub mediante HTTPS y mantén privados los puertos de los agentes; conecta y prueba un agente de Beszel en cada máquina monitorizada; y ejecuta esta verificación: registra un agente, observa los gráficos de CPU, memoria y disco, activa una alerta por umbral y vuelve a conectar el agente después de reiniciar el hub. Conserva el resultado como deployment check para que la siguiente actualización de la image se evalúe por su comportamiento y no por el estado del container.

Preguntas frecuentes

¿Qué necesita Beszel para un despliegue en producción?

Sirve el container de Beszel en el puerto 8090 mediante un único origin HTTPS. El requisito de red asociado es disponer de un agente de Beszel en cada máquina monitorizada. No des por preparado Beszel hasta que puedas registrar un agente, observar los gráficos de CPU, memoria y disco, activar una alerta por umbral y volver a conectar el agente después de reiniciar el hub.

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

Haz persistir /beszel_data e incluye los datos del hub, los usuarios, los sistemas y la configuración de alertas en el mismo recovery manifest. Una restauración limpia de Beszel solo supera la prueba cuando vuelven los sistemas, el historial y las alertas, y cada agente restaurado reanuda el envío de métricas actuales.

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

Usa HTTPS para el origin público de Beszel y mantén el puerto 8090 en la ruta interna. Aplica correctamente la configuración de Beszel: sirve el hub mediante HTTPS y mantén privados los puertos de los agentes. En Beszel, HTTPS protege las credenciales o el contenido de los usuarios durante el transporte y mantiene coherente el comportamiento del cliente sensible al origin.

¿Cómo debe probarse una actualización de Beszel?

Restaura el estado actual de Beszel en un deployment aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las versiones del hub y de los agentes deben probarse juntas: los cambios de protocolo pueden parecer interrupciones silenciosas de la monitorización. Conserva la image anterior de Beszel hasta entender los límites de migración de datos y rollback.