LibreNMS: auto-discovering SNMP monitoring for mixed network hardware

The problem LibreNMS solves: one poller across vendor-specific hardware

Network monitoring tends to fragment. A Cisco stack speaks one MIB set, a Juniper box another, and the Linux servers sitting behind them expose a third. Teams end up running separate checks per vendor, or writing custom SNMP templates that nobody maintains after the author leaves. LibreNMS positions itself against that fragmentation directly: the README describes it as "an auto-discovering PHP/MySQL/SNMP based network monitoring which includes support for a wide range of network hardware and operating systems including Cisco, Linux, FreeBSD, Juniper, Brocade, Foundry, HP and many more." The intended reader is a network or infrastructure engineer who has SNMP-reachable devices from more than one vendor and wants a single inventory, alerting and graphing layer on top of them.

The word doing the work in that sentence is auto-discovering. Rather than requiring you to declare each device's type before polling, LibreNMS is built to work out what a device is from what it answers. That is the core promise, and it is also where the project's complexity lives, because discovery quality depends on the device support that contributors have added rather than on a single vendor's SDK.

How LibreNMS works: PHP, MySQL, SNMP and RRD in one stack

The repository layout makes the architecture legible. The top level contains discovery.php and poller.php as the two central entry points, with discovery-wrapper.py and poller-wrapper.py as Python wrappers around them. The split matters: discovery is the process that interrogates a device and decides what it is and which modules apply, while polling is the recurring collection pass that gathers metrics on a schedule. Keeping them separate means a slow or newly added device does not stall routine collection.

Storage and presentation sit behind that. The topics list includes rrd, and the repository carries a mibs/ directory alongside database/, includes/ and lang/. Metrics land in RRD files, inventory and configuration live in MySQL, and the web UI is served from html/ and public/ on top of a Laravel application (app/, artisan, bootstrap/, config/). The front end is a Vite build with Vue 2, Alpine and Tailwind, per package.json, which tells you the UI is a real application rather than server-rendered templates. A Python requirements.txt pins the poller's supporting libraries (PyMySQL, python-dotenv, redis, psutil, command_runner), so Redis appears as part of the runtime picture even though the README does not describe its role.

The practical consequence of this shape is that LibreNMS is not a single binary you drop on a host. It is a LAMP-style application with a scheduled poller, and the operational surface includes PHP, MySQL, RRD files, SNMP reachability and a queue. That is a heavier footprint than an agent-based collector, and it is the price of polling arbitrary hardware over SNMP.

Installing LibreNMS and adding a first device

The README does not carry install commands. It points at the doc directory in the repository and at docs.librenms.org for installation instructions, and it offers a VirtualBox image based on Ubuntu for trying the system without installing it, with login credentials and setup details in the accompanying documentation. So the honest starting point is: read the install page for your distribution before running anything, because the required PHP and MySQL versions are set there and not in this file.

What the repository does give you is the shape of the configuration. The root config.php.default is the template for the instance configuration, and .env.example shows the Laravel-side environment keys, including the database connection and the application key:

APP_KEY=
#DB_HOST=
#DB_DATABASE=
#DB_USERNAME=
#DB_PASSWORD=
#APP_URL=

Those keys are commented out in the example, so a fresh deployment fills them in for the local MySQL instance and generates APP_KEY. Once the web UI answers, the first real task is adding a device, which in LibreNMS means giving it an SNMP hostname or address and credentials. The repository exposes discovery.php at its top level as the discovery entry point, and the documentation covers how it is invoked; the README does not list its flags, so check the docs before running it against production hardware. What you should see is discovery output for that host: the system being identified, modules being selected, and the device appearing in the web interface afterwards. If discovery returns nothing useful, the usual causes are SNMP reachability, a community string or SNMPv3 credential mismatch, or a device that no contributor has written support for. The README does not document a rollback or removal procedure, so treat discovery as a write into your inventory and test against a lab device first.

For a container-based trial, the project publishes images and the documentation covers Docker, and the repository ships discovery-wrapper.py and poller-wrapper.py intended for scheduled execution rather than interactive use. The README does not give a docker compose file, so any compose setup you find should be checked against the current docs rather than assumed.

Where LibreNMS is the wrong choice

