Por qué Beszel logra el equilibrio justo para el autoalojamiento
Grafana + Prometheus es el estándar del sector, pero conlleva una puesta en marcha pesada: exporters, configuración de Prometheus, fuentes de datos de Grafana, paneles. Uptime Kuma destaca en los controles de disponibilidad, pero no aporta métricas de recursos. Netdata es rico en datos, pero consume más RAM por nodo y exige una cuenta en la nube para agregar varios hosts. Beszel se sitúa entre ambos: métricas de recursos completas (CPU, RAM, disco, ancho de banda, temperaturas), estadísticas Docker por contenedor, gráficos históricos y alertas por umbral — todo ello desplegado con un único comando Docker, sin ningún archivo de configuración.
El hub se apoya en PocketBase, lo que significa un único binario Go con una base de datos integrada. Sin Postgres ni Redis aparte. Sin ningún YAML que escribir. La contrapartida: Beszel no permite consultas personalizadas ni paneles libres como Prometheus/Grafana — para supervisar los recursos de un parque de servidores, es más rápido de asimilar y más sencillo de mantener.
Uptime Kuma · Beszel · Netdata — tabla comparativa
Desplace la tabla
| Criterio | Uptime Kuma | Beszel | Netdata |
|---|---|---|---|
| Métricas de recursos | No (solo sonda HTTP/TCP) | Sí (CPU, RAM, disco, ancho de banda, temp.) | Sí (muy detallado) |
| Multiservidor sin cuenta en la nube | Sí (una instancia por servidor) | Sí (hub único, agentes sin límite) | Parcial (hace falta una room en la nube para agregar) |
| Consumo de RAM del hub | < 100 MB | < 50 MB | 300–500 MB por nodo |
| Estadísticas Docker por contenedor | No | Sí (automático) | Sí |
| Configuración requerida | Interfaz web | Cero archivos | Cero archivos |
| Exportación Prometheus | No (nativa) | No nativa (vía `/metrics` experimental) | Sí (nativa) |
Lo que obtiene de entrada
- Métricas de CPU, RAM, disco, ancho de banda y temperatura actualizadas cada 15 segundos.
- Estadísticas Docker por contenedor — CPU, RAM y red de cada contenedor, detectados automáticamente.
- Gráficos históricos con resolución horaria, diaria y mensual, sin límite de retención.
- Alertas por umbral enviadas a Telegram, Slack, correo electrónico, Discord, ntfy, PagerDuty y muchos más.
- Multiservidor: un solo hub, un parque de agentes sin límite — sin cargos por servidor ni funciones de pago.
- Los agentes se conectan al hub en salida — no se necesita ninguna regla de cortafuegos entrante en los servidores supervisados.
- Licencia MIT — totalmente de código abierto, autoalojado y sin dependencia de la nube.
Requisitos
El hub es excepcionalmente ligero. Se conforma con menos de 512 MB de RAM y un solo núcleo, holgadamente dentro del VPS Start (2 vCPU, 4 GB) — de hecho, encuentra su sitio junto a otros servicios en su servidor más pequeño. Reserve de 5 a 10 GB de disco para el directorio de datos de PocketBase, que crece despacio a medida que se acumulan las métricas históricas. Los agentes son aún más ligeros: unos pocos MB de RAM cada uno. Puede supervisar más de 20 servidores sin que el hub se inmute en ese mismo VPS Start.
Dependencias: Docker instalado en el hub (para el contenedor del hub) y en cada servidor supervisado (para el agente en modo contenedor). Existe una alternativa binaria sin Docker para los agentes — consulte la documentación oficial para esa variante.
Desplegar el hub y añadir varios agentes
Iniciar el hub
En el VPS dedicado a la monitorización:
docker run -d --restart=always \ -p 8090:8090 \ --name beszel \ -v /opt/beszel:/beszel_data \ henrygd/beszel:latestEl hub arranca de inmediato — no requiere ninguna variable de entorno ni archivo de configuración.
Crear la cuenta de administrador
Abra
http://<hub-ip>:8090. El primer visitante ve el asistente de PocketBase que crea la cuenta de administrador (correo electrónico + contraseña fuerte). Esta cuenta controla la totalidad del panel — elija una contraseña sólida; activará el 2FA en el paso siguiente.Activar el 2FA en la cuenta de administrador
En PocketBase, vaya a Settings → Admins, abra su perfil y active la autenticación de dos factores (TOTP). Escanee el código QR con un gestor de códigos (Aegis, Authy, 1Password). A partir de ahí, cualquier inicio de sesión exige el código temporal además de la contraseña.
Poner el hub detrás de un reverse proxy HTTPS
Apunte un subdominio (por ejemplo
monitor.votre-domaine.com) al VPS del hub. Con Caddy:apt install -y caddyContenido de
/etc/caddy/Caddyfile:monitor.votre-domaine.com { reverse_proxy localhost:8090 }Caddy aprovisiona el certificado TLS automáticamente. Cierre después el puerto 8090 en su cortafuegos — todo el acceso pasa por 443:
ufw delete allow 8090 ufw allow 443Añadir cada servidor supervisado
En Beszel, haga clic en Add system, introduzca un nombre y la IP o el nombre de host del servidor (puerto 45876). El hub genera una clave pública propia de ese sistema — cópiela.
Instalar el agente en cada servidor supervisado
En cada servidor que vaya a supervisar:
docker run -d --restart=always \ --network host \ --name beszel-agent \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -e KEY="<clé-copiée-depuis-le-hub>" \ henrygd/beszel-agent:latestEl agente establece una conexión saliente hacia el hub en el puerto 45876 — no hay ningún puerto entrante que abrir en el servidor supervisado. Las métricas aparecen en el panel en unos segundos.
Configurar las alertas de Telegram y de correo
En los ajustes de Beszel, abra la pestaña Notifications y haga clic en Add notification.
Telegram (canal recomendado por su rapidez): cree un bot con @BotFather para obtener un token y después recupere su chat_id enviando un mensaje al bot y llamando a https://api.telegram.org/bot<token>/getUpdates. Pegue el token y el chat ID en el formulario. Un mensaje de prueba confirma la conexión.
Correo electrónico (SMTP): indique el host SMTP, el puerto (587 para STARTTLS), el nombre de usuario, la contraseña y la dirección de destino. En cada sistema supervisado, defina después umbrales de alerta: por ejemplo, alerta en cuanto el uso del disco supere el 80 %, o cuando la RAM se mantenga por encima del 90 % durante 5 minutos. Varios canales pueden convivir — Telegram para las alertas urgentes, correo para los resúmenes.
Solución de problemas — agente silencioso, TLS rechazado, puerto bloqueado
El agente no aparece en el panel. Compruebe primero que el agente está realmente en marcha: docker logs beszel-agent. Un mensaje connection refused indica que el puerto 45876 está bloqueado en el hub — ábralo en ufw únicamente del lado del hub (los agentes, por su parte, no necesitan abrir ningún puerto entrante):
ufw allow 45876/tcpSi los registros muestran un error TLS como certificate signed by unknown authority, es que el hub está expuesto con un certificado autofirmado o con un certificado de una CA no reconocida. Dos soluciones: usar un certificado Let's Encrypt válido (la vía recomendada, con Caddy), o pasar la variable AGENT_SKIP_TLS_VERIFY=true al agente (a evitar en producción).
El hub está detrás de un reverse proxy pero los agentes no se conectan. El puerto 45876 es un puerto TCP directo (no HTTP): el reverse proxy Caddy o nginx no lo proxifica de la misma manera que una petición web. La solución es exponer el puerto 45876 directamente en el hub (no a través del proxy) y dejar únicamente la interfaz web (8090) detrás del proxy HTTPS. Autorice el puerto 45876 en su cortafuegos y asegúrese de que el grupo de seguridad de su VPS lo permita en TCP entrante desde las IP de sus agentes.
Métricas de Docker ausentes. El agente debe tener acceso al socket de Docker. Compruebe que /var/run/docker.sock está montado en solo lectura en el comando de arranque del agente.
Proteger el hub
Un hub de monitorización agrega datos sensibles (carga, disco, topología de red interna). Algunas medidas esenciales:
Acceso restringido al panel. Después de activar el 2FA, añada una capa de restricción por IP o una autenticación HTTP básica en el reverse proxy si el hub solo debe ser accesible para un equipo reducido. Con Caddy:
monitor.votre-domaine.com {
basicauth {
<utilisateur> <hash-bcrypt>
}
reverse_proxy localhost:8090
}Puerto 45876 no expuesto públicamente. Si todos sus agentes están en VPS del mismo proveedor y comparten una red privada, configure el hub para que escuche solo en la IP privada y bloquee el 45876 en la IP pública. Si no, restrinja ese puerto a las IP conocidas de sus agentes en ufw.
Copias de seguridad del directorio de datos. La carpeta /opt/beszel contiene la base de datos PocketBase y el histórico de métricas. Inclúyala en su rutina de copias de seguridad — una restauración tras un siniestro es inmediata si la copia está al día.
Exportación a Prometheus — para ir más lejos
Si ya tiene una stack Prometheus/Grafana y desea centralizar todas sus métricas, Beszel expone un endpoint experimental /metrics en formato Prometheus en el hub. Actívelo en los ajustes avanzados y añada un scrape job en su prometheus.yml:
scrape_configs:
- job_name: beszel
static_configs:
- targets: ['monitor.votre-domaine.com']
scheme: https
metrics_path: /metrics
basic_auth:
username: '<utilisateur>'
password: '<mot-de-passe>'No es la vía principal de Beszel — si Prometheus/Grafana ya está en marcha, quizá no necesite Beszel en absoluto. Pero para un equipo que quiere ambos paneles, es una pasarela útil.
Ejecute el hub de Beszel en un VPS distinto del de su stack principal. Cuando su servidor de producción esté fuera de servicio, querrá que el sistema de monitorización siga en pie y continúe enviando alertas — no que se caiga al mismo tiempo. La huella minúscula del hub en recursos permite justificar un VPS Start dedicado a la monitorización sin la impresión de estar malgastando dinero.
La documentación oficial
Para la configuración avanzada y las opciones propias de la herramienta, consulte la documentación oficial de Beszel. Esta guía cubre la puesta en línea en un VPS y los casos habituales; la documentación del editor sigue siendo la referencia para las actualizaciones mayores y los ajustes finos.
