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.
| 1 | Old 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 | |
| 8 | Baseline 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 | |
| 14 | Autoscale 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.
| 1 | Declared 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 | |
| 7 | Replacement 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.
| 1 | Buying 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.
| 1 | Lowest 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 | |
| 8 | Cleanest 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 | |
| 16 | Convenience 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%.
| 1 | Recommended 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 | |
| 23 | Upfront 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.
| 1 | Seattle 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 | |
| 7 | Formula: |
| 8 | 0.085 kW * 730 h * $0.1338/kWh * 1.10 = $9.13/month |
| 9 | |
| 10 | Backblaze B2: |
| 11 | old live volume set: 260 GB |
| 12 | price: $6.95/TB-month |
| 13 | estimate: $1.81/month |
| 14 | |
| 15 | Total 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.
| 1 | Effective 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 | |
| 6 | Cloud 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
| 1 | Three-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 | |
| 8 | Compared 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.
| 1 | Minimal 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 | |
| 11 | Deferred: |
| 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.
| 1 | Before 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 | |
| 6 | Names 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 | |
| 12 | First 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 | |
| 18 | Do 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.
| 1 | # Run from a root shell on k3s-01. |
| 2 | curl -sfL https://get.k3s.io | sh -s - server --cluster-init |
| 3 | |
| 4 | # Copy this token securely; do not publish it. |
| 5 | cat /var/lib/rancher/k3s/server/token |
| 6 | |
| 7 | # Run from a root shell on both k3s-02 and k3s-03. |
| 8 | curl -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. |
| 12 | k3s 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.
