Beszel

Last reviewed Aug 26, 2026 · 855 words

Ten minutes and a public key. That is what Beszel asks in exchange for a single page showing CPU, memory, disk, network, temperature and per-container Docker stats for every machine you own, with alerts when any of them crosses a line. It is a Go binary with an embedded SQLite database, MIT, first released in 2024 and already past 24,600 stars, and both the hub and the agents idle at a few tens of megabytes; the 128 MB floor in the listing is generous. What it will not give you is per-second resolution, process lists or log tails. For a homelab, that trade is usually correct, and the last section covers when it is not.

Hub first, then one agent per host

The hub is the web UI and the database. Run it on whichever box you check first when something feels slow:

services:
  beszel:
    image: henrygd/beszel
    ports: ["8090:8090"]
    volumes: ["./beszel_data:/beszel_data"]
    restart: unless-stopped

Open port 8090, create the admin account, click Add System, and the hub shows you the public key it will use to talk to agents. Then on each host:

services:
  beszel-agent:
    image: henrygd/beszel-agent
    network_mode: host
    volumes: ["/var/run/docker.sock:/var/run/docker.sock:ro"]
    environment:
      LISTEN: 45876
      KEY: "ssh-ed25519 AAAA...the key from the hub..."
    restart: unless-stopped

The agent listens on 45876 and the hub connects to it over SSH using that key, so no credentials live on the monitored host and nothing but the hub can read from it. The Docker socket mount, read-only, is what turns on per-container CPU and memory; skip it on hosts where you do not want any process holding the socket. There is also a single-binary install script for hosts without Docker, and newer releases let the agent dial out to the hub instead, which solves the case where a monitored box sits behind NAT or a firewall you cannot open. Repeat per host; by the fourth one it is 90 seconds each.

Alerts are the reason to bother

Graphs are pleasant, but the value of a hub is the message at 7 in the morning saying the backup server's disk hit 90 percent. Per system, Beszel lets you set thresholds for CPU, memory, disk, bandwidth and temperature over a chosen window, plus a status alert for when the agent stops answering. Delivery goes through email via SMTP or through notification URLs in the Shoutrrr style, so ntfy, Discord, Telegram, Gotify and most of the usual suspects work with one line in the settings. Set the disk alert first and the down alert second; those two catch most of what actually happens in a homelab.

Retention that fits in SQLite

Beszel keeps detailed points for the recent past and rolls them into coarser averages as they age, roughly per-minute data for the last hour and multi-hour averages for the last month. That is why the database stays small and why the whole thing runs comfortably from a Raspberry Pi. It is also why you cannot ask it what happened at 03:14:07 last Tuesday. If forensic resolution matters to you, that is a different tool.

It is not Netdata, and it is not Uptime Kuma

Three tools get confused here and they answer different questions. Beszel answers "how healthy are my hosts" from the inside. Uptime Kuma answers "is the service responding" from the outside, by polling URLs and ports, and a host can be perfectly healthy while its web app returns 502. Netdata answers both in far more depth, with per-second metrics across thousands of series, at a cost in RAM and in the time it takes to find anything on the dashboard. My homelab monitoring post argues for pairing Beszel with Uptime Kuma: one inside-out, one outside-in, both light, and together they cover 90 percent of the incidents a home setup ever has. Reach for Netdata or the heavier stacks in the monitoring category when you are chasing a specific performance mystery rather than keeping watch.

The young-project caveat

A project that went from nothing to a large user base in about 2 years moves fast, and that has meant occasional changes to how agents connect and how settings are stored. Read the release notes before updating the hub, update agents to match, and keep the beszel_data directory in your backup rotation; it holds the database, the key and every alert rule you configured.

What I'd do

Hub on the always-on box next to the reverse proxy, agent on every host including the hub's own, Docker socket mounted read-only everywhere I run containers. Disk and down alerts on every system through ntfy, CPU and memory alerts only on the boxes that have run hot before. Uptime Kuma alongside for the outside-in view. Total memory for all of it across 5 hosts is less than one browser tab, and I have not needed anything heavier for a home network in a long time.