Beszel
Small multi-server dashboard: CPU, memory, disk, containers, alerts, 30 days of history
Beszel is a hub and agent pair that charts CPU, memory, disk, network, temperatures, GPU and per-container stats across several machines, and alerts when a threshold is crossed. It covers the ground people used to cover with a Netdata tab per host, at a fraction of the resource cost and with a fraction of the detail.
Our verdict on Beszel#
Actively maintained and moving fast: v0.19.0 landed in September 2026 and the agent picked up ZFS, SMART, systemd services and GPU power draw over the past year without the hub getting heavier. The scope is deliberately narrow. There are no logs, no traces, no per-process drill-down, no query language, and metrics stop at 30 days because the retention windows are hard-coded, not configurable. Against Netdata the comparison is stark and worth stating plainly: the agent image is about 4 MB and the agent process idles in the low tens of MB, against Netdata's documented 150 MiB and roughly 4 GiB of disk. What that buys Netdata is per-second resolution, machine learning anomaly detection and hundreds of collectors you did not configure. Beszel gives you a number every minute and an alert when it is wrong, which for most home servers is the whole job.
Who Beszel is for#
Choose it if
- Someone with three to twenty machines who wants one page showing all of them and an alert when a disk fills
- Raspberry Pis, mini PCs and small VPS instances where a 150 MiB monitoring agent is not acceptable
- Anyone who wants container CPU and memory history without standing up Prometheus and cAdvisor
- People who want threshold alerts to ntfy, Gotify or Telegram with no rule syntax to learn
Look elsewhere if
- You need metrics history beyond 30 days, which the retention windows do not allow
- You want to ask questions of the data: there is no PromQL equivalent and no ad hoc querying
- You are troubleshooting sub-minute events, where the coarse sampling will simply miss them
What running it actually looks like#
Two pieces: the hub (port 8090, one volume at /beszel_data) and one agent per machine you want to watch. Since 0.12 the agent dials out to the hub over a WebSocket using a token, so remote hosts behind NAT need no inbound port; the older mode has the hub connecting in to the agent on 45876 with an SSH key, which does need a firewall rule. Agents run with network_mode: host and a read-only Docker socket mount for container stats, or as a binary installed by the hub's copy-paste script. First run is creating the admin account in the browser, then Add System, which generates the exact compose file or install command for that host. A universal token under /settings/tokens skips per-host setup.
Resource profile#
- Memory
- 40 MB idle, around 80 MB in ordinary use. Hub is a single Go binary with SQLite, commonly around 30 to 60 MB; each agent adds roughly 10 to 25 MB on the host it watches. Observed figures, not published minimums.
- CPU and acceleration
- Negligible. The agent samples on an interval and caches expensive checks: SMART and ZFS pool detail refresh hourly by default rather than on every collection.
- Storage growth
- Retention is fixed in code and self-limiting: 1 minute records for 1 hour, 10 minute for 12 hours, 20 minute for 1 day, 2 hour for 7 days, 8 hour for 30 days. The database plateaus at tens of MB.
- Operational load
- 1 of 5, Set and forget. Two small containers, one SQLite file, no external database, and built-in backup to disk or S3 from the web UI. Upgrades are a tag bump. The only recurring job is keeping agent versions roughly in step with the hub.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Everything is in the hub's /beszel_data: a PocketBase SQLite database plus auxiliary files. Use the built-in backup, which writes a zip to local disk or an S3-compatible bucket on a schedule and can restore in place, rather than copying the live database. Agents hold effectively no state worth keeping; the token and public key can be reissued from the hub in a minute. Because retention caps at 30 days, an old backup restores your systems, users, alert rules and notification config, but not history that has since aged out.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
History is capped at 30 days, permanently
The record cleanup job keeps 1 minute rows for an hour, 10 minute for 12 hours, 20 minute for a day, 2 hour for a week and 8 hour for 30 days, then deletes them. These windows live in the source, not in a setting, so there is no way to keep a year of graphs. If you need seasonal comparisons, run Prometheus alongside it or export through the REST API.
The Docker socket mount is root equivalent
The agent mounts /var/run/docker.sock read-only to read container stats. Read-only on the mount does not make the API read-only: anything that can talk to that socket can create a privileged container. It is the same tradeoff every container monitor makes, but do not treat the agent as an unprivileged process, and do not expose its port to untrusted networks.
Local hub and agent cannot use localhost
When the hub and an agent run as containers on the same machine, localhost resolves inside each container's own namespace and the connection silently fails. The documented fix is a shared unix socket: mount a directory into both, set the agent's LISTEN to a socket path inside it, and enter that path as the host in the web UI. Expect this on the very first system you add.
Pre-1.0 means minor versions move
At v0.19 the project is still shipping meaningful changes between minors, including new agent environment variables and connection modes. Agents and hub are best upgraded together, and the copy-paste compose from a year-old tutorial may set variables that no longer mean the same thing. Pin image tags rather than latest, and read release notes before bumping several versions at once.
Disks only report if the agent can see them
The agent reports the root filesystem by default. Extra disks need either an EXTRA_FILESYSTEMS entry for binary installs or a bind mount into /extra-filesystems/ for containers, and SMART needs the device to be readable by the agent's user. Silence here looks identical to healthy: no error, just a missing disk, so verify each mount point appears after setup.
Specifications#
- Category
- Monitoring and observability
- Licence
- MIT (Permissive)
- Written in
- Go
- First release
- 2024
- Maturity
- Young
- Datastore
- SQLite via PocketBase
- Default ports
8090,45876- Ships as
- docker, native binary, homebrew / winget package
- arm64 builds
- Yes
- Identity
- Native OIDC. PocketBase OAuth2 and OIDC providers are built in, password auth can be turned off with `DISABLE_PASSWORD_AUTH`, and `TRUSTED_AUTH_HEADER` supports forwarded auth.
- Replaces
- Netdata Cloud, Datadog, New Relic, Glances
- Project site
- beszel.dev
- Source
- github.com/henrygd/beszel
- Documentation
- beszel.dev/guide/what-is-beszel
Alternatives to Beszel#
Everything else in monitoring and observability, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Dozzle | 1, Set and forget | 15 MB | MIT |
| Gatus | 1, Set and forget | 25 MB | Apache-2.0 |
| Grafana | 2, Light | 150 MB | AGPL-3.0-only |
| Netdata | 2, Light | 150 MB | GPL-3.0-or-later (agent); dashboard UI under NCUL1 |
| Uptime Kuma | 2, Light | 120 MB | MIT |
| Prometheus | 3, Moderate | 150 MB | Apache-2.0 |
Where Beszel comes up elsewhere#
Migration guides
Reference
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.