How I built a homelab from parts I already had lying around

There’s a specific kind of guilt that only hardware you already own can inflict on you. Mine came in the form of four Raspberry Pis I bought in 2022 to “learn Kubernetes on Pi,” which lasted exactly one weekend before they went into a drawer. Every time I’d open that drawer for a screwdriver, they’d look at me. For three years.

This is the story of how I stopped ignoring them and built an actual homelab — the parts I already had, the parts I finally picked up cheap, and every “why” behind the choices. If you’re staring at some old hardware wondering whether it’s enough to start with: yes it is, and this post is for you.

What was lying around

The full parts list, and roughly where each piece came from:

Piece	Detail	Origin
2× mini PC	i5-6th-gen, 16GB RAM, 256GB HDD	Corporate refurb lot — cheap, boring, dependable
3× Raspberry Pi 4B 2GB	Bought “for learning” and forgot about	Sunk cost from the abandoned project
1× Raspberry Pi 4B 8GB	For the “one big Pi” tier	Added later when I had a real plan
1× NAS	4-bay, saved for it	Only piece I splurged on
Networking	Managed switch + USG-shape router	Picked up over time

Three quick notes:

• Refurbed office mini PCs are homelab gold. These aren’t blazing fast — 6th-gen i5s were released in 2015 — but they’re roughly a 4-core CPU with lots of RAM headroom for less than a decent night out. Companies refresh their fleets every 3–5 years and dump perfectly good machines onto the refurb market. If you’re waiting for the “perfect” homelab hardware, don’t. Buy the boring refurb.
• The Pis were sunk cost when I started. An embarrassing pile of unused Pi is a specific hobbyist shame. This project mostly exists so I stop feeling bad about them.
• The NAS is the most important single piece and it earns it. More on that in a bit.

Nothing here was bought in one shot. It’s just what happens when you keep buying small things over a few years.

What I wanted the homelab to actually do

A homelab is not a goal. It’s infrastructure for goals. Mine:

1. DNS I control. I wanted an ad-blocking DNS server the whole house uses, and I wanted it redundant so my partner never once notices when I’m tinkering with it.
2. Self-hosted media server. I have a movie library. I want it available on any TV in the house without paying anyone monthly.
3. Home automation with a service that isn’t going to get shut down or acquired.
4. Backups I actually trust. Not “cloud provider I’m crossing my fingers about” backups. Backups I could verify.
5. A place to run experiments without breaking anything real.
6. Metrics on all of it, because if I can’t see what’s going on, I can’t fix it.

Every workload in this homelab exists to serve one of those six goals. If a machine can’t answer “which goal does this belong to?”, it doesn’t run.

Why Proxmox?

This was the first real decision. I had two mini PCs. What should they run?

The options I considered:

• Just Docker on Debian. The tempting one. “Why do I need VMs at all? Docker isolates enough.” True until you want to run two workloads that both want port 443, or a workload that needs its own kernel version, or you want to blow away one project without touching another. Also true until you break Docker’s networking and can’t SSH into the box any more (ask me how I know).
• TrueNAS SCALE. Nice UI, integrates with ZFS. But it’s opinionated toward being primarily a NAS with apps on the side, and I already had a real NAS. Would have paid a full mini-PC’s worth of RAM for the OS itself.
• Unraid. Paid. I have nothing against paying, but I wasn’t going to pay to learn on my own hardware.
• Bare Debian + KVM by hand. I know some people love this. I’m not one of them. Managing a fleet of VMs via virsh at 11pm is not why I got into this.
• Proxmox VE. Debian underneath, KVM for VMs, a web UI I can actually navigate, a proper CLI (qm, pct, pvesm) I can drive from Ansible, free for personal use.

Proxmox won. Not because it’s the most powerful — because it’s the most learnable. Every layer of it is a real, googleable thing: it’s just Debian, and KVM, and LVM, wearing a web UI. When something breaks, I’m debugging Linux, not “the Proxmox way to do things.”

Why Debian for the VMs?

Once Proxmox is running, every VM on top is some Linux. Which one?

