Beszel vs Netdata vs Glances: Homelab Monitoring

For a homelab with more than one machine I would run Beszel (v0.20.0, September 19). It is one hub and an agent per host, with one dashboard of all of them and alerts, and it costs nothing. Netdata (v2.11.1, September 16) is the one I would put on the box I am debugging, because it collects most metrics every second, keeps them for up to 14 days and runs anomaly detection on the agent, at a cost its resource-utilization page puts at 100-200 MB of RAM on an empty system; its Cloud dashboards provide access to 5 nodes without a paid plan. Glances (v4.5.7, September 26) is a live look at one machine. Uptime Kuma (2.5.5, September 16) answers a different question, whether a service is reachable, and since v0.20.0 in September 2026 Beszel’s agents cover part of that job too.

At a glance

Feature and footprint matrix

Read September 26, 2026 from each project’s releases and docs, and from Beszel’s source for its retention periods. Beszel shipped three releases between August 17 and September 19. Glances shipped the day I read it. The first row ages fastest.

Beszel: the simple multi-server dashboard

Beszel (MIT, by henrygd) is a hub built on PocketBase and an agent on each host, and the agent reports CPU, memory, disk usage and I/O, network, load, temperature, fan speed, GPU, battery, containers, drive SMART health and ZFS pools. The hub keeps the history, sends the alerts, and handles users, OAuth / OIDC logins and backups to disk or S3-compatible storage.

Two Beszel releases in September 2026 changed what it does. v0.19.0 (September 3) made agents verify the hub’s HTTPS certificate, so an agent pointed at a hub with a self-signed certificate now needs CA_CERT_FILE or it will not connect, and the same release added alerts for container health, failed systemd services, and CPU I/O wait and steal. v0.20.0 (September 19) lets each agent probe targets over ICMP, TCP, HTTP or DNS every 1 to 3,600 seconds and chart response time and packet loss.

The agent installs on Linux and FreeBSD from a script, on macOS through Homebrew, and on Windows through WinGet or Scoop. Beszel’s version numbers are still below 1.0, and v0.19.0 broke self-signed setups. Read the notes before an upgrade. On Proxmox, put the agent on the host or in a VM. Beszel issue #176, open since September 2024, reports agents inside LXC containers showing the host’s RAM.

Pick Beszel if you want one dashboard and alerts across several machines and do not want to run Prometheus and Grafana.

Netdata: depth and real-time diagnostics

Netdata collects most metrics every second with little configuration, runs unsupervised anomaly detection on the agent, and stores its own tiered history, which by default keeps per-second data for up to 14 days, per-minute for up to 3 months and per-hour for up to 2 years, each tier capped at 1 GiB, about 4 GiB of disk in all. Netdata v2.11.0 (August 12) added OpenTelemetry (OTLP) log ingestion next to the systemd journal, and a Network Monitor dashboard for SNMP devices and flows as a technical preview. v2.11.1 (September 16) is a patch release. The agent is GPL-3.0+. The dashboard UI is closed-source and free to use.

Two limits matter once a homelab has more than a few boxes. Netdata caps its Cloud dashboards at 5 nodes for anonymous and Community users. It calls this a “Netdata Cloud plan entitlement, not a streaming or connection limit”: any number of nodes can stream to a Parent and keep collecting and storing data, while only the five selected nodes are accessible through Netdata Cloud. The Homelab plan removes the Cloud dashboard cap for $90 a year (unlimited nodes, fair usage), and Business costs $4.50 per node per month, billed annually. A free standalone agent on Windows collects metrics but locks its local dashboard, so you view it through Netdata Cloud or through a Linux Parent.

Netdata publishes its footprint, which neither of the others does, and its two pages disagree. The resource-utilization page says 100-200 MB of RAM on an empty system and 250-350 MB in typical production; CPU is 1%-5% of one core with default settings and up to 5%-20% in production. The README says about 150 MiB and 5% CPU by default on production systems, and under 1% CPU and about 100 MiB with machine learning and alerts off and ephemeral storage. Its sizing docs name the levers: turning machine learning off cuts CPU, sampling less often can halve it, and keeping fewer tiers cuts memory.

