Beszel vs Netdata

These two are not competing for the same slot, and treating them as equivalents is how people end up with a 150 MiB agent on a Raspberry Pi that has 1 GB of RAM. Beszel is a fleet view with alerts. Netdata is a microscope for one machine. The numbers below are published by both projects, and they make the split obvious.

What the specification table decides#

Idle memory is 40 MB against 150 MB, and unlike most memory comparisons that ratio holds under load rather than converging. Services to run is 2 against 1, which flatters Netdata: Beszel's two are a hub plus an agent, and you add one more agent per machine, while Netdata's one container needs near-root privileges to be useful. Identity is the row people miss: Beszel has native OIDC through PocketBase, Netdata's local dashboard has no login at all.

Quantify the small one#

Beszel is a hub and agent pair. The hub is a single Go binary with a PocketBase SQLite database, listening on 8090 with one volume at /beszel_data. Each agent watches one machine.

• Agent container image: about 4 MB.
• Agent process: roughly 10 to 25 MB resident on the host it watches.
• Hub: commonly 30 to 60 MB.
• CPU: negligible, because the agent samples on an interval and caches expensive checks. SMART and ZFS pool detail refresh hourly by default rather than on every collection.
• Database: plateaus in the tens of MB, because retention is self-limiting.

What it collects: CPU, memory, disk, network, temperatures, GPU including power draw, per-container stats, systemd services, ZFS pools and SMART. Alerts are thresholds you set in the UI, delivered to ntfy, Gotify, Telegram and similar, with no rule syntax to learn.

Setup for a remote host is genuinely five minutes. Since 0.12 the agent dials out to the hub over a WebSocket using a token, so machines behind NAT need no inbound port:

services:
  beszel-agent:
    image: henrygd/beszel-agent:0.19
    network_mode: host
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./extra-filesystems/data:/extra-filesystems/data:ro
    environment:
      LISTEN: 45876
      HUB_URL: https://beszel.example.org
      TOKEN: ${BESZEL_TOKEN}
      KEY: ${BESZEL_KEY}

Note the extra-filesystems mount. The agent reports the root filesystem by default and nothing else, and a missing disk looks identical to a healthy one: no error, just absent. Verify every mount point appears after setup.

Two other facts to hold. The Docker socket mount is read-only on the mount, which does not make the API read-only: anything that can talk to that socket can create a privileged container. Every container monitor makes this trade, but do not treat the agent as unprivileged. And at v0.19.0 (September 2026) the project is still pre-1.0 and shipping meaningful changes between minors, including new agent environment variables and connection modes, so pin tags rather than running latest and upgrade hub and agents together.

Quantify the big one#

Netdata's own documentation gives the figures, which is more than most projects in this category do:

• RAM: about 150 MiB by default, about 100 MiB with machine learning and alerts disabled. The model is roughly 16 KiB per unique metric plus 5 KiB per ML model.
• CPU: about 5% of one core on production systems, under 1% with ML and alerts off.
• Disk: 1 GiB per tier across three tiers plus metadata, so about 4 GiB, giving 14 days at per-second resolution, 3 months at per-minute and 2 years at per-hour.

That last line deserves emphasis because it is the fact that most comparisons get backwards. Netdata is not a live-view-only tool. Two years of hourly data by default is longer retention than Beszel's hard 30 days and longer than a stock Prometheus, which keeps 15 days.

What you get for the cost: per-second collection, hundreds of collectors that auto-discover what the machine runs, hundreds of preconfigured alarms, and machine learning anomaly detection running per metric. Ten seconds after installation you are looking at disk latency per device, per-container network throughput and interrupt counts, with no configuration.

The costs beyond RAM and disk are real and worth stating plainly:

• Port 19999 has no authentication. By design. It exposes process lists, running containers, network connections and the full metrics API to anyone who reaches it. Bind it to localhost in netdata.conf and proxy it. Never map it to a public IP.
• The container needs to be nearly privileged. The documented compose uses pid: host, network_mode: host, cap_add of SYS_PTRACE and SYS_ADMIN, apparmor unconfined, and read-only mounts of /, /proc, /sys, /etc/passwd, /var/log and the Docker socket. Without them, container and per-application metrics are silently missing. If that is unacceptable, install the native package on the host instead of running a crippled container.
• The dashboard is not open source. The agent is GPLv3 or later; the UI is NCUL1 and the latest version is pulled from Netdata's CDN by default.

Trimming it for smaller hardware is a real option:

# /etc/netdata/netdata.conf
[db]
    storage tiers = 2
    dbengine tier 0 retention size = 256MiB
    dbengine tier 1 retention size = 256MiB
    update every = 2
[ml]
    enabled = no
[web]
    bind to = 127.0.0.1

That gets you under 1 GiB of disk and around 100 MiB of RAM, at the price of half the resolution and no anomaly detection. Which is to say: a worse Netdata that still costs four times a Beszel agent.

What Beszel deliberately does not do#

Say it plainly rather than calling it "focused":

• No history past 30 days, ever. 1 minute rows for 1 hour, 10 minute for 12 hours, 20 minute for 1 day, 2 hour for 7 days, 8 hour for 30 days, then deleted. The windows are in the source, not in a setting.
• No sub-minute resolution. A 20 second IO stall, a fan ramp, a burst that saturates a link for 15 seconds: Beszel will not see any of it. Netdata will show you the exact second.
• No query language. There is no PromQL equivalent and no ad hoc querying. You look at charts and set thresholds.
• No per-process drill-down, no logs, no traces. When a container is eating CPU, Beszel tells you the container. Netdata tells you which process inside it and what it is doing.

If any of those four is something you will need at 2am, Beszel is not enough on its own.

What Netdata deliberately does not do#

• It is not a fleet view without work. The free path to multiple machines is streaming children to a parent, which is a config file and a shared API key. Netdata Cloud does it for you and its Community tier has been capped at five concurrently viewable nodes and one custom dashboard since November 2023, with new signups on a 30 day Business trial so the cap appears a month in.
• It does not have an opinion about your thresholds. It has hundreds of alarms, which is the opposite problem: on a busy machine you will tune them.
• It does not fit on small hardware without being made worse.

Which one for your situation#

What to do next#

Default to Beszel if you are choosing one thing today, because for most home servers a number every minute and an alert when it is wrong is the entire job. Stand up the hub, add every machine, set a disk-usage threshold alert, and check that each extra filesystem you care about actually appears. Then use the built-in backup, which writes a zip to local disk or an S3 bucket on a schedule, rather than copying the live PocketBase database.

Add Netdata on the one machine that misbehaves, bound to localhost behind Caddy as covered in Reverse proxy and TLS. That combination costs about 20 MB per host plus 150 MiB once, and it covers both questions.

Metrics are one leg of three. Read The minimum viable monitoring stack, then add uptime checks that alert you when something is unreachable (Uptime Kuma vs Gatus, Uptime Kuma), a log viewer for when it is actually broken (Dozzle), and disk health that warns before a drive dies (Scrutiny). If you decide you need real retention and cross-machine queries, Netdata vs Prometheus and Grafana covers the step up to Prometheus and Grafana, and Stack planner will tell you what the whole set costs in RAM before you deploy it. Everything else is in Monitoring.