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.
- Rehearse notifications in an isolated test instance first; then approve a real shutdown test for one expendable client. Logging-only notification flags do not disable shutdown.
- 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
The driver reads the UPS, upsd serves its state, and upsmon controls host shutdown. The multi-file excerpt below is incomplete and must not replace working configuration. A complete design also needs a protected primary account and local primary MONITOR entry, secondary MONITOR entries with matching credentials, explicit trusted listen addresses, firewall policy, and the package-supported shutdown/power-down integration. Select the actual UPS driver before enabling anything.
# Incomplete multi-file shape: review each file separately.
# Required primary monitor and shutdown integration are described above.
# 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. - Use a separate test instance with the documented dummy-ups driver and no production clients or physical UPS power-control connection. Rehearse notifications there; do not change production shutdown commands merely to suppress a test.
- For a physical transfer test, follow the exact UPS manufacturer procedure in an approved window with current backups. Do not improvise disconnection, grounding or output-switching steps.
- Watch logs on the NUT server and one client.
- Reconnect power before the first test reaches the low-battery threshold.
- Approve real shutdown testing only after roles, host shutdown commands, protected network paths and reserve timing have been reviewed. Notification success alone is insufficient.
In the approved physical test, verify one noncritical client's complete shutdown and application recovery before expanding scope. Record versions, UPS model/firmware, battery age, load, event timestamps, each shutdown completion and remaining reserve. NUT primary coordination waits for client disconnects or a timeout, not a general application-dependency graph; explicitly verify writer-before-storage order and budget the package/UPS timers for the slowest client.
- 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
Stop an unexpected test and restore stable utility input using the manufacturer procedure. An issued forced-shutdown or output-off request may remain active, so do not restart workloads merely because mains power returns. Check the documented latched-FSD, power-down flag and pending UPS state recovery procedure with local access. Restore the known-good configuration only after the power state is safe, verify status and monitoring, and keep a supervised manual-shutdown fallback while automation is under repair.
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
The acceptance result is an observed shutdown and restart sequence for this UPS, load and host set. Keep the tested timings and recovery procedure with the configuration so a battery, driver or workload change triggers the appropriate retest.