Pick Netdata if you want per-second metrics and anomaly detection on the machine you are troubleshooting, and access to 5 nodes through Netdata Cloud without a paid plan is enough.

Glances: the quick single-box look

Glances (LGPL-3.0, by nicolargo) is a cross-platform top/htop alternative written in Python that runs as a terminal UI, a web UI (glances -w) or a REST API. It shows the host (CPU, memory, disk, network, sensors) and its processes, containers from Docker, Podman or LXD, and VMs from Multipass or Virsh. History lives only in memory. Glances keeps 1,200 values per stat, which its config docs put at about an hour. For more, export to InfluxDB, Prometheus, TimescaleDB or another of its targets and chart it elsewhere.

Thresholds colour the display; warning and critical thresholds can also run a shell command, which is how Glances raises an alert. For several machines, glances --browser lists the Glances servers named in its configuration file or found on the network over zeroconf, in the terminal or, since 4.3, in the web UI. Glances v4.5.7 (September 26) fixes bugs, adds enhancements and carries four security patches, including an unauthenticated credential disclosure through the ports plugin.

Pick Glances if you want a rich live view of one box over SSH or in a browser, or a metrics source to feed another stack.

Uptime Kuma: a different job

Uptime Kuma (MIT, by Louis Lam, who also wrote Dockge) checks whether services answer over HTTP(S) or a TCP port, with keyword and JSON-query checks on the response, ping, DNS records and Docker containers. It sends alerts through 90+ notification services and serves status pages mapped to your own domain. Uptime Kuma’s 2.x line has been stable since 2.0.0 (October 20, 2025), and the current release is 2.5.5 (September 16, 2026). My Uptime Kuma setup guide covers where to run it, which is somewhere outside the network it watches.

Beszel v0.20.0 moved into part of this job. Its HTTP probe times a GET request, a status of 400 or above counts as loss, and the alert fires when a monitor’s packet loss over the past hour passes the threshold, 5% by default. It charts latency and loss per host. I would still keep Uptime Kuma for anything someone outside the house relies on, and let Beszel’s probes watch the gateway and DNS.

Which should you run?

• One dashboard and alerts across several hosts → Beszel.
• Per-second depth and anomaly detection on one box → Netdata, with Cloud dashboard access for 5 nodes without a paid plan.
• A live look at one machine, or a metrics source for another stack → Glances.
• Uptime notifications and a public status page → Uptime Kuma, next to whichever of the above you run.

The stack I would run is a Beszel agent on every host and Uptime Kuma on a machine outside the network. Netdata goes on a box only while I am chasing a problem there. Glances is for a look over SSH. Put the web UIs behind a reverse proxy.

A note on footprint numbers

Only Netdata publishes a number. Beszel’s README says “Smaller and less resource-intensive than leading solutions” and gives none. Glances gives none either. The figures I found on other comparison pages lack a reproducible measurement method, which makes them hard to plan a Raspberry Pi around.

Measuring your own takes twenty minutes. Start the agent, leave it alone for ten minutes, then take ten one-minute samples (pidstat is in the sysstat package):

pidstat -r -u -p "$(pgrep -d, -f beszel-agent)" 60 10

Use netdata or glances in place of beszel-agent. For Netdata the pattern also catches plugin processes with netdata in their command line, which you want counted. The Average: lines give RSS in kB and %CPU per process in separate tables. Sum RSS and %CPU separately across processes. For containers, run docker stats --no-stream a few times a minute apart instead. A summed RSS counts shared libraries more than once, and docker stats reports the container’s cgroup memory rather than RSS, so compare native runs with native runs and containers with containers. Write down the version and which collectors were enabled, including GPU and SMART. In Beszel issue #1203 an agent on a Proxmox host used far more CPU after an upgrade because intel_gpu_top restarted in a loop.

Sources

• Beszel: releases · repository and README · agent installation · network monitoring · record retention in the source · issues #176 and #1203
• Netdata: releases · resource utilization · disk requirements and retention · access control and feature availability · pricing · repository and licence table
• Glances: releases · configuration · containers · quickstart and central browser · repository
• Uptime Kuma: releases · repository and README