The clearest boundary is Windows. People search for a Windows install, and the repository does not offer one: the only Windows-adjacent path in the README is downloading a VirtualBox image, which is a way to try LibreNMS, not a supported production deployment. If your monitoring server must run Windows, this is not the tool.

The second boundary is device support. Auto-discovery is only as good as the definitions contributors have written. A device that answers SNMP but has no matching support will be discovered as a generic host at best, and you will be reading raw OIDs instead of vendor-specific graphs and alerts. The README names Cisco, Linux, FreeBSD, Juniper, Brocade, Foundry and HP, and says "and many more", which is a claim about breadth rather than a guarantee for your specific model. Verify against the documented supported devices before you plan a rollout.

The third is operational weight. Because LibreNMS is a PHP application with MySQL, RRD storage and a poller that must run on a schedule, it asks for a maintained server with a working cron or service setup. A team that wants a single static binary and no database is choosing the wrong architecture here, regardless of how good the discovery is. And the documentation in this repository is deliberately thin: installation, upgrade and troubleshooting all live on the docs site, so anyone operating LibreNMS is depending on that external site staying accurate for their version.

LibreNMS compared with Zabbix and Checkmk

The two comparisons people actually search for are Zabbix and Checkmk, and the difference is in where the device knowledge lives. Zabbix is a general monitoring platform: it ships an agent, supports SNMP, and expects you to define items, triggers and templates, with a large template library maintained by the community and the vendor. Its centre of gravity is the template you attach to a host. LibreNMS inverts that. Discovery runs first and selects modules based on what the device reports, so the starting point is the device rather than a template you chose in advance.

Checkmk sits closer to the appliance end of the spectrum. It is distributed as an appliance or a package with a curated check catalogue, and its model is that checks are written and shipped by the vendor for known device families. That yields predictable results for supported hardware and a clear answer when something is unsupported. LibreNMS trades that predictability for breadth and for the ability to add support through pull requests, which is consistent with the community framing in its README and its Debian Social Contract reference.

None of these three is strictly better. If you want a vendor-curated catalogue and are willing to stay inside it, Checkmk's approach is simpler to operate. If you want a general-purpose platform where you write the checks, Zabbix gives you that control. LibreNMS is the one that assumes the device will tell you what it is, and that assumption is the whole bet.

Licence, releases and the cost of staying current

LibreNMS is free software under the GNU General Public License, version 3 or later, per the licence text in the README, with copyright spanning 2006-2012 for Adam Armstrong and 2013-2026 for individual contributors. The README also states a GPL exception permitting linking or combining LibreNMS with included copies of certain third-party software while the remaining software stays under GPLv3, with the list in the Acknowledgements page. That exception exists because a PHP application bundles front-end and library code that carries its own terms; if you redistribute a modified LibreNMS, read the Acknowledgements page rather than assuming everything in the tree is GPLv3. This is a description of the licence text, not legal advice.

The release cadence is visible in the tags: 26.9.0 on 2026-09-21, followed by 26.9.1.1 on 2026-09-22, with 26.8.2 on 2026-08-31 before that. The version scheme is date-based, and the immediate bugfix release after a feature release is the pattern to expect. The last push to master was on 2026-09-22, so the project is under current development rather than dormant.

Upgrade cost is where the external documentation matters most. The repository carries daily.sh and a cronic wrapper at the top level, which indicates the project expects scheduled maintenance tasks rather than manual upgrades, and CHANGELOG.md records what changed between releases. The README does not document rollback, so a version pin plus a database and RRD backup is the only defensible upgrade posture. The .env.example file also implies a Laravel application key and session configuration that must survive upgrades, so treat .env as state, not as a file to regenerate.

Editorial conclusion

Adopt LibreNMS if you run SNMP-capable switches, routers or servers from several vendors and want one auto-discovering poller instead of per-vendor tooling. Do not adopt it if you need a Windows server install, since the README only offers a VirtualBox image for trying it and points to docs.librenms.org for installation. Before committing, verify two things: that your hardware appears in the documented supported device list, and that your PHP, MySQL and SNMP prerequisites match what the doc directory specifies for your distribution.

Frequently asked questions

Official sources

1. Issues
2. librenms/librenms on GitHub
3. Project website
4. README
5. Releases