I’ve been slowly stripping my homelab down. Kubernetes to Docker was the first move. Three servers to one is the second. For a while, I had it split on purpose. One box for monitoring, one for Ansible, one for everything else I test at home. Different environments, different blast radius. Break something on the Ansible box, the rest doesn’t care. Then I actually looked at what the hardware was doing. ...
I ran Kubernetes in my homelab. RKE2, Flux, GitOps, the whole thing — I even wrote about the setup here and here. It worked. I learned a lot. Then I tore it all down and went back to plain Docker. What I actually run Let’s be honest about the scale first: three hosts at home and a VPS. Game servers, a monitoring stack, some self-hosted tools, backups. That’s it. No team, no hundred microservices, no traffic spikes that need autoscaling. ...
Standard setup. Node Exporter and cAdvisor running on the servers, feeding metrics to the monitoring server over Wireguard. Nothing exotic. I wasn’t chasing a specific failure mode when I set it up. I just wanted numbers to look at. The alert Disk usage on the Samba share on the NAS kept tripping the threshold. Almost full, every time. First reaction: something’s wrong. Logs filling up? A backup job stuck in a loop? I went looking for a problem. ...
Background I kept hearing about Pterodactyl but never actually tried it. So I spun up a fresh Debian 13 VM and followed the official docs from scratch. No shortcuts. No prior setup. Just the guide. What Is Pterodactyl? An open-source game server management panel. Every game server runs in an isolated Docker container. The architecture splits into two parts: Panel — the web UI and API Wings — the daemon that runs and manages the containers on the node Panel and Wings don’t need to be on the same machine. That separation matters when you want to scale. ...
Summary Running game servers at home worked — until it didn’t. What started as a learning project slowly became a real workload with real users. Friends were connecting daily, sessions got longer, and expectations grew. At the same time, my home network was being used normally: streaming, downloads, updates, and general traffic. Eventually it became clear: Kubernetes was stable. My storage was stable. My home network was not. The Real Problem: Home Network Limitations Game servers are extremely sensitive to: ...
Summary This post documents how I manage my Kubernetes cluster using Flux and a GitHub repository, and why I chose this approach. The short version: Git is the source of truth. The cluster continuously reconciles itself toward whatever is declared in the repo. Why I Chose GitOps Before GitOps, managing Kubernetes often turns into: applying YAML manually losing track of what changed “it worked yesterday” debugging differences between environments GitOps fixes that by enforcing a clean workflow: ...
Summary This post documents my current Kubernetes architecture running in my homelab. The goal was not just “make it work”, but build something that is structured, secure, reproducible, and close to how I would design it in a small production environment. The stack is built around: OPNsense as firewall and entry point HAProxy for load balancing RKE2 as the Kubernetes distribution Proxmox as virtualization layer Dedicated database VMs (PostgreSQL and MariaDB) WireGuard for secure access Restic for encrypted S3 backups Traefik + CrowdSec for ingress and security MetalLB for static service IPs Network Design The internal cluster network runs on: ...
Background My homelab started in a fairly classic way. I was running Proxmox as a hypervisor with: one main VM running Docker one NAS for storage two additional Mini PCs Across these systems, I hosted: game servers for friends internal websites a personal wiki monitoring and small helper services At the time, this setup worked well. It was flexible, easy to understand, and fast to get running. How the Old Setup Worked Each host had a clear role: ...