Table of Contents

🏗 Homelab Rebuild 2026 — From Homelab to a Mini Datacenter

Episode 0 — The project begins.

This is about a redesign of my entire homelab — not just adding one more service on top, but rethinking how the whole environment is built and operated.

I’ve actually worked with Kubernetes before, in a fairly similar setup to what I’m about to describe. Back in March I published the first draft of that idea. For reasons I still can’t fully explain, I drifted away from the original plan and never finished it. That post has now been retired. This time, I want to start again — following a plan that’s remarkably close to the one I had back then.

As usual, that escalated quickly.

3-node Proxmox cluster
Windows Server Active Directory
Windows 11 clients
Windows File Server
Internal PKI
GitLab
RKE2 Kubernetes
FluxCD GitOps
Longhorn & MinIO (covered in future posts)
Icinga2 Monitoring
Proxmox Backup Server

🎯 Goal

This is not about building a production datacenter. It is about learning how enterprise IT works by building one at home.

🖥️ Hardware

pve01 — 32 GB RAM, 512 GB OS SSD, 3×2 TB SSD (software RAID5)
pve02 — 64 GB RAM, 512 GB OS SSD, 2 TB SSD
pve03 — 32 GB RAM, 512 GB OS SSD, 2 TB SSD

🏛️ Architecture 2026: Not Everything New, But Finally Properly Assembled

Before writing this post, I dug up an old planning document from February — an earlier attempt at this exact same idea that I never finished. I expected to find something outdated and threw away most of it in my head before even re-reading it. I was wrong.

That February draft was already surprisingly close to where I’ve ended up today. It got the IP plan, the naming scheme, and the role split between Active Directory, PKI, and monitoring largely right. What it was missing wasn’t better technology — it was a proper operating model. So rather than starting from a blank page, this rebuild takes that old plan as a “Version 0.9”, keeps what still holds up, drops what doesn’t, and adds GitOps as the missing piece that ties it all together.

What survived from the old plan

IP range and domain — 192.168.10.0/24 on the internal network, with home.arpa as the domain suffix. home.arpa is the officially reserved TLD for home networks — a small detail the old plan already got right.
A readable naming scheme — instead of generic VM11/VM12 style names, every VM follows <pve-host>-<role>-<number>, e.g. pve01-gitlab01 or pve02-icinga01. You can tell where something runs and what it does just by reading its name.
Two Domain Controllers — pve02-dc01 (DNS, FSMO roles, Root CA) and pve03-dc02 (DNS, Global Catalog), spread across two different Proxmox hosts for redundancy.
A proper PKI hierarchy — offline Root CA → Issuing CA → servers and clients, instead of a single flat CA. Closer to how a real organization would run it.
Icinga2 for classical infrastructure monitoring (Proxmox, Windows Server, VMs, network) — Kubernetes gets its own Prometheus/Grafana stack instead, rather than forcing one tool to cover both worlds.
GitLab, promoted from “just a Git repository” to the central platform for source code, CI/CD, the container registry, and the GitOps repository that FluxCD watches.
Vault (or OpenBao) for secrets management — kept, but deliberately pushed to Phase 2 rather than a day-one dependency, so the initial Kubernetes/GitOps setup isn’t blocked on getting secrets management right first.

What I’m deliberately leaving behind

A homelab has a way of turning into a collection of “that’d be interesting too” technologies. This rebuild is meant to demonstrate deliberate architecture, not a technology pile-up — so a few things from the old plan are being dropped on purpose:

Bundling multiple services onto one VM (e.g. GitLab + Pi-hole + Grafana + Nextcloud together). Harder to back up, harder to maintain, and less realistic. One VM, one job.
A separate NAS server. Between the Windows File Server, Proxmox’s own storage, and Longhorn/MinIO for Kubernetes, a fourth storage platform would just add complexity without adding capability.
NFS as the Kubernetes storage backend. Longhorn is purpose-built for this and is the better way to actually learn Kubernetes storage.
Running Nextcloud outside Kubernetes. It’s a genuinely good learning workload — ingress, storage, database, secrets, backup — so it belongs inside the cluster, not next to it.
Stacking multiple overlapping monitoring systems (Icinga + Zabbix + Nagios + Prometheus all at once). One tool per layer is enough: Icinga2 for the classic infrastructure, Prometheus/Grafana for Kubernetes.
A dedicated firewall appliance (e.g. a separate FreeBSD-based firewall VM). Interesting on its own, but a distinct project that would dilute the focus of this one.

The consolidated VM & IP plan

VM placement follows the actual RAM available on each host: pve02 now has the most RAM (64 GB), so it carries most of the general-purpose and control-plane load. pve01 has less RAM but the big RAIDZ1 storage pool, so it keeps a lighter VM count but stays the natural home for storage-heavy Kubernetes workers. pve03 rounds it out with the file server, the second Domain Controller, and the remaining workers.

VM	Role	IP
`pve02-dc01`	AD / DNS / Root CA	192.168.10.31
`pve02-gitlab01`	GitLab / Container Registry	192.168.10.32
`pve02-seed01`	Dev VM (Ansible, kubectl, tooling)	192.168.10.33
`pve02-vault01`	Secrets Management (Phase 2)	192.168.10.34
`pve02-icinga01`	Monitoring	192.168.10.35
`pve02-k8s-cp01`	RKE2 Control Plane	192.168.10.36
`pve02-k8s-cp02`	RKE2 Control Plane	192.168.10.37
`pve03-fs01`	Windows File Server	192.168.10.41
`pve03-dc02`	AD / DNS / Global Catalog	192.168.10.42
`pve03-k8s-w03`	Worker	192.168.10.43
`pve03-k8s-w04`	Worker	192.168.10.44
`pve01-pihole01`	DNS Filter	192.168.10.51
`pve01-k8s-cp03`	RKE2 Control Plane	192.168.10.52
`pve01-k8s-w01`	Worker	192.168.10.53
`pve01-k8s-w02`	Worker	192.168.10.54

All of these VMs are meant to be provisioned automatically with Terraform, rather than clicked together by hand in the Proxmox UI — a deliberate first step toward treating the whole homelab as code, not just the Kubernetes layer on top of it.

Storage, simplified

Proxmox Storage (pve01)
    ZFS RAIDZ1 → VM storage, snapshots

Kubernetes Storage
    Longhorn → Persistent Volumes

Backup
    Proxmox Backup Server → VM backup

No additional NAS box in the middle — Proxmox’s own ZFS storage and Longhorn cover both worlds.

The five pillars

                Homelab 2026

        +-----------------------+
        |                       |
   Classic IT              Cloud Native

   Active Directory        RKE2
   Windows                 FluxCD
   SMB                     GitOps
   PKI                     Longhorn

        +-----------------------+

              Proxmox

        +-----------------------+

              Backup (PBS)

The point of this rebuild isn’t “I installed 25 technologies.” It’s: I’m building a small enterprise-style platform at home, and running it the way modern platform teams actually operate — with GitOps as the backbone connecting the classic infrastructure side to the cloud-native side.

📐 GitOps First

Everything related to Kubernetes will live in GitLab. Git is the single source of truth and FluxCD continuously synchronizes the cluster. No manual configuration drift.

📝 Documentation

Everything — architecture decisions, configurations, lessons learned and mistakes — will be documented publicly at https://www.github.com/aptupgrademe. The goal is to help others while creating my own knowledge base.

🤖 AI as a Learning Partner

Unlike previous Kubernetes experiments, this project will heavily use Claude as a technical sparring partner to understand concepts, review configurations, troubleshoot issues and improve documentation. AI is there to accelerate learning — not replace understanding.