The Cleanest Three-Node Kubernetes Cluster I'd Buy Today

The easiest low-friction home Kubernetes build: three matching refurbished HP mini PCs, k3s, simple storage, and an honest price comparison.

The easiest low-friction home Kubernetes build: three matching refurbished HP mini PCs, k3s, simple storage, and an honest price comparison.

After tearing down my talos-redux Hetzner cluster, I had a narrower question than “can a home lab beat the cloud?” What is the easiest replacement I can order, install, and recover without turning the monthly bill back on?

The answer is still a stack of used corporate mini PCs. The clean version is three matching machines from one refurbisher, one OS image, and one deliberately small k3s design.

The Resource Target

“Replace the cluster” can mean replacing its always-on baseline or its maximum autoscale ceiling. Those are different purchases. For a bootstrapped project, the baseline is the right target.

old-cluster-shape.txt
1Old Hetzner baseline:
2 control plane: 1 x CPX31
3 static workers: 3 x CPX21
4 autoscale workers: 0-5 x CPX21
5 ingress: 1 x LB11
6 live volumes: 15 volumes / about 260 GB
7
8Baseline capacity:
9 compute: 13 shared vCPU
10 memory: 20 GB RAM
11 local boot disk: 400 GB total
12 network volumes: about 260 GB live
13
14Autoscale ceiling:
15 compute: 28 shared vCPU
16 memory: 40 GB RAM

The checked-in workloads are smaller than the old hardware shape. That is normal: Kubernetes requests are scheduling guarantees, limits are a ceiling, and real usage is usually below both.

The repo requests only a few GiB of memory. That is well below the new stack's 24 GB aggregate, even after leaving room for Kubernetes and the operating system.

repo-workload-shape.txt
1Declared workload shape from the repo:
2 requests: about 2.5 vCPU / 4.75 GiB RAM
3 limits: about 10.45 vCPU / 12.69 GiB RAM
4 declared storage: about 350 Gi in checked-in manifests
5 live storage: about 260 GB before teardown
6
7Replacement target:
8 do not replace the autoscale ceiling first
9 replace the always-on baseline with room for bursty build work
10 make restore boring before making storage clever

That is why a three-node home stack is not heroic. It is not trying to reproduce a production datacenter. It is replacing a small always-on platform with enough headroom to run apps, databases, observability, and occasional build work.

Why Used Micros

“NUC” has become shorthand for small x86 boxes, but Intel-branded NUCs are not the cost floor. Businesses bought Dell, HP, and Lenovo micros in bulk. Now they unload them in bulk.

The sweet spot is an eighth-generation Intel business micro with an i5-8500T, 8 GB RAM, and a 256 GB SSD. Three of them provide enough aggregate capacity without buying expensive memory and storage early.

RAM and storage remain user-upgradeable. A node can grow after measured pressure appears, or be replaced from the used market without becoming a special procurement event.

buying-rules.txt
1Buying rules:
2 buy all three nodes from one multi-quantity listing
3 prefer eBay Refurbished for included accessories, warranty, and free returns
4 power-test every node before the return window closes
5 start with 8 GB RAM and 256 GB SSD per node; upgrade only from measured pressure
6 avoid barebones lots while RAM and SSD prices are elevated
7 avoid N100 nodes for the main cluster
8 avoid new retail mini PCs unless time matters more than cost

My current pick is this multi-quantity HP ProDesk 600 G4 Mini listing on eBay. It has more than ten matching units at an advertised $169.99 each before the current checkout promotions.

The machines include accessories, free returns, and a one-year warranty through the eBay Refurbished program. That protection is worth more than squeezing a few dollars from a barebones lot.

Cheapest Versus Cleanest

The cheapest matching lot I verified is actually a newer HP ProDesk 600 G5 listing at $119 per node. It includes HP power adapters and has enough inventory for all three nodes, but the seller does not accept returns.

cheapest-versus-cleanest.txt
1Lowest verified hardware price:
2 3 x HP ProDesk 600 G5 Mini, i5-8500T, 8 GB RAM, 256 GB SSD
3 node price: $119 each
4 AC adapters: included
5 returns: not accepted
6 delivered stack: about $547 after Seattle tax
7
8Cleanest purchase:
9 3 x Ingram Micro refurbished HP ProDesk 600 G4 Mini
10 node price: $169.99 each before checkout promotions
11 AC adapters: included
12 returns: free for 30 days
13 warranty: one year
14 delivered stack: about $716 after Seattle tax
15
16Convenience and risk premium:
17 about $169 for the complete stack