• Ubuntu Server LTS. The default choice. But Canonical keeps making questionable moves (snap-by-default, snap for docker, the pro-tier upsell messages in apt), and every LTS release brings some new surprise. I got tired.
• Alpine. Small, fast, secure. Also weird enough (musl libc, apk instead of apt) that half the tutorials I want to follow don’t work out of the box.
• Fedora / CentOS Stream. Great tech. Wrong culture fit for a homelab — they move too fast on package versions for a system I want to touch once a month.
• Debian. Boring in the best sense. apt, systemd, packages that don’t randomly change behavior between releases, and security updates that keep coming for years past release via the Debian LTS project. It’s what Proxmox already runs.

Debian across the fleet also means one set of muscle memory. I don’t have to remember which host uses which package manager, which init system, which network config file — it’s the same everywhere.

Why Ansible?

Once I had two Proxmox hosts and a plan to run ~10 VMs on top, the question was: how do I not lose my mind?

• Shell scripts. Fine for one host. By host three, you’re maintaining a small library of .sh files, all with slightly different assumptions, none of which are idempotent. Ask me how I know.
• Cloud-init only. Great for first boot. Nothing for the second week, when you realize you forgot to set up a log rotation policy.
• Puppet / Chef. Agent-based. I’d have to install and run software on every host just to run other software on every host. No thank you.
• Nix / NixOS. Very cool. Very powerful. Genuinely reproducible. Also a completely new mental model and configuration language I’d have to learn on top of everything else I was already learning. Maybe someday.
• Ansible. SSH in, run some YAML tasks, SSH out. No agent on the target. YAML tasks I can read six months later. Every task is essentially “here’s the command I’d have SSH’d in to run — do that.”

Ansible won. Not because it’s technically superior — because the learning surface fit into the space I had. If you already know how to SSH in and do things by hand, Ansible is those same things automated. It’s the shallowest possible on-ramp.

Also, Ansible from WSL on my Windows laptop works fine, which was table stakes for me — I daily-drive Windows and I wasn’t switching.

What each host ended up doing

Here’s the fleet, mapped back to the six goals:

• pve1, pve2 (the two mini PCs) — Proxmox hosts. Every VM lives on one of them. That’s their whole job.
• monitor (VM) — Prometheus + Grafana + Loki. This is the “if I can’t see it, I can’t fix it” answer.
• pbs (VM) — Proxmox Backup Server. Backs up every other VM nightly to the NAS.
• postgresql (VM) — Shared database for anything that needs one. Includes TimescaleDB.
• jenkins (VM) — CI for personal projects.
• jellyfin (LXC — a lightweight container flavor of Proxmox VM, faster to boot and cheaper on RAM) — Media server. The “goal 2” answer.
• vpn-gateway (VM) — Routes a specific slice of the network through a commercial VPN. Nothing personal touches it.
• torrenter (VM) — Pinned to route through vpn-gateway. Downloads media. Also the “goal 5, experiments” answer, since I break its networking on the regular.
• server (VM) — Runs a side-project stack. Belongs on its own for blast-radius reasons.
• amd64-1 (VM) — General-purpose Docker host for whatever I’m currently prototyping.
• pihole-p, pihole-s (Pis) — Redundant Pi-hole + Unbound. Goal 1 answered, with no single point of failure.
• hass (Pi 8GB, boots from USB-SSD) — Home Assistant. Goal 3.
• arm64-1 (Pi) — General-purpose ARM64 machine for whatever weird thing needs ARM.

Fifteen machines, six goals, roughly one workload per machine. The one-workload-per-machine rule matters more than I expected: it means I can blow away a VM to fix it and only that VM’s users notice.

What this series covers

This blog is going to work through the whole setup, most-fundamental-first:

1. This post — the origin story and every “why.”
2. Setting up the two mini PCs as Proxmox hosts — the actual bare-metal-to-cluster walkthrough. Boring in a good way.
3. Getting the four Pis ready for real work — the once-per-Pi setup that I finally got repeatable.
4. Then, one post per service — DNS pair, VPN gateway routing, media server, monitoring, backups, home automation. Each one a full story: why I run it, how I set it up, what went wrong.

If you’re a homelab beginner: I was one three years ago, and honestly still consider myself one on plenty of topics. The point of writing this is that I remember what “I don’t know what a VLAN is” felt like. I’ll explain the words as they come up.

If you’re not a beginner: skip ahead. But maybe stick around for the mistakes — I’ll be honest about those too.

Let’s build a homelab.