Homelab UPS Explained: Sizing, Runtime and Graceful Shutdown With NUT

A homelab UPS should be sized on watts first, then VA, with about 25 percent headroom over the peak load you actually measured, and with enough battery to cover your full shutdown sequence twice over. Pick line-interactive for most homelabs and online double conversion for poor mains or sensitive loads. Then use Network UPS Tools (NUT) so the UPS tells every machine when to shut down, in the right order, before the battery runs out.

The rest of this post goes one level deeper than our tiny data center at home guide and the facility scale view in data center backup power: generators, UPS and batteries. It covers UPS designs, sizing with worked examples, battery chemistry, how NUT works, a full graceful shutdown setup for a NAS, a hypervisor and the nodes of a 3-node homelab Kubernetes cluster, security, surge protection and testing. UPS makers are described by category only, and every NUT setting comes from the NUT man pages and user manual.

Key takeaways

• IEC 62040-3:2021 (edition 3.0, published 21 April 2021) classifies UPS by input dependency: VFD (voltage and frequency dependent, the standby design), VI (voltage independent, the line-interactive design) and VFI (voltage and frequency independent, the online double conversion design). The ENERGY STAR UPS specification uses the same three terms.
• A UPS has two ratings, watts and VA, and you must stay under both. Watts is usually the binding limit. Divide the load in watts by its power factor to get VA, then compare each against the nameplate.
• Runtime is not linear. Lead acid batteries deliver less of their rated capacity at high discharge rates, so a UPS at half load often runs more than twice as long as at full load. Use the maker's runtime chart and then measure.
• Valve regulated lead acid (VRLA) batteries are cheap and simple but wear out in a few years, faster when warm. Lithium iron phosphate (LiFePO4) lasts longer and weighs less but costs more and falls under lithium battery safety standards such as IEC 62619 and UL 1973. IEEE 1188-2025 is the current recommended practice for VRLA maintenance, testing and replacement.
• NUT has three layers: a driver talks to the UPS, upsd serves its data on TCP port 3493 (the IANA registered nut port, documented in RFC 9271), and upsmon decides when to shut down. The machine with the USB or serial cable runs upsmon as primary; every other machine runs it as secondary.
• In a shutdown, secondaries go first. The primary waits up to HOSTSYNC seconds (default 15) for them to disconnect, then shuts itself down and tells the UPS to cut power. Make the storage server the primary so it outlives its clients.
• upsd binds only to 127.0.0.1 (and ::1) unless you add LISTEN lines. Keep it that way on single host setups, restrict it with a firewall when you open it, keep upsd.users at mode 640, and use TLS if your build supports it.
• CISA and the US Department of Energy warned on 29 March 2022 that attackers were reaching internet connected UPS devices through unchanged default credentials. Never expose a UPS network card to the internet.
• Test with upsmon -c fsd and a dummy shutdown command, or with the dummy-ups driver, before you trust a real outage.

Standby, line-interactive and online double conversion: which loads need which?

Every UPS keeps the load running when mains fails, conditions power while mains is present and reports how long the battery will last. The three common designs differ in how much conditioning they do while mains is healthy.

The IEC standard for UPS performance, IEC 62040-3:2021, "Method of specifying the performance and test requirements", groups UPS by how much their output depends on the input. According to the IEC webstore abstract, the standard applies to movable, stationary and fixed electronic UPS, and the 2021 edition shortened the performance classification code from 8 to 7 characters after removing the non-linear step load type test. The ENERGY STAR UPS specification, Version 2.0, effective 1 January 2019, uses the same three input dependency classes and defines them in plain words:

• VFD (voltage and frequency dependent): the output voltage and frequency follow the input. This is the classic standby or "offline" design. On mains, power passes more or less straight through, usually with surge suppression and a filter. When mains fails, a relay transfers the load to the inverter.
• VI (voltage independent): everything VFD does, plus protection against continuous under voltage and over voltage on the input, while the output frequency still follows the input. This is the line-interactive design. An autotransformer with taps boosts low voltage and trims high voltage without touching the battery.
• VFI (voltage and frequency independent): the output voltage and frequency are independent of the input, and the UPS protects the load from input variations without depleting the battery. This is online double conversion. A rectifier turns the input into DC, which feeds the battery bus and an inverter that rebuilds a clean sine wave all the time.

The full IEC code adds characters for output waveform and dynamic performance; for a homelab, the three letter prefix is what matters. NUT reports the same behaviours as status tokens: TRIM and BOOST on line-interactive units, BYPASS ("powered, not protecting") and ECO for high efficiency modes, which the upsmon man page contrasts with permanent double conversion as "safer, but more wasteful and with a toll on battery life".

How to choose for a homelab:

• Short gaps and power supply hold-up. Standby and line-interactive units leave a brief gap during transfer. Most computer power supplies ride through it from their own internal capacitors, but a supply that is heavily loaded, old or marginal can drop out. If you see reboots when the UPS transfers, that is the symptom.
• Output waveform. Many lower cost standby and line-interactive units produce a stepped approximation of a sine wave on battery. Some power supplies with active power factor correction behave badly on that waveform, for example by shutting off or making a buzzing noise. Units described as "pure sine wave" or online units avoid the issue. Check the data sheet rather than assuming.
• Unstable mains or a generator. A line-interactive unit handles swinging voltage. If frequency also wanders, as it can on a small portable generator, only a VFI unit isolates the load; the others may keep switching to battery and drain it.
• Efficiency and heat. Double conversion costs energy all the time, which is why the ENERGY STAR specification sets separate efficiency formulas for VFD, VI and VFI units.

US federal rules apply too: under 10 CFR 430.32(z)(3), UPS manufactured on and after 10 January 2022 with a NEMA 1-15P or 5-15P plug and an AC output must meet a minimum average load adjusted efficiency set by product class and rated output power.

