Once you run more than a couple of services, you want to see your homelab — what’s hot, what’s full, what’s down. The lightweight monitoring conversation in 2026 centers on three resource monitors — Beszel, Netdata, and Glances — plus Uptime Kuma, which does a related-but-different job. They’re easy to confuse, so here’s what each actually is, verified against their repos and docs, and how to pick.

One key distinction up front: Beszel, Netdata, and Glances monitor resources (CPU, RAM, disk). Uptime Kuma monitors uptime (is a service reachable?). They’re complementary, not alternatives — most homelabs run one of each.

At a glance

BeszelNetdataGlancesUptime Kuma
JobResource dashboardDeep real-time metricsSingle-box glanceUptime / status pages
LicenseMITGPL-3.0 (agent)LGPL-3.0MIT
ArchitectureHub + agentsPer-node agentOne process/hostSingle app
Multi-server dashboardYesYes (Cloud/Parent)Per-hostYes (checks)
Historical dataYesYes (tiered)No (export)Yes (checks)
FootprintVery lightHeavier (tunable)Light (Python)Light
Stars (approx)~23k~79k~33k~88k

Star counts are rounded mid-2026 values.

Beszel: the simple multi-server dashboard

Beszel (MIT, by henrygd) is the easy default for “show me all my boxes on one screen.” It’s a hub-and-agent design: the hub is a web dashboard built on PocketBase, and a tiny Go-binary agent runs on each host reporting CPU, memory, disk usage and I/O, network, load, temperature, GPU, Docker container stats, and S.M.A.R.T. disk health. It keeps historical data, sends configurable alerts (CPU, memory, disk, bandwidth, temperature, load), and supports multi-user, OIDC, and automatic backups to disk or S3.

It launched in 2024 and grew fast (~23k stars) because it nails the homelab sweet spot: low overhead, dead-simple setup, one clean pane of glass. Be clear about scope, though — it’s deliberately not a full observability platform. No per-second high-resolution metrics, no log aggregation, no APM/tracing, no PromQL. It’s a resource dashboard, and a very good one. (It’s still pre-1.0, so expect some churn, and verify current first-party Windows-agent support if you need it — that’s historically been community/fork territory.)

Pick Beszel if you want a low-overhead dashboard and alerts across several servers without running a heavier stack.

Netdata: depth and real-time diagnostics

Netdata is the opposite end: maximum depth out of the box. Its agent collects per-second metrics, auto-discovers thousands of metrics with little config, and runs unsupervised ML anomaly detection right on the agent. When you need to understand why a box is misbehaving in real time, nothing here competes. Licensing nuance worth knowing: the agent core is GPL-3.0 (open source), but the UI is closed-source-but-free and Netdata Cloud is closed-source (free and paid tiers) — the self-hosted agent works fully without Cloud.

On the perennial “is Netdata heavy?” debate, be fair: it does far more per node than the lightweights, so it uses more — but it’s tunable. Netdata’s own docs cite roughly 150 MiB RAM and ~5% CPU by default, dropping to ~100 MiB and under 1% CPU with ML and alerts off and ephemeral storage. (You’ll see third-party “200–500 MB/node” claims; those aren’t Netdata’s stated default and depend heavily on config — treat them as unverified.) Its free Cloud tier caps at 5 nodes; a non-commercial Homelab plan is $90/year, and Business is $4.50/node/month.

Pick Netdata if you want deep, real-time metrics and anomaly detection and don’t mind a heavier (but adjustable) footprint.

Glances: the quick single-box look

Glances (LGPL-3.0, by nicolargo) is a Python-based top/htop alternative for a single machine, runnable as a terminal UI, a web UI, or a REST API. It shows live CPU, memory, disk, network, sensors, processes, and containers (Docker/Podman/LXC, even Kubernetes pods) at a glance. The key caveat: it’s not historical by default — you get a live snapshot with only short in-memory history. For real retention you export to InfluxDB, Prometheus, PostgreSQL, and others, then chart it in Grafana. Alerting is basic threshold coloring, not a full notification engine.

Pick Glances if you want an instant rich overview of one box for ad-hoc diagnostics, or a lightweight metrics source to feed a bigger stack — not a standalone multi-server dashboard.

Uptime Kuma: a different job

