One UPS, Many Devices: NUT Shutdown for Proxmox, NAS, Router, and Docker Hosts
The short answer: connect one stable, low-power host to the Uninterruptible Power Supply (UPS) by Universal Serial Bus (USB) or Simple Network Management Protocol (SNMP), run Network UPS Tools (NUT) there as the server, and let trusted clients monitor it over the local network. Shut down application writers before shared storage, guests before hypervisors, and keep the router, switch, and NUT server powered until the messages have arrived.
Network UPS Tools (NUT) is the classic open-source way to do this. One machine talks to the UPS over Universal Serial Bus (USB) or Simple Network Management Protocol (SNMP), and the other systems monitor that NUT server over the local area network (LAN) so they can react when the UPS goes on battery or reaches a low threshold.
The Short Version
- Protect the NUT server and network path with the same UPS as the clients that depend on them.
- Size the plan around measured load, battery condition, and shutdown duration, not the runtime printed on a product page.
- Use notification-only tests before enabling automatic shutdown, then validate one expendable client at a time.
- Keep databases and storage mounted until their writers stop; halt the NAS before the remaining battery reserve becomes uncertain.
- Document what happens when the NUT server, switch, UPS data cable, or battery fails, not only when utility power fails cleanly.
Design principle: Treat UPS shutdown like a dependency graph. The network and NUT server must stay up until every protected client knows what to do.
The Decision
Use a networked NUT design when several machines share one UPS and can receive shutdown events reliably. A direct USB connection to every host is impossible because the UPS normally exposes one data connection. A manufacturer network-management card can fill the server role for some equipment, but check protocol and client compatibility before buying it. For one host, a local standalone NUT configuration may be simpler and removes the network dependency.
| Role | Example | Shutdown Priority |
|---|---|---|
| NUT server | Mini personal computer (PC), NAS, or always-on host connected to UPS | Stays up until clients receive events. |
| Docker host | App server with databases or media apps | Stops write-heavy containers early. |
| NAS | Shared storage or backup target | Shuts down after clients stop writing. |
| Proxmox | VM and LXC hosts | Shuts down guests before halting the host. |
| Router and switch | Core network path | Stays powered as long as possible. |
Map Power and Dependencies First
List every outlet and device attached to the UPS, then measure the steady load from the UPS display, management interface, or another appropriate meter. Record the UPS watt and volt-ampere limits, battery age, replace-battery state, and observed runtime under normal load. Leave headroom for startup behavior and battery aging. Do not connect laser printers, heaters, or other high-draw equipment unless the UPS manufacturer explicitly supports that use.
Next draw the service dependency graph. A database may write to NAS storage; a Docker host may mount that share; a Proxmox guest may provide DNS; and every NUT client may need the same switch. The shutdown sequence must avoid circular dependencies. Keep essential local DNS available or configure clients with a stable NUT server address that still resolves during a WAN outage.
Reference Configuration Shape
On the USB-connected server, NUT runs in netserver mode. The UPS driver reads battery status, upsd exposes a monitoring endpoint to trusted LAN clients, and upsmon on each client decides when to start a shutdown. Bind the service carefully, use a low-privilege monitor account, and do not expose NUT to untrusted networks.
# nut.conf
MODE=netserver
# ups.conf
[homelab-ups]
driver = usbhid-ups
port = auto
desc = "Homelab UPS"
# upsd.users
[monuser]
password = long-random-password
upsmon secondary
Current NUT documentation uses primary and secondary monitor roles; older examples may use master and slave terminology. Configure each client with the matching monitor role and protect the credential file with operating-system permissions. Bind upsd only to the required trusted interface, restrict it with host firewall rules, and do not route the service from guest or internet-facing networks.
Do not copy the sample blindly. Confirm the exact driver in the NUT hardware compatibility list and inspect upsc output for the variables the UPS actually reports. A UPS may expose charge, runtime, load, and low-battery status differently. Build shutdown policy from reliable state transitions and tested timers, not one optimistic runtime estimate.
Proxmox and Docker Details
- Enable QEMU guest agents where appropriate so guests shut down cleanly.
- Set VM and container shutdown ordering for dependencies such as databases and storage clients.
- Use Docker Compose stop grace periods for databases and media applications.
- Keep the NUT server and core switch on protected power.
- Confirm shutdown commands work before waiting for an outage.
For Proxmox, guest-agent availability does not replace guest-specific shutdown behavior. Confirm each virtual machine (VM) and Linux Container (LXC) responds within its configured timeout, and decide what happens when one guest refuses. A forced stop can protect the host from battery exhaustion while still risking application data, so set that tradeoff explicitly.
For Docker, stop front ends and workers before databases when dependencies require it. Compose startup ordering is not a complete shutdown orchestrator, so verify actual stop signals and grace periods. A container marked stopped does not prove its database flushed correctly; inspect application and database logs and run the application's own recovery check after restart.
Validation and Evidence
- Confirm
upsc homelab-ups@nut-serverreturns status from a client. - Set conservative notify-only behavior first.
- Unplug the UPS from wall power during a maintenance window; do not pull power from the server.
- Watch logs on the NUT server and one client.
- Reconnect power before the first test reaches the low-battery threshold.
- Enable full shutdown only after notification and monitoring are proven.
Repeat the test with one noncritical client allowed to shut down, then verify a clean reboot and application recovery. Expand to application hosts, storage, and the hypervisor only after the prior stage passes. Record NUT and operating-system versions, UPS model and firmware, battery age, measured watts, reported charge and runtime, event timestamps, notification receipt, each shutdown start and completion time, remaining battery state, and restart checks.
- Clients detect on-battery and utility-restored events through the protected network path.
- The notification-only test does not trigger an unexpected shutdown.
- Application writers stop before shared storage and storage unmounts cleanly.
- Guests stop within the hypervisor's planned reserve and the host halts before the battery is exhausted.
- The router and switch remain available until all network-dependent clients have acted.
- After utility power returns, filesystems, databases, containers, VMs, backups, and monitoring recover without unexplained errors.
This article is documentation-backed; TechGeeks did not connect a named UPS or perform an outage test for this revision. A successful upsc query does not prove that shutdown triggers, credentials, timers, guest order, or low-battery behavior work. One short transfer-to-battery test does not prove battery runtime, battery health, surge protection, graceful database recovery, or behavior during a long outage.
Failure Modes and Troubleshooting
- Client cannot query NUT: verify the server locally, then check name resolution, bind addresses, firewall policy, credentials, monitor role, and clock before changing shutdown thresholds.
- UPS status is stale: inspect the driver and USB or SNMP path. Treat lost communication differently from a confirmed low-battery event so a cable fault does not silently defeat protection.
- Some hosts shut down too early: compare their monitor and timer policy, and confirm that the network and shared storage remain present for hosts still running.
- A guest or container hangs: collect its stop logs, adjust application-specific grace periods, and decide the last-resort forced-stop boundary before the next test.
- Systems restart while utility power is unstable: review firmware restore-on-power settings, minimum battery charge before startup, and whether automated startup should wait for stable input.
Security, Privacy, Legal, and Recovery Boundaries
- Security: restrict NUT network access and credentials, use least-privilege monitor roles, protect UPS management, and keep shutdown commands unavailable to untrusted networks.
- Privacy: power and event logs can reveal occupancy, outages, equipment, hostnames, and operating schedules. Limit access, exports, and retention.
- Legal and safety: follow UPS electrical ratings, manufacturer instructions, battery handling and disposal rules, lease or workplace policy, and local electrical and fire requirements. Do not open mains-powered equipment or improvise unsupported power connections.
- Recovery: back up NUT and host configuration, keep local console access, document how to disable automatic actions, retain known-good thresholds, and confirm manual shutdown remains possible if the NUT server fails.
Rollback Plan
If any staged test behaves unexpectedly, reconnect utility power, stop before the low-battery threshold, disable automatic shutdown actions, and return clients to notification-only monitoring. Restore the previous NUT files, restart the driver, server, and monitor in dependency order, and verify local status plus one remote query. Do not remove the UPS from service during rollback unless the electrical or battery state itself is unsafe.
Useful Gear and Buyer Notes
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
| Need | Good Choice | Why It Fits | Affiliate Link |
|---|---|---|---|
| UPS with USB | APC, CyberPower, or Eaton line-interactive UPS | NUT support starts with a UPS the server can read reliably. | Amazon: CyberPower CP1500PFCLCD Amazon: APC BR1500MS2 |
| NUT coordinator | Always-on mini PC or supported NAS | The NUT server should be boring and power efficient. | Amazon: Intel N100/N305 mini PCs |
| Core switch battery | Power over Ethernet (PoE) or managed switch on UPS | Clients need network reachability during shutdown. | Amazon: TP-Link TL-SG2008P PoE switch Amazon: UniFi PoE switch |
| Replacement battery | UPS battery cartridge | A shutdown system needs a healthy battery behind it. | Amazon: UPS replacement battery |
| Short cords | Short International Electrotechnical Commission (IEC) or National Electrical Manufacturers Association (NEMA) power cords | Makes it obvious which devices are protected. | Amazon: short power cord pack |
Common Mistakes
- Connecting the UPS USB cable to a machine that shuts down first.
- Putting the switch outside the UPS path.
- Letting every client decide independently with no shared order.
- Testing only by reading a status page.
- Using the same aggressive timeout for databases and stateless apps.
Related TechGeeks
- What Should Happen to Your Homelab During a Power Outage? covers the wider outage runbook.
- UPS Buying Guide for Home Servers covers capacity, battery, and load decisions.
- Document a Homelab So Someone Else Can Recover It turns the shutdown order into a usable handoff.
- Homelab Monitoring Basics expands alerting and recovery checks.
References
- NUT User Manual
- NUT Configuration File
- NUT Monitor Configuration
- Proxmox QEMU Guest Agent
- Docker Stop Command
- Docker Compose Startup and Shutdown Order
Final Thought
Once NUT is working, a UPS becomes infrastructure instead of just a battery box. The outage path is known, the order is intentional, and the lab can fail cleanly instead of improvising in the dark.
Need help applying this?
Bring TechGeeks into the real environment.
If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.


