From Proxmox & Docker to Kubernetes

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:

  • Proxmox
    Managed virtual machines and basic resource separation.

  • Docker VM
    Ran most services using Docker Compose:

    • game servers
    • websites
    • monitoring
    • automation tools

  • NAS
    Provided shared storage and backups.

  • Mini PCs
    Used for additional workloads and testing.

Service management was mostly manual:

  • SSH into the correct host
  • edit a Compose file
  • restart containers
  • repeat on the next system

This was fine for a small number of services, but it did not scale well in terms of management.

Where the Limits Started to Show

As the environment grew, a few problems became obvious:

  • I had to log into every host manually
  • Restarts and updates were host-specific
  • Configuration drift was easy to introduce
  • There was no single source of truth
  • Scaling or moving workloads required manual planning
  • Learning was stagnating — I was repeating the same patterns

Most importantly:
the setup worked, but it was not teaching me anything new anymore.

Why Kubernetes

The move to Kubernetes was a deliberate learning decision.

I wanted to:

  • understand how modern platforms are actually operated
  • stop treating servers as special snowflakes
  • manage services declaratively
  • design for failure instead of hoping nothing breaks

Kubernetes forces you to think in terms of:

  • desired state
  • reconciliation
  • automation
  • repeatability

That alone made it worth the effort.

GitOps as the Missing Piece

Kubernetes without GitOps would only solve half the problem.

With GitOps:

  • Git is the single source of truth
  • changes are reviewed before being applied
  • rollbacks are trivial
  • the cluster reconciles itself
  • no more “what did I change last night?”

Instead of SSH and manual restarts:

  • I commit a change
  • the cluster applies it
  • everything converges automatically

If a node dies, workloads move. If a pod crashes, it restarts. If I want to change something, I change Git — not servers.

What Changed for Me

The biggest improvement was not technical — it was operational.

I no longer:

  • log into random hosts
  • restart services by hand
  • keep mental notes of where things run

I now:

  • describe what I want
  • let the system handle how it runs
  • learn skills that transfer directly to real-world environments

The homelab became a platform, not a collection of machines.