Uptime Kuma (MIT, by Louis Lam, the Dockge creator) is uptime/status-page monitoring, not resource monitoring. It runs HTTP, TCP-port, ping, DNS, and keyword checks to tell you whether a service is up, down, or slow, with 90+ notification channels and public status pages. Its 2.x line is now stable (it added MariaDB support and a UI refresh — older “2.x is beta” advice is outdated). Run it alongside a resource monitor: Kuma answers “is it reachable?”, the others answer “why is the host struggling?”

Which should you run?

  • Simple resource dashboard + alerts across all hosts → Beszel. The homelab default.
  • Deep real-time metrics + anomaly detection on a box → Netdata. Heaviest but most powerful.
  • Quick single-box glance or a metrics source → Glances.
  • Service uptime + status page + notifications → Uptime Kuma (run it alongside the above).

A sane, common stack is Beszel + Uptime Kuma — resource overview plus uptime/status — reaching for Netdata when you need to deep-dive a specific host and Glances for one-off terminal inspections. If you’re deploying these in containers, the Docker Compose starter stack guide pairs well, and you’ll likely front the web UIs with a reverse proxy.

A note on footprint numbers

The whole appeal of “lightweight” monitoring is low overhead — but precise RAM/CPU figures are the most-fabricated numbers in this space. Beszel is genuinely tiny (a single small Go agent), Glances is light (a Python process), and Netdata is heavier-but-tunable per its own docs. Beyond Netdata’s published defaults, exact figures vary by version, host, and what you’re collecting — so measure on your own hardware with docker stats rather than trusting a blog’s number, including this one.

Sources

Frequently asked questions

What is the most lightweight homelab monitoring tool?
Beszel is the lightest multi-server option by design: a small hub plus a single tiny Go-binary agent on each host. Glances is also light as a single Python process for one machine. Netdata does far more per node (per-second metrics, on-agent ML), so it legitimately uses more — its own docs cite roughly 150 MiB RAM and ~5% CPU by default, tunable down to ~100 MiB and under 1% CPU. Exact footprint always depends on config and library versions, so measure on your own box with docker stats rather than trusting any single number.
What is Beszel and why is it popular?
Beszel is a free, open-source (MIT) lightweight server monitoring tool by henrygd, built as a hub-and-agent system: the hub is a web dashboard (built on PocketBase) and a small agent runs on each monitored host reporting CPU, memory, disk, network, temperature, GPU, Docker container stats, and S.M.A.R.T. disk health. It keeps historical data, sends configurable alerts, and supports multi-user and OIDC. It launched in 2024 and grew fast (~23k GitHub stars by 2026) because it gives homelabbers one clean dashboard for all their servers with minimal overhead and easy setup.
Beszel vs Netdata — which should I use?
Use Beszel if you want a simple, low-overhead dashboard across several servers with sensible alerts and don’t need deep diagnostics — it’s the easy default for a homelab overview. Use Netdata when you want depth: per-second real-time metrics, automatic discovery of thousands of metrics, and on-agent machine-learning anomaly detection for troubleshooting why a box is struggling. Netdata is heavier per node (but tunable), and its free Cloud tier caps at 5 nodes. Many people run Beszel for the overview and reach for Netdata on a specific box when they need to dig in.
Does Glances store historical data?
Not by default. Glances shows a live snapshot (with only short in-memory history) — it’s a top/htop-style ‘glance’ at one machine via terminal, web UI, or REST API. For real history you export its metrics to an external store like InfluxDB, Prometheus, PostgreSQL, or others, then visualize in something like Grafana. So Glances is best as a quick single-box look or as a metrics source feeding a bigger stack, not as a standalone historical dashboard like Beszel or Netdata.
Is Uptime Kuma a resource monitor like Netdata?
No — it’s a different category. Uptime Kuma (MIT, by Louis Lam) does uptime and status-page monitoring: HTTP, TCP port, ping, DNS, and keyword checks that tell you whether a service is up, down, or slow, with 90+ notification channels and public status pages. It does not chart your CPU, RAM, or disk. You run it alongside a resource monitor: Uptime Kuma answers ‘is my service reachable?’ while Beszel/Netdata/Glances answer ‘why is the box struggling?’ Its 2.x line is now stable (with MariaDB support).
What's a good lightweight monitoring stack for a homelab?
A common, sensible setup is Beszel plus Uptime Kuma: Beszel gives you a resource dashboard and alerts across all your hosts, and Uptime Kuma watches service uptime and publishes a status page with notifications. Then reach for Netdata on any single box where you need deep, per-second diagnostics, and use Glances for quick one-off terminal inspections or as a metrics source. They’re complementary tools, not competitors — most homelabs end up running two or three of them for different jobs.