How to Plan a Quiet, Low-Power Always-On VPN Server

Idle is where a home VPN box spends almost all of its life, so idle is the state worth measuring. The same machine still has to answer a connection, serve a file and finish a backup while the tunnel is up, and those three jobs pull in different directions. Quiet, low-power and always-reachable are separate properties, and a spec sheet describes none of them. Working through the checks below in order keeps a hardware decision from turning into a rebuild six months later.

Start With the Roles, Not the Parts

Write down every job the box must do while nobody is watching. A WireGuard or OpenVPN gateway, a file share, a backup target and an indexing job have different steady-state costs, and one machine doing all four has a much higher floor than one doing the first. Idle draw is the sum of those floors rather than an average of them. That is why two boxes both described as low-power can differ by a factor of three in the same room.

Deciding early whether the data lives on the same host as the tunnel constrains everything else. Separate hosts mean two idle draws but a gateway that stays awake while storage sleeps; one host means a single draw and a single failure domain. Neither is wrong, yet the answer has to be written down before the parts list exists.

Measure the Whole Box in Three States

A wall meter between the socket and the power supply is the only honest instrument here, because it includes conversion losses, drive spin-up and every USB device you forgot about. Record three numbers: idle with the tunnel up and nothing else running, the same box under a real remote transfer, and the box during a scheduled backup.

Software counters help explain the wall reading but do not replace it. The RAPL interface reports package and memory-domain energy, which excludes power-supply losses and anything attached over USB.

read -r a < /sys/class/powercap/intel-rapl:0/energy_uj; sleep 60; read -r b < /sys/class/powercap/intel-rapl:0/energy_uj
awk -v a="$a" -v b="$b" 'BEGIN{printf "package average: %.1f W\n", (b-a)/60/1000000}'

Noise needs the same treatment. A fanless case removes one source and leaves the hard drive, the power supply and coil whine, so listen during a backup rather than at the login prompt. Temperature belongs in the same pass: read the sensors under sustained load, and never disable thermal protection to make a box quieter.

Turn Watts Into a Year You Can Compare

Continuous draw converts to energy with one multiplication, and doing it once stops the annual cost from being a surprise. An illustrative 11 W average over a full year works out as follows.

awk 'BEGIN{printf "%.1f kWh/year at 11 W\n", 11*24*365/1000}'

That figure is arithmetic, not a measurement of your box, and the tariff you multiply it by moves the answer more than a couple of watts do. What the calculation is good for is comparing two designs: a gateway idling at 6 W against one idling at 15 W is a decision you can price. A processor's rated wattage is not that number, because it describes a package under load rather than a system at rest. Use the wall-meter average with the local tariff, and label the result as an estimate.

Decide Whether Sleep Is Allowed

Sleep saves the most energy and breaks the most assumptions. A sleeping host cannot accept the inbound connection that would wake it, and a client keepalive does not change that; only an always-on device on the same LAN can send a wake-on-LAN packet.

If the tunnel has to be reachable at any hour, treat sleep as disabled by policy and write that into the build notes. Masking the targets is blunt, but it is explicit and survives package upgrades better than a habit does.

systemctl status sleep.target suspend.target
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
systemd-inhibit --list

Wake-on-LAN deserves its own line in those notes because it fails quietly. The feature has to be enabled in firmware, works on only some interfaces, and needs a device that is already awake to send the packet. Test it before you depend on it, not after a trip.

Prove It Under the Workload It Will Actually See

The last check is the one people skip: run the intended workload and watch the box for an hour. A remote transfer, a backup and an index rebuild at the same time will show whether the cooling, the link and the storage can carry the role combination you chose.

uptime
sensors | grep -E 'Core|Package|fan'
ss -s

Watch the access link in the same window, since upstream bandwidth usually limits remote throughput long before the processor does. If the tunnel saturates at a fraction of what the CPU could encrypt, a faster chip buys nothing at all.