Homelab Platform and GitOps

Project Overview

My homelab started as a Fedora Server host running KVM, with virtual machines provisioned by Ansible. It has since grown into a Proxmox-backed platform aimed at declarative operations: Git-managed cluster state, automated host setup, and CI-driven delivery of both applications and infrastructure.

The work is intentionally iterative. Each phase solved the pain that the previous stack could not, without pretending the platform is finished.

Where It Started

The first setup used Fedora Server with KVM. Ansible playbooks created and configured VMs for services, development, and experimentation. That worked well enough to learn automation, but day-to-day operations exposed limits:

• Manual VM lifecycle — create, resize, rebuild, and retire VMs by hand or with one-off scripts
• Snapshot and recovery gaps — backups existed, but full-environment recovery was slow and error-prone
• No declarative state — the running system and the Git repository could drift apart without anyone noticing

The Shift to Proxmox and Automation

Proxmox replaced the bare KVM workflow as the hypervisor layer. Host preparation and baseline configuration stayed in Ansible, which had already proven its value.

By this point, self-hosted GitLab and CI/CD pipelines were in place and had become the driver for how automation evolved: changes were tested in pipelines, reviewed in merge requests, and applied deliberately rather than interactively on hosts.

Workloads then moved toward Kubernetes, starting with k3s and continuing toward RKE2 as requirements around stability, add-ons, and operational patterns matured.

Current Platform

The target platform is built around GitOps and SOPS-encrypted secrets in Git, not ad hoc cluster edits. Most meaningful changes land as commits and merge requests. Flux reconciles the cluster from that repository; host-level Ansible still handles what Kubernetes should not own: hypervisor setup, networking baselines, and imaging workflows.

Active work right now is node imaging — CI-built Leap Micro / Combustion ISOs for reproducible bare-metal setup — as the cluster migrates from k3s to RKE2.

• RKE2 as the Kubernetes distribution, with migration work from earlier k3s deployments
• Flux for continuous reconciliation of cluster and application manifests from Git
• SOPS for secrets encrypted beside the manifests (see below)
• MetalLB for load-balanced services and Longhorn for persistent storage
• Keycloak and LLDAP for identity and directory integration
• Prometheus and Gatus for metrics and synthetic availability checks
• Self-hosted container registry fed by GitLab CI builds
• CI-built Leap Micro / Combustion installer ISOs for reproducible node imaging
• KubeVirt under evaluation for VM workloads alongside cluster-native services

Secrets in Git: SOPS + age

I encrypt secrets with SOPS and age, and commit the encrypted files next to the manifests. The only path into the cluster is a merge request—same review as any other change. Flux decrypts in-cluster using an age key stored as a cluster secret.

I never resisted committing secrets. Encrypted-in-Git is easier for me than maintaining long CI/CD variable lists: the secret is part of the reviewed change. Being responsible with the age key is what matters.

What Comes Next

Once Kubernetes runs reliably on bare metal, the plan is to split environments into production, staging, and development rather than sharing one cluster for everything. That separation should make promotion paths, blast radius, and experimentation safer without giving up the same GitOps model.

Lessons Learned

• Start with the pain you feel daily. VM sprawl and manual recovery were the forcing functions; Kubernetes and GitOps followed once the hypervisor layer was stable.
• Let CI drive discipline. Pipelines and merge requests shaped Ansible, imaging, and cluster changes more than any single tool choice.
• Secrets belong in Git—encrypted. SOPS made it practical to treat secrets like every other declarative artifact, and I prefer that over scattered CI variables.
• Platform work is a timeline, not a milestone. Each layer (Proxmox, k3s, RKE2, Flux, bare metal, multi-env) unlocked the next set of problems worth solving.