How do you size a UPS: watts vs VA, power factor and runtime

Watts, VA and power factor

A UPS nameplate gives two numbers, for example "1500 VA / 900 W". The VA figure is apparent power, the product of RMS voltage and RMS current. The watt figure is real power, the energy actually consumed. The ENERGY STAR specification defines power factor as the ratio of the absolute value of active power P to apparent power S, so:

• VA = W divided by power factor
• W = VA multiplied by power factor

The UPS has a limit on each. The inverter, wiring and transformer care about current (VA). The battery and the heat sink care about real power (W). You have to stay under both, and for modern IT equipment the watt limit is almost always the one you hit first, because modern power supplies with active power factor correction run at a power factor close to 1. A small UPS rated 1500 VA and 900 W has an implied rated power factor of 0.6, so a 950 W load at a power factor of 0.95 (about 1,000 VA) is comfortably inside the VA rating but over the watt rating. The UPS will report an overload, which NUT surfaces as the OVER status and an OVER notify event.

The rule of thumb that works:

1. Measure each device at the wall with a plug-in power meter, idle and during its heaviest normal work (a scrub, a backup, a build). The power supply's rated wattage tells you nothing.
2. Add the peak values for everything on the battery backed outlets.
3. Add about 25 percent headroom for growth, battery ageing and startup surges (a planning margin, not a standard).
4. Choose a UPS whose watt rating exceeds that figure, confirm VA, then check runtime separately.

Runtime: why it is not a straight line

Runtime is battery energy divided by load, with three corrections:

• Battery energy. Multiply nominal voltage by amp hours. Two 12 V, 9 Ah batteries in series make a 24 V, 9 Ah string, which is 216 Wh nominal.
• Inverter losses. Converting DC back to AC loses energy. For a small unit, planning with 85 percent inverter efficiency is reasonable; the data sheet may give a better figure.
• Rate of discharge. Lead acid capacity is usually rated over a long discharge, often 20 hours. Drained in 10 to 20 minutes, the same battery delivers much less of that rated capacity, and the faster you drain it the less you get. This is why a UPS runtime chart curves sharply: halving the load often more than doubles the runtime. Lithium iron phosphate is much less sensitive to discharge rate.

Start with the maker's runtime chart for your model, then confirm by measurement: most NUT drivers report battery.charge (percent) and battery.runtime (seconds), readable with upsc during a controlled test.

The number that actually matters: your shutdown budget

A homelab UPS is not meant to keep things running through a long outage. Its job is to ride through short blips and, when an outage goes on, to give every machine enough time to shut down cleanly. So the real sizing question is: how long does my whole shutdown sequence take, and does the battery still cover it at the end of the battery's life?

Write the sequence down with times:

1. Kubernetes nodes drain pods and stop (graceful node shutdown period, for example 120 seconds).
2. The hypervisor stops its virtual machines in order (for example 2 minutes for the slowest VM).
3. The NAS stops its services, exports its pools and powers off (for example 60 to 90 seconds).
4. NUT's own delays: FINALDELAY (default 5 seconds) and HOSTSYNC (default 15 seconds) on the primary.

Then set the point at which shutdown starts (the "low battery" trigger, or a timer, both shown later) so that the remaining runtime at that moment is at least twice the sequence length. The factor of two covers battery ageing, cold or hot rooms and estimates that turn out optimistic.

Worked example 1: a NAS, a switch and a mini PC

Measured at the wall over a week (these figures are an illustration; measure your own):

Sizing: 144 W peak multiplied by 1.25 is 180 W. Any line-interactive unit with a watt rating above roughly 200 W covers it. With every device using an active power factor correction supply at about 0.95, the VA is 144 divided by 0.95, about 152 VA, far below the VA rating of any unit that meets the watt requirement.

Runtime: suppose the unit uses one 12 V, 9 Ah VRLA battery, 108 Wh nominal. Plan with 85 percent inverter efficiency and assume that at a 15 to 30 minute discharge rate the battery delivers about 65 percent of its 20 hour rating. Usable energy is 108 multiplied by 0.85 multiplied by 0.65, about 60 Wh. At a typical 90 W working load that is 60 divided by 90, or 0.66 hours, about 40 minutes. At the 144 W peak, assume only 55 percent of rated capacity: 108 multiplied by 0.85 multiplied by 0.55 is about 50 Wh, and 50 divided by 144 is about 21 minutes.

Shutdown budget: the mini PC needs 30 seconds and the NAS 90 seconds, so the sequence takes about 2 minutes plus NUT delays. Double it to 5 minutes. Setting the low battery trigger at 5 minutes of runtime remaining, or starting shutdown after 3 minutes on battery, leaves plenty of margin even on an aged battery. The 2.5 GbE switch keeps running until the UPS cuts power, which is fine; it has no disk to corrupt.

Worked example 2: a three node Kubernetes rack with shared storage

Sizing: 402 W multiplied by 1.25 is about 500 W, so you want a unit rated at 500 W or more. In the common product ranges that usually means a 1000 VA class line-interactive unit or larger.

Runtime: suppose the unit has two 12 V, 9 Ah batteries in series, 216 Wh nominal. At the 197 W working load, usable energy is roughly 216 multiplied by 0.85 multiplied by 0.65, about 119 Wh, so runtime is 119 divided by 197, about 0.6 hours, or 36 minutes. At the 402 W peak with the discharge factor at 0.55, usable energy is about 101 Wh and runtime is 101 divided by 402, about 0.25 hours, or 15 minutes.

Shutdown budget: the nodes need 120 seconds of graceful node shutdown, the NAS needs 90 seconds after its clients disconnect, and you add 20 seconds of NUT delays. That is under 4 minutes. Doubled, 8 minutes. In this rack it is better to start shutting down early on a timer (for example 5 minutes on battery) than to wait for low battery, because by then the nodes might be running a heavy job at peak load and the remaining minutes shrink fast.

