Homelab hardware, hosting & architecture selection

Ask the question nobody asks first: what are you actually going to run? Before you spec a single component, write down the services you truly plan to host with realistic (not aspirational) resource needs — Plex/Jellyfin, Home Assistant, Nextcloud, a couple of small apps like n8n or Vaultwarden, maybe a Docker host for dev. Most homelabs don't need a 256GB-RAM, 64-core monster; they need 16–32GB of RAM, a CPU with hardware video decode, and disk that fits the media plus backups.

Match the box to the workload category:

• Storage-heavy (media, Nextcloud, photo backup): disk matters more than CPU. Use ZFS or mdadm for redundancy — not as backup, but because rebuild time on a 16TB drive is brutal. An Intel iGPU with QuickSync (or a low-end GPU) cuts transcoding CPU load by ~90%.
• Compute-heavy (occasional ML, encoding, dev): a modern 8–16 core CPU, 32–64GB RAM if you'll run VMs or local LLMs, NVMe for working storage and spinning disk for cold.
• Always-on (Home Assistant, monitoring, reverse proxy): reliability over speed — a small low-power machine that runs 24/7 without complaint, ideally with a hardware watchdog.

For the modal 2026 homelab the boring answer is right: a Beelink/Minisforum N100 or N305 mini PC running Proxmox with USB/SATA-attached storage. It idles at 10–15W, does 4K transcode via QuickSync, runs ten LXCs without breaking a sweat, and costs $250–400.

Sanity check before you buy: sum the realistic CPU/RAM of your top five services, add 50% headroom, and compare to the box. If it's 4x what you need you're overspending; if it's 0.8x you're underspending. The comfortable range is 1.2–2x.

Used enterprise gear (R730, R740, EPYC builds) gets a lot of love on homelab forums, and it's genuinely right — for a specific person. The justifications that hold up:

• You're learning enterprise systems for work.
• You actually need 256GB+ of RAM (local LLMs, big databases, 50+ VMs).
• Power and noise aren't issues — you have a basement and cheap electricity.

The justifications that don't hold up:

• "You never know what you'll need." You mostly do know — that's what the workload list is for.
• "It's only a bit more power." It's 5–10x more power. A rack server pulling 100–200W+ against a mini PC's 10–15W idle adds up to hundreds of dollars a year.
• "More cores are better." Sometimes true for batch jobs; for the modal homelab, no.

An R730 or DL360 is loud, power-hungry, cheap, and capable — a great choice for the right person and a fast path to a noisy, eventually-unused machine for everyone else. For most people the boring mini PC (N100/N305 + Proxmox) wins on power draw, noise, and — most importantly — regret rate six months later. Buy the enterprise tier when a concrete workload demands it, not because the spec sheet is exciting.

The paths most guides push all have a catch: managed GKE/EKS/AKS runs $70–100/month minimum before you deploy anything; single-node Minikube or kind is fine for syntax but teaches you nothing about the distributed parts; a three-Mini-PC homelab is $500+ upfront plus power and noise.

There's a fourth option that's better for most learners: three cheap VPSes running K3s, ~$40/month total. You get real multi-node scheduling, real network partitions when you pull a node, and real failover. You don't get HA-grade capacity — and for learning, that's a feature.

Architecture: one control-plane node (Hetzner CX22, 2 vCPU / 4GB, ~$5/mo) plus two workers (CX22 each) talking over the private network on port 6443; external object storage for stateful workloads (Cloudflare R2 at ~$1–3/mo, or Backblaze B2 at $6/TB) and GitHub Container Registry for images. That's ~$15/mo for the cluster plus a few dollars for storage — round to $20 bare minimum, $40 if you spec up to CX31s (4 vCPU / 8GB).

Why K3s over vanilla kubeadm: a single ~100MB binary control plane (vs 1GB+), bundled Traefik ingress and a local-path storage class. Everything translates directly to full Kubernetes — same kubectl, YAML, RBAC, operators. Setup is about 15 minutes: curl -sfL https://get.k3s.io | sh - on the server, then the same with K3S_URL/K3S_TOKEN on each worker, then copy the kubeconfig to your laptop.

Know the limits: no HA control plane (one server = one SPOF; add two more for ~$10/mo with embedded etcd), a 4GB worker holds maybe 5–8 small pods so favor Go/Rust/Node over Java, keep all nodes in the same region to avoid intra-cluster latency, and no GPU workloads.

The real problem with the Always-Free tier isn't price, it's reliability you don't control. Idle instances get reclaimed, accounts get flagged and put on hold by opaque automated systems, and free-tier capacity isn't guaranteed — and because you're not paying, you have almost no leverage when something goes sideways. That's why the fix isn't "find another free tier" (you'll inherit the same class of problem); it's paying a small, predictable amount for a box that's yours until you say otherwise.

The natural destination is a low-cost dedicated VPS. Hetzner's ARM (CAX) and shared-vCPU instances start in the few-euros-a-month range and map neatly onto an Always-Free ARM box, often with better sustained performance because nothing's being throttled or reclaimed underneath you. DigitalOcean, Vultr, and others work too — the point is a paid instance with a clear SLA instead of a free one with a reclamation clause.

A clean migration:

1. Inventory what's running — services, data directories, environment variables, cron jobs, systemd units. The stuff that bit people on reclamation was always the unbacked-up state.
2. Back up data first — database dumps, volume contents, config files — pulled off the Oracle box and verified to open on another machine before you touch anything.
3. Provision the new VPS near your users, sized to match (an Always-Free ARM box → a small Hetzner CAX).
4. Re-deploy apps — move compose files and remount data if Dockerized; if hand-installed, containerize now so the next move is painless.
5. Restore and cut over — import dumps, point DNS at the new box, confirm, then decommission Oracle.
6. Lock it down — firewall, SSH keys (not passwords), automatic security updates.

Picking hardware or a host is only step one. The recurring second problem is getting a stack of apps onto a fresh server without SSH gymnastics — and it shows up whether the box is a mini PC, a rented Hetzner VPS, or an instance you just migrated off Oracle.

The order that keeps this sane: hardware first (workload-driven), orchestration second (boring), apps third (whatever you actually want to run). Keep the middle layer deliberately dull — one orchestration approach (Proxmox VE for the hypervisor with LXC/Docker for services, or plain Docker Compose on a single box), one storage strategy (a ZFS pool plus an offsite backup), one networking setup (a single VLAN or private network to start). Add complexity only when a real need surfaces.

The friction is rarely the idea — it's wiring up Docker, a reverse proxy, and SSL by hand across several apps and hoping you didn't miss a step. Do that manually and a routine move becomes a lost weekend; the unbacked-up detail you skipped is the one that bites at 2am. A repeatable deploy workflow — templates or a Git-connected pipeline, with the proxy and certificates handled for you — is what turns "boring middle layer" from a slogan into something you actually get.