Network UPS Tools (NUT): a C daemon stack for UPS and PDU monitoring

What NUT solves that a vendor utility does not

Most UPS vendors ship a small utility that talks to one device over one cable and shows a tray icon. That works until the machine holding the cable reboots, or until three other hosts also need to know the battery is at 12 percent. NUT, the Network UPS Tools project, exists to separate the device conversation from the consumers of that data. A driver process owns the hardware link. A server process, upsd, holds the current state in memory and answers queries. Clients connect to upsd over TCP instead of each opening the USB device themselves. The repository topics list what the drivers cover: usb, serial, snmp, modbus, netxml, epdu, pdu, ups. That range is the point. The same upsd instance can sit in front of a consumer USB UPS in a home rack and a switched PDU in a datacenter, and the clients do not need to know which is which. The audience is system and infrastructure engineers who already run Linux or BSD servers and want UPS state to be a network service rather than a desktop app. The project also publishes its wire protocol as Informational RFC 9271 through the IETF, which is unusual for this class of tool and means a client can be written against a stable public document rather than against the C source.

Driver, upsd, client: the three-process data flow

The architecture is a chain, and each link has a different failure mode. At the bottom, one driver process per device speaks the vendor protocol and publishes variables. The top-level directories show the split plainly: drivers/, server/, clients/, common/, lib/. The driver does not decide what to do about a low battery; it reports. In the middle, upsd collects those variables and serves them. It is the only component that needs to be reachable from other machines, and it is where access control lives. Above it, clients read state and can issue instant commands such as a battery test or a load-off. The variable names are the stable interface here, not the code. A client asks for ups.status and gets OL, OB, LB or a combination, and that string means the same thing whether the driver is talking to a USB HID device or an SNMP agent. The trade-off is that the driver is a separate process that can die independently of upsd. If it does, upsd keeps serving the last values it received unless it notices the driver is gone, so a monitoring setup that only polls the client side can miss a dead driver. That is a design consequence of the split, not a bug, and it is the first thing to check when readings freeze.

Getting NUT and reading your first UPS status

The README points at the project homepage, networkupstools.org, and the repository carries INSTALL.nut.adoc at the top level for build instructions. That file, not the README, is where the project documents how to obtain and build the code, including the autotools path through autogen.sh and configure.ac. The repository also carries conf/ for configuration file templates and clients/ for the client programs, so the install sequence is: build or package the code, write a driver section in ups.conf, start the driver, start upsd, then query it with a client. The README does not reproduce those commands, and this article does not invent them; the exact flags and file contents belong to INSTALL.nut.adoc and the man pages shipped alongside the binaries. What the repository layout does tell you is which component you are configuring at each step. The driver reads ups.conf. The server reads its own configuration under conf/ and is the process that listens for client connections. The client programs under clients/ are the read side. If you are starting from a distribution package rather than a source build, the package's own documentation is the authority on file locations, because NUT's build system allows those paths to be set at configure time. The one thing worth checking before any of this is the hardware compatibility list on the project site, since driver selection is hardware-specific and the README does not enumerate models.

Where NUT is the wrong tool

NUT assumes a device that exposes a usable protocol and a host that is always on to run the driver. Neither assumption always holds. If your UPS only ships a closed Windows agent and no documented USB HID or serial interface, no amount of NUT configuration will produce data; the hardware compatibility list is the authority on this, and the README does not promise universal support. The second limit is the client side. Clients read state and issue commands, but the shutdown decision is a policy you write, not something NUT decides for you. That is deliberate, and it means a NUT install with no shutdown script configured will report a dying battery accurately and do nothing about it. Third, the project is C with a build system that predates most modern toolchains: configure.ac, Makefile.am, m4/, autogen.sh. Building from source on a minimal container image means pulling in a real autotools chain, and the INSTALL.nut.adoc file is the place the project documents that, not the README. If you want a single binary that bundles a web UI and a database, NUT is not that, and the repository has no such component.

How NUT differs from a vendor management agent

The closest alternative most people encounter is the vendor's own monitoring software, and the difference is architectural rather than feature-by-feature. A vendor agent typically bundles the device driver, the state store and the notification logic into one process tied to that vendor's hardware. It is often easier to install and it usually supports exactly one family of devices. NUT inverts that: the driver is swappable, the state store is a network service, and the clients are separate programs. The practical consequence is that a mixed fleet works. A rack with a USB UPS from one brand and an SNMP PDU from another can be monitored by one upsd, and a single client script can poll both with the same variable names. The cost is configuration surface. You maintain the driver and server configuration and the client-side logic yourself, and the project's own documentation is spread across README.adoc, INSTALL.nut.adoc, UPGRADING.adoc and the docs/ tree rather than collected in one place. For a single desktop with a single UPS, that overhead buys little; for anything with more than one device or more than one consumer of the data, it is the reason to choose NUT.

Maintenance, releases and licence status

The repository is not archived, and the last push was on 2026-09-18, days before this writing. Releases are infrequent but real: v2.8.3 and v2.8.4 both landed in August 2025, and v2.8.5 on 2026-04-03. That cadence matters for planning. A distribution shipping v2.7.x is several years of fixes behind, and UPGRADING.adoc exists specifically to document the changes between 2.7.4 and 2.8.x, which tells you the project expects migration pain between those branches. Read it before upgrading a working install. On licensing, the repository carries COPYING, LICENSE-GPL2, LICENSE-GPL3 and LICENSE-DCO at the top level, and the GitHub licence field reports NOASSERTION. That combination means the licence is not a single unambiguous identifier as far as automated detection is concerned, so anyone embedding NUT in a product should read those files directly rather than trusting the repository metadata. The DCO file indicates a contributor sign-off process, which is a governance detail worth noting if you plan to send patches. This is not legal advice; the files are the source.

Editorial conclusion

Adopt NUT when you have a UPS or ePDU that speaks USB, serial, SNMP or Modbus and you want a single daemon that many clients can query over the network; skip it when your hardware vendor already ships a supported management agent and you do not need a shared status endpoint. Before committing, verify that your exact model appears in the hardware compatibility list, check whether your distribution packages v2.8.5 or an older branch, and read UPGRADING.adoc for the changes between 2.7.4 and 2.8.x if you are migrating an existing install.

Frequently asked questions

Official sources

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