Worked example 3: a lithium iron phosphate rack unit

A lithium module rated at a nominal 51.2 V and 20 Ah stores 51.2 multiplied by 20, or 1,024 Wh. With 90 percent inverter efficiency and about 90 percent of capacity usable, that is roughly 830 Wh: about 4.2 hours at the 197 W working load from example 2, or about 2 hours at the 402 W peak. With hours of battery you can ride through short outages and shut down after a set time on battery (say 20 minutes). Long runtime moves the trigger; it does not replace graceful shutdown.

Sizing decision table

What battery chemistries are used: VRLA vs LiFePO4

Valve regulated lead acid

Most small and mid sized UPS ship with valve regulated lead acid (VRLA) batteries, usually the absorbed glass mat type: sealed, cheap, happy to sit at float charge for years and easy to recycle. Their weaknesses are lifespan and heat. Quoted service life is measured at a reference temperature, usually 25 °C, and a battery in a warm closet next to a hot NAS wears out sooner. Homelab UPS batteries are commonly replaced every few years; check your maker's stated service life.

The reference document for maintaining them is IEEE 1188-2025, "IEEE Recommended Practice for Maintenance, Testing, and Replacement of Valve-Regulated Lead-Acid (VRLA) Batteries for Stationary Applications", approved by the IEEE SA Standards Board on 10 December 2025. According to its IEEE abstract, it covers "maintenance, test schedules, and testing procedures" to optimise VRLA life and performance and gives guidance on when batteries should be replaced. The principles carry down to a homelab: inspect, test capacity on a schedule and replace on evidence.

Lithium iron phosphate

Lithium iron phosphate (LiFePO4 or LFP) is the lithium chemistry most used in UPS and home energy storage. Compared with VRLA it typically offers many more charge cycles, a longer calendar life, less weight per watt hour, a flatter discharge voltage and less sensitivity to discharge rate. It costs more up front and needs a battery management system that monitors each cell. Compared with other lithium ion chemistries, LFP is generally regarded as more thermally stable, which is one reason it is common in stationary storage. For how cells and packs are built, see how lithium-ion batteries are made, from mine to cell to pack.

Three standards show up on lithium UPS and battery data sheets:

• IEC 62619:2022 (edition 2.0, published 24 May 2022) specifies requirements and tests for the safe operation of secondary lithium cells and batteries used in industrial applications, including stationary applications.
• UL 1973, "Batteries for Use in Stationary and Motive Auxiliary Power Applications", currently in its third edition according to UL Standards and Engagement.
• NFPA 855, the US "Standard for the Installation of Stationary Energy Storage Systems". It governs installation of larger systems and is adopted through local fire codes. A homelab UPS is usually far below the energy thresholds where it applies, but whole home battery systems may not be. If you are adding a large battery bank, check which edition your local authority has adopted before you buy.

The UPS itself is covered by IEC 62040-1, the safety standard. The consolidated edition 2.1 (IEC 62040-1:2017 plus Amendment 1 of May 2021; check the IEC webstore for later amendments) applies to movable, stationary, fixed or built-in UPS in low voltage distribution systems that deliver fixed frequency AC output, and sets requirements to protect the ordinary person who comes into contact with the equipment. In the US, look for a listing mark from a nationally recognised testing laboratory on anything you plug into house wiring.

How replacement works

A UPS judges its battery with a self test, briefly running on battery under load. A failed test sets the RB status token and the REPLBATT notify event in NUT. According to the upsmon.conf man page, upsmon repeats the REPLBATT notification every 43,200 seconds (12 hours) by default, set by RBWARNTIME.

Some drivers also expose battery.date or battery.mfr.date. Record the install date when you swap batteries; if your UPS lets you set it, upsrw can write it back.

Replacing VRLA batteries safely:

1. Shut down or move the loads; do not rely on the UPS staying up while the battery is disconnected unless the maker documents hot swap for that model.
2. Follow the maker's procedure. Battery terminals in a UPS carry enough current to weld a ring or a wrench; take off rings and watches and use insulated tools.
3. Replace all batteries in a string at once, with the exact type and capacity specified. Mixing old and new cells in series shortens the life of the new ones.
4. Let the new battery charge fully (often several hours) before running a runtime test.
5. Run a self test, confirm the RB flag has cleared with upsc, and recycle the old battery.

How does Network UPS Tools work?

Network UPS Tools is an open source project that supports a very wide range of UPS, PDUs and power devices through a common set of tools. The current release is NUT 2.8.5, announced on the project site on 7 April 2026 (the GitHub release tag is dated 3 April). Its release notes call out improvements to STARTTLS handling and systemd units that now honour the MODE setting in nut.conf. The online man pages track the development branch after 2.8.5, so a few options described there (for example a multi-token form of SHUTDOWNCMD marked as new in 2.8.6) may not exist in your distribution's package yet. When in doubt, check man upsmon.conf on your own system.

The three layers

The NUT user manual describes a layered design:

• Drivers talk to the hardware over USB, serial or the network and translate each protocol into standard NUT variables: usbhid-ups for USB HID power devices, snmp-ups for network cards and many PDUs (SNMP v1, v2c or v3), dummy-ups for simulation or relaying. upsdrvctl or systemd nut-driver units start them.
• The data server, upsd, reads from drivers and answers client queries over TCP. It enforces access control for clients and for privileged actions such as instant commands and setting variables. It listens on port 3493, registered with IANA as the nut service. The NUT network protocol is documented in RFC 9271, "Uninterruptible Power Supply (UPS) Management Protocol: Commands and Responses", an Informational RFC published in August 2022, which includes a STARTTLS command for encrypted sessions.
• Clients connect to upsd. The important one is upsmon, which turns UPS status into shutdown decisions. Others include upsc (read variables), upscmd (send instant commands), upsrw (set variables), upslog (log variables to a file), upssched (timers) and web CGI programs.

