LibreNMS

Last reviewed Sep 13, 2026 · 812 words

Budget 1 GB of RAM for the base install and plan on roughly another gigabyte for every 100 devices you poll, because LibreNMS polls each one over SNMP every 5 minutes and stores the result as RRD files that grow with port count. On a homelab with a managed switch, a router, a NAS, and 3 hypervisors it idles well under that. Where it earns its 4,872 stars is the network side: point it at one switch with LLDP enabled and it walks the neighbour table and finds the rest of the fabric on its own, then graphs every interface, every CPU, every temperature sensor the vendor MIB exposes. If your fleet is mostly containers and Linux hosts rather than network gear, stop here and go read the Prometheus section.

The Docker stack has five moving parts, and all five matter

The official compose example runs librenms/librenms as the web app on port 8000, plus separate containers from the same image for the dispatcher (polling and discovery) and snmptrapd, with MariaDB and Redis alongside. RRDtool lives inside the image and writes to an rrd volume; that volume is the one whose disk you will watch. The dispatcher container replaced the older cron-driven poller design, and it needs Redis to coordinate workers. Set TZ, PUID, and PGID identically on every container, back up the MariaDB database and the rrd volume together (they only make sense as a pair), and give the stack a real hostname because trap sources and alert links use it.

Bare-metal on a LAMP stack works and the docs are thorough; the librenms user, the lnms CLI, and validate.php tell you exactly what is misconfigured. I still prefer Docker here because the PHP extension list is long and the image maintainers keep it correct.

Add one device, let discovery find the rest

lnms device:add core-switch.lan --v2c -c public

Use SNMPv3 (--v3 with auth and privacy passphrases) on anything that leaves a trusted VLAN. After the first discovery run, enable the xDP, ARP, and OSPF/BGP autodiscovery options in the settings (subnet scanning with snmp-scan.py is the blunt instrument for the rest) and watch the device list fill in. Every discovered device gets an interface graph, a device overview, and an entry in the inventory with serial, OS version, and uptime.

Linux servers need snmpd installed and a community configured; the distro script adds distribution and package detail. For anything without SNMP, LibreNMS is the wrong shape. That is not a criticism; it is a monitoring system built for the thing SNMP is good at.

Alerting works once you write rules, and the defaults are quiet

Nothing alerts until you create a rule. That is the correct default and the opposite of Nagios, whose stock checks page you about disk space on a NAS you never asked about. Rules are built in a query builder (devices.status = 0 for "device down", ports.ifOperStatus = down AND ports.ifAdminStatus = up for "a port that should be up went down"), with per-rule delays so a 30-second blip never fires. Transports include mail, Slack, Discord, Telegram, Pushover, ntfy, webhooks, and dozens more. Alert templates are editable. Take the community rule collection as a starting point and expect to spend an evening tuning thresholds to your gear.

Billing (bandwidth accounting by port, 95th percentile) and the distributed poller mode exist for people running LibreNMS at ISP scale, and they are genuinely used at that scale, which is a good sign for a project in the 5,000-star band: it is small in stars because it is niche, not because it is unmaintained.

Prometheus, Zabbix, and the honest boundaries

Prometheus with snmp_exporter can scrape the same switches, and if you already run it with Grafana for application metrics, adding a second monitoring system is a real cost. What you lose is discovery, the per-device pages, and the inventory. Prometheus makes you describe each target; LibreNMS finds them. Zabbix is the general-purpose alternative that does both agents and SNMP well, with a heavier install and a steeper UI. My split: LibreNMS for network gear and anything SNMP-only, Prometheus for services and containers, and Uptime Kuma for "is the website up" checks that neither of the others should be doing.

What I'd do

Docker compose from the official example on a box with 2 GB and a disk you can grow, SNMPv3 on every device, LLDP autodiscovery on, three alert rules on day one (device down, port down, disk over 90 percent) sent to a chat channel, and a weekly look at the rrd volume size. Run it beside Prometheus rather than instead of it. For anyone with more than 2 managed switches, it is the monitoring tool I would install first.