How it started — and why it grew

I’d been running a homelab on a couple of Raspberry Pis for a while. They were the perfect place to poke at things — small, cheap, low-power, and forgiving when I broke them.

Then AI agents took off, and I wanted to experiment with running models locally with Ollama. That’s where the Pis hit a wall: great for tinkering, not so great for anything compute- or memory-hungry. I wanted a real, multi-node environment I could run a proper Kubernetes cluster on — and host local LLMs without paying per token.

So I went shopping. The whole rule was cheap: everything here came off the secondhand marketplace, which is exactly why mini-PCs and a few small boxes beat a loud, power-hungry rack server.

The hardware

Four small machines, a switch, and a NAS — nothing rack-mounted.

Compute: 2× Dell OptiPlex 3070 Micro

The two workhorses, which I named plex1 and plex2. They’re identical, so here’s the spec for one node (both are the same):

The 3070 Micro hits the homelab sweet spot: a 35 W “T” CPU sips power and runs silent, but six cores and 24 GB of RAM are plenty to host a multi-node cluster — and finally enough headroom to run Ollama. The 2 TB SSD in each node holds the VM disks (local-ssd); the smaller NVMe handles boot and Proxmox itself.

Two nodes instead of one bigger box was deliberate: it lets me split the Kubernetes control plane across physical hosts and actually learn multi-node clustering — the whole point of the exercise.

2× Raspberry Pi 5 — where it all started

The Pis are still around. They were the original homelab and my first set of experiments, and they’ve earned a permanent spot. These days they handle the lighter, always-on bits while the OptiPlex nodes do the heavy lifting.

Storage: Buffalo TeraStation 5200 NVR

Bulk storage and backups live on a secondhand Buffalo TeraStation 5200 NVR — a 2-bay business NAS, loaded with 2× 4 TB drives. It has dual Gigabit ports, so the box itself isn’t the bottleneck; in practice it runs well behind the node-local SSDs, which is exactly why it stays in the “cold storage / backups” tier and each compute node keeps its own local 2 TB SSD for anything live or performance-sensitive.

Networking: TP-Link switch

Everything sits on a single flat LAN:

                Internet
                   │
          ┌────────┴─────────┐
          │   home router     │  gateway, DHCP
          └────────┬─────────┘
                   │
          ┌────────┴─────────┐
          │  TP-Link switch   │  unmanaged, 5 V powered
          └────────┬─────────┘
         ┌─────┬────┴───┬──────┬───────┐
       plex1  plex2   Buffalo  rpi5    rpi5
                       NAS

The switch is a plain, unmanaged 5 V-powered TP-Link unit — the same low-power class of gear as the Pis themselves. No VLANs, no management, nothing fancy: the OptiPlex Micros each have a single onboard 1 GbE NIC, and the switch just ties the nodes, NAS, and Pis together off the home router. (Segmenting this into VLANs is on the list for a later post.)

Power & physical setup

It’s all low-power by design — those 35 W CPUs idle quietly. No UPS yet; that’s the next purchase, because the one thing this setup can’t currently survive gracefully is a power blip.

What’s actually running on it

To make the hardware concrete — here’s the current Kubernetes cluster, running as Proxmox VMs spread across the two nodes:

Two control-plane nodes and three workers, with the control plane split across physical hosts so a single node reboot doesn’t take the cluster down. On top of this runs my GitOps/observability stack and the local-AI experiments that started this whole upgrade — the subject of later parts.

Decisions and trade-offs

• Secondhand mini-PCs over a rack server — quiet, low-power, fits anywhere, and cheap. The cost is no IPMI/iLO and limited expansion, which I can live with.
• Two nodes over one — redundancy and a real multi-node cluster to learn on, rather than one big single point of failure.
• Node-local SSD + a NAS for cold storage — fast, node-local storage for anything live; the Buffalo NAS strictly for backups and bulk.

What’s next

With the metal racked (well, shelved) and on the network, Part 2 covers the virtualization layer: installing Proxmox, the plex1/plex2 setup, and how the Kubernetes VMs are laid out across them.

It’s all learning — and the whole world’s our stage, folks.

Why a blog?

Writing things down forces me to actually understand them. The goal is short, practical notes I’d want to find again later.

How posts work

Each post is a Markdown file in _posts/ named YYYY-MM-DD-title.md with a bit of front matter at the top:

---
layout: post
title: "Your title"
date: 2026-06-21
tags: [kubernetes, terraform]
---

Then just write Markdown. Code blocks, lists, and links all work:

• Fenced code blocks get syntax highlighting
• inline code is supported
• Links work as expected

That’s it — commit, push, and it goes live.