Primary and secondary

Each upsmon instance monitors one or more UPS in a role. The upsmon man page says that in general a primary "is one running on the system with the UPS actually plugged into a serial or USB port, and a secondary is drawing power from the UPS but can't talk to it directly."

The roles matter at shutdown time:

• A secondary shuts down as soon as the UPS goes critical, meaning on battery and low battery (OB LB), or when the primary sets the forced shutdown (FSD) flag.
• The primary sets FSD, then waits until every secondary has logged out of upsd or until HOSTSYNC seconds pass (15 by default), then shuts its own system down. It also creates the POWERDOWNFLAG file so that late in the shutdown sequence the operating system tells the UPS to switch its outputs off.

That final power-off is deliberate. The NUT user manual's shutdown design notes explain that the load should be turned off so every attached device is forcibly rebooted and starts in a predictable order when mains returns. Without it, a machine that has shut down while mains comes back mid sequence can sit powered off until someone presses a button.

Status tokens, power values and the decision to shut down

upsmon polls upsd every POLLFREQ seconds (default 5) and every POLLFREQALERT seconds (also 5 by default) while on battery. It reads ups.status, a space separated list of tokens such as OL (on line), OB (on battery), LB (low battery), RB (replace battery), CHRG, DISCHRG, BYPASS, OVER, TRIM, BOOST and FSD.

Each MONITOR line in upsmon.conf assigns the UPS a power value, the number of power supplies in this machine that the UPS feeds (usually 1). MINSUPPLIES (usually 1) is the number that must have power for the machine to keep running. A UPS that is critical (OB and LB) or in FSD stops contributing. When the total drops below MINSUPPLIES, upsmon starts the shutdown. This design lets a server with two power supplies on two UPS survive one UPS failing.

Low battery itself is usually decided by the UPS firmware. If yours waits too long, the ups.conf man page describes ignorelb together with override.battery.charge.low and override.battery.runtime.low, which make the driver declare low battery when charge or runtime falls under your own thresholds. The man page's own example uses 30 percent and 180 seconds, and warns: "Use with caution!" It only works if the UPS reports charge and runtime reliably.

If upsmon cannot reach upsd for longer than DEADTIME (default 15 seconds) and the UPS was last seen on battery, it assumes the worst and treats the UPS as critical. This is why a secondary whose network path to the primary runs through an unprotected switch will shut down during an outage even if the primary has plenty of runtime left.

How to configure graceful shutdown for a NAS, a hypervisor and Kubernetes nodes

This walkthrough uses the rack from worked example 2: a NAS connected to the UPS by USB, a hypervisor running virtual machines, and three Kubernetes nodes. The NAS is the NUT primary because storage must be the last thing to go: if the NAS shuts down first, virtual machines and pods with NFS or iSCSI volumes lose their disks while still running.

Package names below are for Debian and Ubuntu, with configuration in /etc/nut. NAS operating systems often wrap NUT in a web interface; the directives are the same.

Step 1: install NUT and find the UPS

On the NAS (primary):

sudo apt update
sudo apt install nut
# list USB UPS devices that NUT recognises, printed in ups.conf format
sudo nut-scanner -U

nut-scanner -U lists NUT compatible USB devices that are plugged in. Copy the section it prints.

Step 2: define the UPS in ups.conf

# /etc/nut/ups.conf on the NAS
[rackups]
    driver = usbhid-ups
    port = auto
    desc = "Homelab rack UPS"
    # start the driver's low battery logic earlier than the firmware does.
    # only use this if the UPS reports charge and runtime reliably.
    # ignorelb
    # override.battery.charge.low = 40
    # override.battery.runtime.low = 600
    # delay before the UPS cuts its outlets after the kill power command,
    # and before it restores them once mains is back (seconds)
    offdelay = 60
    ondelay = 120

The usbhid-ups man page gives offdelay a default of 20 seconds and says it should usually be lower than ondelay, which keeps the UPS from restoring power before it has actually switched off. Some models round these delays to whole minutes, so the man page recommends at least 60 and 120 seconds on those. Start the driver and check it:

sudo upsdrvctl start
upsc rackups@localhost
upsc rackups@localhost ups.status
upsc rackups@localhost battery.runtime

You should see OL (often with CHRG) and a runtime figure in seconds.

Step 3: set the mode and the listener

# /etc/nut/nut.conf on the NAS
MODE=netserver

netserver starts the driver, upsd and upsmon and allows network clients. The nut.conf man page warns that because this mode is open to the network, "a special care should be applied to security concerns". On a single machine with no clients, use MODE=standalone instead.

# /etc/nut/upsd.conf on the NAS
LISTEN 127.0.0.1 3493
LISTEN 192.168.50.10 3493

Use the NAS's address on the management VLAN, not a wildcard. Without any LISTEN lines, upsd binds only to 127.0.0.1 and ::1.

Step 4: create NUT users

# /etc/nut/upsd.users on the NAS
[upsmon_local]
    password = change-this-long-random-value-1
    upsmon primary

[upsmon_remote]
    password = change-this-long-random-value-2
    upsmon secondary

These users are independent of operating system accounts. The upsd.users man page tells you not to assign actions to upsmon users by hand; the upsmon primary and upsmon secondary lines grant exactly what each role needs. Lock the files down as the NUT security chapter recommends:

