Beszel gives small fleets one hub and one agent per host
Beszel splits monitoring into a central PocketBase-based hub and an agent on every system. The hub stores history, presents dashboards, manages users, and sends alerts. Agents report host and container measurements. That design is easy to understand and far smaller in scope than a Prometheus, exporter, database, alert manager, and Grafana installation. It fits a homelab, a set of rented servers, or a small business that wants charts and warnings without hiring an observability specialist.
The repository we tested contained 429 files and about 65,649 lines of source in a 5 MB checkout. Beszel covers CPU, memory, swap, disks, disk I/O, networks, temperatures, fans, batteries, and several GPU vendors. It also records Docker or Podman container status and usage. Alerts can watch common thresholds and host availability. This is a deliberately defined monitoring product, so you get a useful dashboard quickly but cannot invent any metric or query you like.
The quick start still requires trust between 2 components
The documented Docker example starts the hub on port 8090 and can connect a local agent through a Unix socket. After creating the first administrator, you add a system in the web interface, copy its public key and token into the agent environment, then restart that agent. Since v0.12.0, a universal token can enroll an agent without configuring the system first. Remote machines follow the same idea over a network connection instead of the local socket.
Docker statistics require access to the Docker socket, mounted read-only in the example. That is a meaningful permission even when the mount itself is read-only because the socket exposes information and control surfaces from the container runtime. Agent configuration also changes with the metrics you want. Extra filesystems need explicit paths, GPU collection may need device access or utilities, and SMART data depends on what the host exposes. Start with basic host metrics, then add privileges one collector at a time.
What happened when we ran it
Our clean Go sandbox installed 114 packages in 42 seconds. The build succeeded in 11 seconds, so compiling the checked-out source was straightforward on 3 CPUs with 8 GB of memory. The repository was only 5 MB, a welcome contrast with monitoring systems that bring a large frontend toolchain or several services into the development checkout. No top-level Dockerfile or conventional tests directory was detected, although test files live alongside Go packages.
The full test command failed after 49 seconds. Go reported 9 passing packages and 3 failing packages out of 12. The final lines show several hub packages with no test files, one transport package passing, then a plain FAIL. They do not show the names or assertions behind the 3 failures. We can report the red result, but attributing it to PocketBase, timing, permissions, or the sandbox would be speculation beyond the supplied log.
For a production decision, separate buildability from test health. Our 11-second build shows the source compiled at commit f1e5797, while the failed 12-package run means that commit did not provide a clean full-suite baseline in our Debian container. Test the release and target operating systems you intend to deploy, especially if you depend on a specific hardware collector. Beszel supports many host combinations, and that breadth creates cases a single Linux container cannot prove.
ZFS and device-specific metrics need qualification
Beszel reports ordinary filesystem use and can monitor extra mounted filesystems. Native ZFS pool capacity, health, scrub state, and vdev details remain requested in issue 1541. Issue 1782 describes a TrueNAS Scale deployment where the containerized agent reported its roughly 10 MB overlay as the root disk because the ZFS-only host returned no normal partitions. Extra mounted datasets worked for that reporter, but the primary disk did not. ZFS operators should reproduce their exact mount and container arrangement before trusting storage alerts.
SMART monitoring has similar hardware boundaries. A current request says an HP ProLiant controller requires explicit smartctl -d cciss,N arguments that Beszel does not automatically enumerate. Release v0.18.8 improved mdraid consistency checks and SMART device detection, yet those changes do not promise support for every controller. Confirm each disk appears, compare its health with the host's own tool, and test a known alert condition before treating the dashboard as the only storage warning system.
Built-in accounts and backups reduce surrounding work
The hub includes multiple users, system sharing, OAuth or OIDC login, API access, and automatic backups to disk or S3-compatible storage. Those are useful operational features, since a dashboard with no authentication or backup plan quickly becomes another fragile service. Notification documentation covers many providers. A reverse proxy can give the hub TLS and a stable address, while password authentication can be disabled when an identity provider is ready.
Each added service brings configuration outside Beszel. OAuth needs client details and callback URLs. Object storage needs endpoint and access credentials. Notifications need provider tokens or webhooks. None is required for a one-host trial, but a shared deployment should record who owns those credentials and how the hub database is restored. The backup feature is only useful once a restore has been tested.
Active v0.18.8 development comes with a large queue
GitHub recorded the last push on August 24, 2026, one week after v0.18.8 was released. The repository had 24,674 stars and 318 open issues and pull requests when fetched. The latest release added fan, battery, Intel GPU, FreeBSD sensor, proxy, authentication, and platform work, alongside fixes for Docker counters and SMART records. Recent pull requests and issue updates show continued development; the combined open number describes both proposed work and problems, not 318 confirmed defects.
Beszel earns its place by choosing sane defaults for a bounded job. A 2-component deployment can give a small fleet historical metrics, container charts, and alerts without a separate query and dashboard platform. Our failed package tests stop us from calling the source baseline clean, and hardware-specific reports require local verification. If its fixed metric set covers your machines, run a trial. If you need custom telemetry or storage-specific depth, start with Prometheus or Netdata instead.