What a home server actually costs to run

Self-hosting is usually presented as free once you own the hardware. It is not. It has an electricity bill, a disk replacement schedule, a domain renewal, an off-site storage line and a machine that has to be bought again in five years. Here is all of it, with the arithmetic exposed so you can substitute your own numbers.

The formula#

annual_kwh    = idle_watts * 8760 / 1000
annual_cost   = annual_kwh * price_per_kwh
five_year_cost = annual_cost * 5

Every price below uses 18.34 cents per kWh, the US average residential rate for June 2026 published by the EIA. In most of Europe you are paying 0.28 to 0.35 EUR, so double the electricity lines. Check your own bill; this is the one input where regional variation swamps everything else.

A one-liner for your own machine, once you have a reading from a plug-in meter:

W=28; P=0.1834
echo "$W W -> $(echo "$W*8.76" | bc) kWh/yr -> \$$(echo "$W*8.76*$P" | bc) /yr"

Idle watts is the only power number that matters#

A home server is idle for something like 95 percent of the wall clock. Peak draw during a transcode or a backup run is real but brief, and it is dwarfed by the 8600 hours a year the machine spends doing nothing. Optimize idle; ignore TDP.

The 8 W versus 60 W row pair is the whole argument for caring. Over five years that is 64 USD against 482 USD, a difference of 418 USD, which is more than the price gap between the two machines that produce those figures. This is why Mini PC vs NAS vs used enterprise lands where it does on used enterprise gear.

The worked example#

A four-person household. One i5-12400 build with 32 GB, a 1 TB NVMe drive for the operating system and container data, and two 14 TB drives in a mirror for media and photos. It runs Jellyfin, Immich, Vaultwarden, Paperless-ngx, Actual Budget, Home Assistant and a reverse proxy. Measured idle: 28 W.

That is 31 USD a month, and it is the honest number. It excludes your time, which is the largest cost and the one nobody prices.

Note what is not in the off-site line: the media library. Backing up 12 TB of films you could re-acquire at 6.95 USD per TB per month is 1001 USD a year and it is the single most common way people make self-hosting expensive. Back up what is irreplaceable. Backup planner separates the two piles for you, and Backups that actually restore covers the restore side, which is the part that decides whether any of this spending was useful.

What you are actually replacing#

Against that 374 USD, the subscriptions a household of four might drop:

So a four-service household is roughly 68 USD a year ahead, before counting the unpaid administration. That is a thin margin, and you should see it as thin. Anyone telling you self-hosting saves a fortune on a stack like this is not showing you the electricity line or the disk replacement line.

Where it does pay, clearly#

Two situations flip the arithmetic decisively.

Storage volume. Cloud storage is priced per terabyte per month, forever. Google One's published tiers stop at 5 TB for 19.99 USD a month, which is 239.88 USD a year for 5 TB. Your disks are priced once. A pair of 20 TB drives is around 600 USD and covers you for five years at roughly 120 USD a year including their share of the power. Above about 3 TB of data you cannot delete, the self-hosted side wins and keeps winning as the number grows.

Service count. Each additional service you move costs you close to zero marginal electricity, because the machine is already on and the median tool in the index idles at 150 MB. The tenth service is nearly free; the first one costs you a whole server.

Where it does not pay#

If you are one person replacing one 3 USD a month service, the answer is no, and no amount of enthusiasm changes it. That subscription is 36 USD a year. The cheapest credible always-on machine costs 13 USD a year to power and about 200 USD to buy, which is 53 USD a year over five years before the domain, before the backup target, before the disk. You will spend more money and considerably more time.

The same is true for anything where the value is in the network rather than the software: a shared calendar with people who use Google, a family chat where the other family members will not install a client, a service you touch twice a year. When not to self-host is the longer version of this argument.

The correct reasons to self-host that one service are control, privacy, and not being subject to a pricing change or a feature retirement. Plex Media Server is the standing example: remote playback of your own files now requires that somebody in the transaction is paying, which is exactly the kind of change you cannot be exposed to on hardware you own. Those are good reasons. They are just not financial ones, and the pages that pretend otherwise are doing you a disservice.

Spin-down, and why ZFS fights it#

A 3.5 inch drive draws roughly 3 to 5 W at idle with the platters spinning and well under 1 W in standby. Four drives asleep is about 15 W, or 24 USD a year. Worth having on an archive; not worth breaking anything for.

# 20 x 5 seconds = 100 seconds of inactivity before standby
sudo hdparm -S 20 /dev/sda
# check whether it is actually asleep, without waking it
sudo hdparm -C /dev/sda

The catch is that spin-up costs 5 to 10 seconds of latency and each cycle increments the head load/unload counter. Watch SMART attribute 193 (Load_Cycle_Count); some drives are rated in the hundreds of thousands of cycles, and an aggressive timer plus a chatty filesystem can burn through that in a couple of years. A monitoring agent polling disks every ten seconds will also happily wake them forever, so check what Netdata or Beszel is doing before you blame the filesystem.

ZFS is the specific problem. Any write to the pool wakes every disk in the vdev, and ZFS writes more often than people expect: transaction group commits, access-time updates, metadata. The practical consequences:

• Set atime=off (or relatime=on) on datasets you want to sleep. Access-time updates alone will keep a pool awake under any read workload.
• Never put container data, databases or logs on the spinning pool. Put them on the NVMe drive. A single container writing a log line every thirty seconds pins six disks at 4 W each, permanently, which is 38 USD a year to record nothing.
• Scrubs wake everything by design and should. Schedule them monthly, not weekly, on a home pool.

The layout decision that makes spin-down possible is made when you create the pool, not afterwards, which is one more reason to read ZFS, btrfs, mdadm or one disk before you commit.

The replacement cycle#

Assume five years for the machine and five to six for the disks. Do not assume disks fail on a schedule: Backblaze's Q1 2026 Drive Stats reported a 1.24 percent annualized failure rate across a fleet of 341,263 drives, with 1.36 percent for calendar 2025. Across six drives that is roughly one failure every three years on average, and averages do not protect you from two in one month.

Budget for it as a line item rather than an emergency, keep one cold spare on a shelf if your array cannot survive a second failure during a rebuild, and make sure SMART alerts actually reach you. A disk failing silently for six weeks is how a mirror becomes a single disk without anybody noticing.

What to do next#

Buy a 15 USD plug-in power meter and measure the machine you already own before you optimize anything; every figure on this page is worthless next to your actual reading. Then size the off-site pile with Backup planner, size the machine with Stack planner, and if the total looks worse than the subscriptions, read When not to self-host before you buy hardware.