The G5 lot is the lowest cash price. The Ingram G4 lot is the easiest purchase: matching stock, refurbisher testing, free returns, and a one-year warranty from one seller.

I would pay the roughly $169 stack premium to protect the setup weekend. A dead-on-arrival node should be a return label, not a repair project or an argument about whether the listing was accurate.

When the listing ages out, search for the same HP ProDesk configuration and keep the same rules. Exact 32 GB/1 TB configurations now cost roughly twice as much or more per node. They are no longer the deal.

Bill of Materials

This is the conservative price model as of August 12, 2026. It uses the advertised machine price and treats checkout coupons as upside instead of assuming they apply to all three units.

Seattle sales tax is modeled at the official Q3 2026 rate of 10.55%.

bill-of-materials.txt
1Recommended purchase:
2 3 x HP ProDesk 600 G4 Mini, i5-8500T, 8 GB RAM, 256 GB SSD
3 advertised price: $169.99 each before checkout promotions
4 subtotal: $509.97
5 Seattle tax: $53.81
6 total: $563.78
7
8 1 x APC BN1050M 1050 VA UPS
9 unit: $109.99
10 Seattle tax: $11.60
11 total: $121.59
12
13 1 x TP-Link TL-SG105 5-port gigabit switch
14 unit: $14.99
15 Seattle tax: $1.58
16 total: $16.57
17
18 1 x Cat6 cable 5-pack
19 unit: $12.99
20 Seattle tax: $1.37
21 total: $14.36
22
23Upfront total:
24 pre-tax: $647.94
25 tax: $68.36
26 total: $716.30

The UPS is not optional. This 1050 VA model is cheaper than the smaller units I checked. It provides enough buffer to survive short blinks and shut the cluster down cleanly.

Five gigabit ports cover three nodes, the router uplink, and one spare. The cables are boring Cat6. Rack hardware is excluded because a ventilated shelf works until there is an actual rack.

Supporting links: APC BN1050M UPS, TP-Link TL-SG105 switch, and Cat6 cable pack.

Power and Backups

Seattle changes the math. At California residential rates, home hosting looks more marginal. At Seattle City Light residential rates, the power cost is small enough that hardware amortization dominates the model.

monthly-math.txt
1Seattle power:
2 assumed draw: 85 W for the three-node stack
3 hours/month: 730
4 rate: $0.1338/kWh
5 UPS overhead: 10%
6
7Formula:
8 0.085 kW * 730 h * $0.1338/kWh * 1.10 = $9.13/month
9
10Backblaze B2:
11 old live volume set: 260 GB
12 price: $6.95/TB-month
13 estimate: $1.81/month
14
15Total recurring:
16 power: $9.13/month
17 backup: $1.81/month
18 total: $10.94/month

The power estimate comes from Seattle City Light's residential rate page. The backup estimate uses Backblaze B2 pricing.

The backup model keeps the old 260 GB live volume footprint offsite. If all 350 Gi of declared storage becomes real data, B2 rises from about $1.81 to $2.43 per month. The difference is immaterial.

Effective Cost

The right way to compare this to cloud is not only monthly power. The hardware is paid upfront, so the practical number is effective monthly cost over a horizon.

effective-cost.txt
1Effective cost:
2 12 months: ($716.30 + $10.94 * 12) / 12 = $70.63/month
3 24 months: ($716.30 + $10.94 * 24) / 24 = $40.79/month
4 36 months: ($716.30 + $10.94 * 36) / 36 = $30.84/month
5
6Cloud comparison:
7 old Hetzner rebuild: about $210/month after EUR conversion
8 24-month home stack: about $41/month effective
9 36-month home stack: about $31/month effective

At 24 months, the home stack lands around $41/month effective. At 36 months, it lands around $31/month. That is dramatically cheaper than recreating the old Hetzner shape.

More importantly, it is cheap enough that infrastructure stops becoming a recurring product decision. The cluster can sit there and keep working while the project stays bootstrapped.

What the Purchase Buys

resulting-capacity.txt
1Three-node home stack:
2 nodes: 3
3 CPU class: i5-8500T, 6 hardware threads each
4 aggregate CPU: 18 hardware threads
5 aggregate memory: 24 GB RAM
6 aggregate storage: 768 GB raw local SSD
7
8Compared to old baseline:
9 CPU: 18 hardware threads vs 13 shared vCPU
10 memory: 24 GB vs 20 GB
11 storage: 768 GB local vs 260 GB attached volumes
12 availability: worse than cloud for power/WAN/building failure
13 cost: much lower after the upfront buy