sudo chown root:nut /etc/nut/*
sudo chmod 640 /etc/nut/*

Generate the passwords with something like openssl rand -base64 24. If you prefer each client to have its own user so you can see who is connected, create one upsmon secondary section per host.

Step 5: configure upsmon on the NAS (primary)

# /etc/nut/upsmon.conf on the NAS
MONITOR rackups@localhost 1 upsmon_local change-this-long-random-value-1 primary
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POWERDOWNFLAG /etc/killpower
POLLFREQ 5
POLLFREQALERT 5
# wait long enough for every secondary to finish its own shutdown
HOSTSYNC 240
FINALDELAY 5
DEADTIME 15
NOTIFYCMD /usr/sbin/upssched
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+WALL
NOTIFYFLAG COMMBAD SYSLOG+WALL
NOTIFYFLAG NOCOMM SYSLOG+WALL

HOSTSYNC is the important change. The default of 15 seconds is far too short for secondaries that need two minutes to stop virtual machines or pods. The upsmon.conf man page notes that secondaries running heavy workloads can delay logging off until their services are stopped, and that you "may also have to tune HOSTSYNC on the NUT primary to be long enough for those secondaries to stop their services."

Keep SHUTDOWNCMD as one quoted string. That works on every NUT version; the multi-token form is documented as new in 2.8.6. Check the path of upssched on your system with command -v upssched.

Step 6: shut down early with upssched

Waiting for low battery is the default and the simplest option. For racks with several machines, a timer is usually safer, because it gives every machine the same predictable window regardless of load. The NUT user manual's scheduling notes show the pattern: upsmon calls upssched as its NOTIFYCMD, upssched runs timers, and your CMDSCRIPT does the work, ending with upsmon -c fsd to start a coordinated shutdown.

# /etc/nut/upssched.conf on the NAS
CMDSCRIPT /etc/nut/upssched-cmd
PIPEFN /run/nut/upssched.pipe
LOCKFN /run/nut/upssched.lock

AT ONBATT * START-TIMER onbatt_shutdown 300
AT ONLINE * CANCEL-TIMER onbatt_shutdown
AT LOWBATT * EXECUTE onbatt_shutdown

#!/bin/sh
# /etc/nut/upssched-cmd on the NAS
case "$1" in
  onbatt_shutdown)
    logger -t upssched-cmd "On battery for 5 minutes or low battery: starting forced shutdown"
    /sbin/upsmon -c fsd
    ;;
  *)
    logger -t upssched-cmd "Unrecognised command: $1"
    ;;
esac

sudo chmod 750 /etc/nut/upssched-cmd
sudo chown root:nut /etc/nut/upssched-cmd

The PIPEFN and LOCKFN directory must exist and be writable by the NUT user. Check where your package puts its state directory and adjust.

Step 7: configure each secondary

On every hypervisor and Kubernetes node:

sudo apt install nut-client

# /etc/nut/nut.conf on each secondary
MODE=netclient

# /etc/nut/upsmon.conf on each secondary
MONITOR rackups@192.168.50.10 1 upsmon_remote change-this-long-random-value-2 secondary
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
FINALDELAY 5
DEADTIME 25
NOTIFYFLAG ONBATT SYSLOG+WALL
NOTIFYFLAG ONLINE SYSLOG+WALL
NOTIFYFLAG COMMBAD SYSLOG+WALL
NOTIFYFLAG NOCOMM SYSLOG+WALL

Restart the client and confirm it sees the UPS:

sudo systemctl restart nut-monitor
upsc rackups@192.168.50.10 ups.status

On the NAS, upsc -c rackups lists the clients currently logged in to that UPS. You should see one entry per secondary.

Step 8: make the hypervisor stop guests cleanly

When a secondary runs /sbin/shutdown -h +0, the operating system stops its services in order. On a hypervisor, the service that stops virtual machines needs time, and each VM needs to actually respond to a shutdown request. On a Proxmox VE host, for example:

# let the host ask the guest OS to shut down through the QEMU guest agent
qm set 101 --agent enabled=1
# start order 1, wait up to 120 seconds for this VM to stop before moving on
qm set 101 --startup order=1,up=30,down=120

The qm man page describes startup as "Startup and shutdown behavior", where order defines start order and "Shutdown in done with reverse ordering", with up and down delays in seconds. Install the guest agent inside each VM (qemu-guest-agent on Debian family guests) so the shutdown request reaches the guest OS rather than relying on an ACPI power button event. Give the most important VMs (a database, a domain controller) a lower order number so they start first and stop last.

Two things to check on any hypervisor:

1. The host's own shutdown timeout for guests must be longer than the sum of the down delays it will wait through, or it will hard stop VMs.
2. The HOSTSYNC on the NUT primary must be longer than this host's whole shutdown, because upsmon on the host only logs out of upsd when the host actually stops nut-monitor, late in the shutdown.

Step 9: make Kubernetes nodes drain pods on shutdown

Kubernetes has a built-in feature for exactly this. The Kubernetes node shutdown documentation says that on Linux the kubelet uses systemd inhibitor locks to delay the node shutdown for a configured time, and terminates pods in two phases: regular pods first, then critical pods. The feature gate is beta and enabled by default since Kubernetes 1.21, but it does nothing until you configure it, because both settings default to zero.

# kubelet configuration on each node, for example /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
shutdownGracePeriod: 120s
shutdownGracePeriodCriticalPods: 30s

With these values, the node delays shutdown by 120 seconds. The first 90 seconds are for regular pods and the last 30 for critical pods. The kubelet also marks the node NotReady with the reason "node is shutting down", so the scheduler places no new pods on it.

The inhibitor lock duration is capped by systemd-logind's InhibitDelayMaxSec. Raise it to at least the grace period:

# /etc/systemd/logind.conf.d/kubelet-shutdown.conf
[Login]
InhibitDelayMaxSec=150

sudo systemctl restart systemd-logind
sudo systemctl restart kubelet

The Kubernetes documentation also warns that on systems using the default unattended-upgrades configuration, which sets its own logind delay, the kubelet can fail to obtain the lock when shutdownGracePeriod is greater than 30 seconds. Check for /etc/systemd/logind.conf.d/unattended-upgrades-logind-maxdelay.conf; the documentation's suggestion is to make that file a symbolic link to /dev/null.

Give stateful workloads a suitable terminationGracePeriodSeconds, and see the 3-node homelab Kubernetes cluster build for node level detail.

Step 10: let the NAS power off the UPS last

On most current distributions, the NUT package installs a late shutdown hook (a systemd shutdown script) that checks for the POWERDOWNFLAG file and runs upsdrvctl shutdown near the end of the shutdown, after file systems are unmounted or read only. The upsmon man page says you can test for the flag with upsmon -K in scripts. Confirm the hook exists on your NAS operating system; some NAS distributions handle it through their own UPS settings instead.

Warning: the next command cuts power to everything plugged into the UPS outlets. Only run it during a planned test window with every machine on that UPS already shut down or prepared to lose power.

# confirm which UPS you are about to switch off before running anything
upsc rackups@localhost device.model
upsc rackups@localhost ups.status
# planned test only: tell the UPS to cut outlet power after offdelay
sudo upsdrvctl shutdown rackups

Finally, set every machine's firmware to power on when AC power returns ("restore on AC power loss" or similar wording in BIOS settings). Without that, the UPS restores power after ondelay and nothing boots.

Security considerations for UPS network cards and the NUT listener

Anyone who can command your UPS can turn the homelab off or change thresholds so the next outage becomes a crash. Treat the UPS and NUT as part of your management plane.

What CISA and DOE warned about

On 29 March 2022, CISA and the US Department of Energy said they were aware of threat actors gaining access to a variety of internet connected UPS devices, "often through unchanged default usernames and passwords." Their main recommendation was to remove management interfaces from the internet immediately, and the alert pointed to a joint CISA and DOE guidance document with further mitigations.

For a homelab, the practical version:

• Never port forward a UPS network management card, a PDU web interface or upsd to the internet. Reach them over your VPN; see is it safe to self-host apps on the internet for the wider pattern.
• Change default credentials on day one. Network management cards often ship with a well known default administrator account. Change the user name if the card allows it and set a long unique password.
• Disable protocols you do not use. Check which of HTTP, Telnet, FTP and SNMP v1 your card has enabled out of the box. Turn on HTTPS and SSH, and turn off the rest.
• Use SNMP v3 if you poll by SNMP. The snmp-ups driver supports snmp_version=v3 with secLevel, secName and authentication and privacy settings. Its default is v1, which sends a community string in clear text.
• Update card firmware from the maker's own support site only, and check any published hash or signature. Firmware for management cards includes a web server, a TLS library and network stack, all of which receive security fixes.
• Put management interfaces on a separate VLAN with firewall rules that only allow your admin hosts and the NUT server.

Locking down upsd

The NUT security chapter lays out the options in order:

1. Bind address. upsd defaults to 127.0.0.1 and ::1. Add LISTEN lines only for the interfaces that clients use. The manual adds that you "should not rely exclusively on this for security", so combine it with a firewall.
2. Firewall. NUT clients connect to upsd on TCP 3493, and upsd itself never initiates outgoing connections. NUT ships an Uncomplicated Firewall profile; with it installed you can allow only your homelab subnet:

sudo cp nut.ufw.profile /etc/ufw/applications.d/
sudo ufw allow from 192.168.50.0/24 to any app NUT

Or with plain nftables:

sudo nft add rule inet filter input ip saddr 192.168.50.0/24 tcp dport 3493 accept
sudo nft add rule inet filter input tcp dport 3493 drop

3. Users and permissions. Every client authenticates with a user from upsd.users. Only grant actions = set, actions = fsd or instcmds to a separate administrative user you use by hand, never to the upsmon users. Keep /etc/nut/* at root:nut and mode 640, and the state directory where drivers and upsd talk (for example /var/state/ups or /run/nut) at mode 0770. The man page also reminds you to protect backup copies of upsd.users.
4. TLS. SSL/TLS is a build time option in NUT, backed by OpenSSL or NSS, so it depends on how your package was compiled. The manual puts it plainly: with SSL, "stealing port 3493 from upsd will no longer net you interesting passwords." On the server, upsd.conf takes a CERTFILE, and DISABLE_WEAK_SSL restricts sessions to TLS 1.2 or better (it is off by default for compatibility). On clients, upsmon.conf supports FORCESSL 1 to require encryption and CERTVERIFY 1 to verify the server certificate, which the man page says "greatly reduces the risk of man-in-the-middle attacks". From NUT 2.8.5 you can check whether your build has TLS support with upsd -Dh and upsmon -Dh. If your distribution's package lacks it, keep NUT traffic on an isolated management VLAN.
5. Privilege separation. upsmon splits into a small root process that only runs SHUTDOWNCMD and an unprivileged monitor; the man page says disabling that split with -p "is not the recommended mode". If you build from source, the security chapter shows how to verify release tarballs against the maintainers' signing key.

How surge protection, PDUs and power monitoring fit in a homelab rack

A UPS is one layer. A small rack usually has four:

Points worth getting right:

• Do not plug a UPS into a surge strip, or a surge strip into a UPS, unless the UPS maker's manual says it is acceptable. UPS manuals commonly warn against both, because the strip's suppression components can interfere with the UPS and the combination can exceed outlet ratings.
• Battery backed versus surge only outlets. Many small UPS have two banks. Put devices that must shut down cleanly on the battery bank, and things like monitors or a printer on the surge only bank.
• Metered and switched PDUs. A metered PDU shows current per outlet bank, which is the easiest way to measure what your rack really draws. A switched PDU can power cycle a hung device remotely. Treat its management interface like the UPS card above. NUT's snmp-ups driver supports a number of PDU families, so you can graph PDU data next to UPS data.
• Power monitoring. Logging input.voltage, ups.load, battery.runtime and often ups.realpower over time shows brownouts and whether load is creeping toward your sizing limit. Community exporters can feed NUT data into dashboards; treat them like any third party software you run.
• Electrical safety. Anything inside the wall or panel is a job for a licensed electrician working to the electrical code your local authority enforces. Never open a UPS beyond the battery compartment the maker documents; inverters hold dangerous voltages after unplugging. IEC 62040-1 exists precisely to protect ordinary users from UPS hazards, and it assumes you stay on the outside of the case.

How to test a UPS safely and log events

Test in layers

Test the software before the hardware and the hardware before a real outage.

1. Check communication. On every host:

upsc rackups@192.168.50.10 ups.status
upsc rackups@192.168.50.10 battery.charge
upsc rackups@192.168.50.10 battery.runtime

On the NAS, upsc -c rackups should list every secondary.

2. Dry run the shutdown with a dummy command. The upsmon man page suggests setting SHUTDOWNCMD to something that only logs, then triggering a forced shutdown. Temporarily change SHUTDOWNCMD on every host:

# temporary, for a dry run only
SHUTDOWNCMD "/usr/bin/logger -t nut-test would-shutdown-now"

Restart nut-monitor on each host, then on the NAS:

sudo upsmon -c fsd

Watch the logs on every host (journalctl -t nut-test -t upsmon -f). You should see FSD on the secondaries, their dummy shutdown, the SHUTDOWN_HOSTSYNC wait on the primary and finally the primary's dummy shutdown. Time it. The man page warns that afterwards you may need to restart upsd to clear the FSD flag, and check that no POWERDOWNFLAG file such as /etc/killpower is left on the primary. That file left behind would make the UPS switch off at the next ordinary reboot.

sudo systemctl restart nut-server
ls -l /etc/killpower 2>/dev/null && echo "remove this before the next reboot"

Put the real SHUTDOWNCMD back on every host when you are done.

3. Simulate states with dummy-ups. The dummy-ups driver looks like a real UPS to upsd. Since NUT 2.8.0, a data file named with .dev is read once in dummy-once mode and values can then be changed with upsrw; a .seq file loops and can step through states with TIMER lines. This is ideal for testing upssched timers in a lab:

# /etc/nut/ups.conf on a test host
[fakeups]
    driver = dummy-ups
    port = fakeups.dev
    desc = "Simulated UPS for testing"

# /etc/nut/fakeups.dev
ups.status: OL
battery.charge: 100
battery.runtime: 1800

Point a test upsmon (with a dummy SHUTDOWNCMD) at fakeups, then edit the file to ups.status: OB and later OB LB and watch your timers and scripts fire.

4. Run a battery self test. List what your UPS supports, then start a quick test with an administrative NUT user:

upscmd -l rackups@localhost
# example name only: use the exact battery test command that upscmd -l printed
upscmd -u admin rackups@localhost test.battery.start.quick

upscmd -l prints the instant commands your driver offers, and names vary between drivers, so copy the battery test command from that list rather than from this post. Avoid load.off, shutdown.return and similar commands outside a planned test; the upscmd man page calls load.off out as dangerous for a reason.

5. Do one real test per year, carefully. With the dry run proven and backups current, switch off the circuit breaker feeding the UPS (rather than pulling the UPS plug, which also disconnects its ground) and let the real sequence run. Note when each machine shuts down and how much runtime remained. If the UPS maker says not to cut the input at the breaker for your model, follow that instead.

Logging and notifications

• Syslog. Set SYSLOG in NOTIFYFLAG for every event you care about. On systemd hosts, journalctl -u nut-monitor and journalctl -t upsmon show the history.
• Notifications. Set EXEC and a NOTIFYCMD script that sends a message by whatever channel you use. The upsmon man page lists the events, from ONBATT, ONLINE and LOWBATT through REPLBATT, NOCOMM, OVER and BYPASS.
• Time series log. upslog writes UPS variables to a file at a set interval (30 seconds by default). Its default format already includes time, battery.charge, input.voltage, ups.load, ups.status, ups.temperature and input.frequency:

sudo upslog -s rackups@localhost -l /var/log/nut/rackups.log -i 30

• Keep a battery record. Write the install date on the battery with a marker and in your homelab notes. Compare battery.runtime at full charge month by month; a sudden drop is your early warning.

Common mistakes

• Sizing by VA alone. A 1500 VA unit may only deliver 900 W. Check the watt rating against measured peak load.
• Leaving HOSTSYNC at 15 seconds while secondaries need minutes to stop VMs and pods. The primary then cuts power under them.
• Making a client the primary. If a hypervisor holds the USB cable and the NAS is a secondary, the NAS can shut down while VMs still have its volumes mounted.
• Forgetting the switch. If the switch between the primary and secondaries is not on the UPS, secondaries lose contact as soon as mains fails, hit DEADTIME and shut down immediately.
• Leaving /etc/killpower behind after a test, so the next routine reboot also switches off the UPS.
• Kubernetes graceful node shutdown left at zero. The feature is enabled by default but configured off. Set both durations and raise InhibitDelayMaxSec.
• Binding upsd to all interfaces with no firewall, or exposing a UPS network card to the internet, the exact pattern behind the 2022 CISA and DOE warning.
• Never testing the sequence before a real outage.
• Ignoring REPLBATT warnings, or replacing only one battery of a series string.
• Not enabling "restore on AC power loss" in each machine's firmware, so nothing comes back after the outage.

FAQ

What size UPS do I need for a homelab?

Measure the peak power of everything that must stay up, add about 25 percent, and choose a UPS whose watt rating (not just VA) exceeds the result. Then confirm on the maker's runtime chart that the battery covers your shutdown sequence at least twice over.

Is a line-interactive UPS good enough for a NAS?

For most homes, yes. A line-interactive (VI) unit corrects sustained high and low voltage without draining the battery. Prefer a pure sine wave output, and choose online double conversion if you run from a generator or your mains is unstable.

What is the difference between VA and watts on a UPS?

VA is apparent power and watts is real power; watts equals VA multiplied by power factor. Modern IT loads usually hit the watt limit first.

How long will my UPS run?

A rough estimate for lead acid is battery Wh multiplied by about 0.85 for inverter losses and about 0.55 to 0.65 for a short, fast discharge, divided by the load in watts. Confirm with the maker's runtime chart and with battery.runtime from upsc during a planned test.

How often should I replace UPS batteries?

When the self test fails (NUT shows RB and sends REPLBATT), when runtime at full charge drops below what you need, or at the end of the maker's stated service life, whichever comes first. Warm rooms shorten VRLA life.

Is a lithium UPS worth it for a homelab?

If you want long runtime, lower weight or a longer service life, yes, at a higher up front cost. Look for lithium battery safety standards such as IEC 62619 or UL 1973 on the data sheet.

What is the difference between NUT primary and secondary?

The primary runs on the machine connected to the UPS and powers the UPS off at the end. Secondaries read status over the network from the primary's upsd, shut down first, and the primary waits up to HOSTSYNC seconds for them to log out.

Which port does NUT use and is it safe to open it?

TCP 3493, the IANA registered nut port. Open it only to your homelab subnet, bind upsd to an internal address with LISTEN, use strong passwords and TLS where your build supports it, and never forward it from the internet.

Can NUT shut down Proxmox VMs and Kubernetes nodes?

Yes. Run upsmon as a secondary on each host; the host's shutdown stops VMs in order, and the kubelet terminates pods if shutdownGracePeriod and shutdownGracePeriodCriticalPods are set. Make the primary's HOSTSYNC longer than the slowest secondary's shutdown.

How do I test my UPS shutdown without losing power?

Set SHUTDOWNCMD to a command that only logs, run upsmon -c fsd on the primary and watch the logs. Afterwards restart upsd to clear FSD and delete any leftover POWERDOWNFLAG file.

Where Safeguard fits

Safeguard does not monitor UPS hardware, configure NUT, manage UPS network card firmware, measure power or plan battery capacity. Nothing in the sizing, configuration or testing steps above depends on it. The honest connection is the software around the power layer. NUT is open source C software, its client libraries are published for Python, Java and other languages, and homelabs commonly run NUT exporters, dashboards and notification bots as container images next to the services they protect.

For the code and images you build or pull yourself, Safeguard's software composition analysis builds a dependency inventory, container scanning shows which images carry which package versions, and SBOM generation and analysis records the result in SPDX or CycloneDX. The platform shows which projects contain a given component and version, and vulnerability matching and reachability analysis help you decide what to fix first. When an advisory lands for a library inside a monitoring container you run, the question "which of my images still ship that version" has a quick answer.

A rebuilt homelab node pulls container images and dependencies again, and the exporters, dashboards and notification scripts around NUT ship open source components like any other service. Firmware on a UPS network card still has to come from its maker, but the software you build and run around the UPS is yours to keep current, which is where the next section applies.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not UPS monitoring or power management. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container image for a NUT exporter, a power dashboard or a notification bot you run in your homelab, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a dependency in a small notification service or dashboard you wrote to report UPS events.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Network UPS Tools: project home page and news (NUT 2.8.5 release, 7 April 2026)
• Network UPS Tools: GitHub release v2.8.5
• Network UPS Tools: source repository on GitHub
• NUT User Manual: Overview
• NUT User Manual: Configuration notes and shutdown design
• NUT User Manual: Notes on securing NUT
• NUT User Manual: Advanced usage and scheduling notes (upssched)
• NUT man page: upsmon(8)
• NUT man page: upsmon.conf(5)
• NUT man page: upsd(8)
• NUT man page: upsd.conf(5)
• NUT man page: upsd.users(5)
• NUT man page: ups.conf(5)
• NUT man page: nut.conf(5)
• NUT man page: upssched(8)
• NUT man page: upsc(8)
• NUT man page: upscmd(8)
• NUT man page: upslog(8)
• NUT man page: nut-scanner(8)
• NUT man page: usbhid-ups(8)
• NUT man page: snmp-ups(8)
• NUT man page: dummy-ups(8)
• RFC 9271: Uninterruptible Power Supply (UPS) Management Protocol, Commands and Responses (August 2022)
• IANA: Service Name and Transport Protocol Port Number Registry (port 3493, nut)
• IEC 62040-3:2021, Uninterruptible power systems (UPS), Part 3: Method of specifying the performance and test requirements
• IEC 62040-1:2017+AMD1:2021 CSV, Uninterruptible power systems (UPS), Part 1: Safety requirements (preview)
• IEC 62619:2022, Safety requirements for secondary lithium cells and batteries for use in industrial applications
• IEEE 1188-2025: Recommended Practice for Maintenance, Testing, and Replacement of VRLA Batteries for Stationary Applications
• UL Standards and Engagement: UL 1973, Batteries for Use in Stationary and Motive Auxiliary Power Applications
• NFPA 855: Standard for the Installation of Stationary Energy Storage Systems, standard development page
• ENERGY STAR: Uninterruptible Power Supplies
• ENERGY STAR: Uninterruptible Power Supplies Specification Version 2.0
• ENERGY STAR Uninterruptible Power Supplies Final Version 2.0 Specification (PDF)
• eCFR: 10 CFR 430.32, Energy and water conservation standards (UPS efficiency, paragraph (z)(3))
• CISA and DOE: Mitigating Attacks Against Uninterruptable Power Supply Devices (29 March 2022)
• Kubernetes documentation: Node Shutdowns (graceful node shutdown)
• Kubernetes documentation: Kubelet Configuration (v1beta1)
• Proxmox VE documentation: qm(1)

Last reviewed: 23 October 2026. NUT documentation online tracks the development branch after 2.8.5; check the man pages installed on your own system for the options your version supports.