2026.10.18
Beszel: Centralized Server Monitoring with a Hub and Agents
Beszel collects metrics from host-based agents into a hub, with historical data, container statistics, and alerts. It suits people who need a central view of self-hosted systems, subject to environment-specific metric availability.
What it does
Beszel is a server monitoring platform whose project description highlights historical data, Docker statistics, and alerts. Its architecture has two parts: a hub and an agent. The hub is a web application for viewing and managing connected systems. An agent runs on every system to be monitored and communicates system metrics to the hub. In practical terms, its basic model is to bring data from multiple hosts into one management interface rather than to view only one machine.
Metrics and functions listed by the project
The README lists host CPU, memory, disk usage, disk I/O, network usage, and load average. It also lists temperature, fan speed, GPU usage and power draw, and battery charge. For containers, Beszel covers the status and metrics of running Docker or Podman containers. Its Docker statistics include CPU, memory, and network usage history for each container.
Storage-related items include S.M.A.R.T. disk-health data. The README also lists ZFS pool capacity, usage, health, I/O throughput, scrub status, and per-dataset usage. Network monitoring can check response time and interruptions directly from agents. Alerts are configurable for most metrics and support multiple notification services.
Who it may suit
The repository is tagged with homelab, monitoring, and self-hosted topics. That makes it relevant to people seeking a consolidated view of a homelab, personal servers, or a small self-hosted environment. Operators using Docker or Podman, relying on ZFS, or wanting to inspect host status through historical trends and alerts can compare their needs with the feature set documented by the project.
The README also describes multi-user behavior: users manage their own systems, and administrators can share systems across users. OAuth/OIDC, API access, and automatic backups are listed as well. Backups can be saved to and restored from local disk or S3-compatible storage. These functions are relevant to deployments that need shared visibility or backups, although the supplied sources do not define a detailed authorization model or organizational scale.
Limits and deployment points to check
The hub-and-agent design means that every monitored system needs an agent and a path for that agent to send metrics to the hub. While the README lists a broad range of metric categories, it does not state a universal minimum hardware requirement or provide a complete compatibility matrix. Fan-speed data is specifically described as coming from Linux through /sys/class/hwmon. Whether GPU, sensor, S.M.A.R.T., ZFS, and container metrics are available should therefore be checked against the data exposed by each target host.
The v0.21.0 release notes also list Wi-Fi signal-strength monitoring, TLS certificate-expiry checks for HTTPS network monitors, network-monitor comparisons, and systemd service logs. A prospective deployment should confirm whether those listed capabilities are needed in its environment. Beszel uses the MIT License and repository metadata marks it as unarchived. The supplied material does not provide performance benchmarks, a security-audit conclusion, or a universal resource-sizing recommendation, so none of those should be inferred from the available sources.
Sources
Sources checked: 2026-10-18