The weak point is not CPU or RAM. It is the failure domain. A cloud region is not the same as one house, router, UPS, ISP, and circuit.

That trade is acceptable because downtime is acceptable. This design optimizes for cost, comprehension, and recovery—not cloud-grade availability.

That changes the Kubernetes storage answer. The simple version is local storage, explicit backups, and a restore path that has actually been tested—not Longhorn on day one.

Distributed storage can come later if restore pain becomes the bottleneck. Until then, it adds more failure modes than value.

operating-model.txt
1Minimal operating model:
2 host OS: Ubuntu Server 26.04 LTS
3 Kubernetes: k3s, all three nodes as server nodes
4 ingress: Cloudflare Tunnel to in-cluster services
5 admin access: Tailscale or WireGuard
6 storage class: local-path first
7 database: one primary Postgres, local SSD, offsite logical backups
8 object storage: R2 or B2 instead of self-hosted MinIO
9 GitOps: keep ArgoCD if it keeps discipline; delete if it becomes ceremony
10
11Deferred:
12 Longhorn
13 Ceph
14 metal load balancer
15 rackmount hardware
16 LTE failover
17 remote hands story

The Clean Setup Path

Use Ubuntu Server 26.04 LTS on all three nodes. It is the current Ubuntu LTS, receives standard security maintenance through May 2031, and avoids maintaining a custom host image.

clean-setup.txt
1Before installing:
2 power-test all three nodes during the return window
3 load BIOS defaults and enable automatic power-on after AC loss
4 install the same Ubuntu Server 26.04 LTS image on every node
5
6Names and network:
7 k3s-01: reserve 192.168.1.41 in the router
8 k3s-02: reserve 192.168.1.42 in the router
9 k3s-03: reserve 192.168.1.43 in the router
10 use wired Ethernet; do not configure Wi-Fi or OS-level static addresses
11
12First pass:
13 patch Ubuntu and reboot
14 install k3s on all three nodes
15 verify node loss and an etcd snapshot
16 add Tailscale, ingress, workloads, and backups in that order
17
18Do not add yet:
19 Longhorn, Ceph, MetalLB, a virtual IP, or a second ingress controller

Reserve addresses in the router instead of hand-writing static network files on each machine. The router remains the source of truth, while every node still gets the stable address etcd expects.

Then follow the official k3s embedded-etcd procedure. The first server initializes the cluster; the other two join it with the server token.

install-k3s.sh
1# Run from a root shell on k3s-01.
2curl -sfL https://get.k3s.io | sh -s - server --cluster-init
3
4# Copy this token securely; do not publish it.
5cat /var/lib/rancher/k3s/server/token
6
7# Run from a root shell on both k3s-02 and k3s-03.
8curl -sfL https://get.k3s.io | K3S_TOKEN="<server-token>" sh -s - server \
9 --server https://192.168.1.41:6443
10
11# Verify from k3s-01.
12k3s kubectl get nodes

Those addresses are examples; substitute reservations from the home LAN. Keep the default k3s components initially. Three server nodes form the odd quorum embedded etcd needs.

K3s requires unique hostnames and SSD-backed storage, both covered by this build. Its current requirements also support modern Ubuntu and recommend leaving UFW inactive unless the required cluster rules are added.

The relevant references are the k3s requirements and the Ubuntu release lifecycle.

Single-Node Option

There is an even cheaper answer if the goal is only to get the apps back online: buy one mini PC, the UPS, and cables. That is about $324 after Seattle tax and about $5.57/month for power plus B2 before checkout deals.

Over 24 months, the single-node option costs about $19.07/month effective. It is the right answer when the goal is merely to host the apps again.

I would still buy three nodes to replace the old cluster shape. They preserve the habits of scheduling, draining, upgrading, and losing a node without making every operation a full outage.

One node is the cheapest app host. Three nodes are the cheapest useful cluster.

Decision

Buy three matching Ingram-refurbished HP micros, put them on a UPS, and run the same Ubuntu image on each. Use k3s for Kubernetes, Cloudflare Tunnel for ingress, and Tailscale for admin access.

Skip new NUCs, rack hardware, distributed storage, LTE failover, and colocation. Add one only when it solves a problem that has actually appeared.

The old cluster was a useful platform when the bill was tolerable. After the price change and teardown, recreating it in cloud is mostly paying for continuity of shape. The home stack keeps the useful part: enough compute to keep building.