Practical Homelab: Self-hosted CI/CD, GitOps, and Automation for a Resilient Home Lab

Hooked on automation but stuck with “just enough” at home? A well-tuned homelab can feel like real IT, not a toy. This is a pragmatic blueprint for a self-hosted stack that actually ships software, recovers gracefully, and doesn’t melt down every time you reboot your router. It’s not about chasing the latest buzzwords; it’s about reliable, repeatable workflows you can extend year after year.

Why this matters in a home lab

• You ship apps to your own infrastructure instead of relying on cloud services you don’t fully control.
• Your CI/CD and GitOps pipelines become the single source of truth for how your services run, scale, and recover.
• You build muscle for real-world ops: backups, secrets, security posture, and disaster recovery—without risking a production-style outage at work.

The core idea: a small but reliable stack that mirrors modern enterprise workflows, scaled down to fit a 1–2-node homelab. You don’t need a data center budget; you need discipline, reproducibility, and sane defaults.

Architectural overview: what you’ll actually run

• Virtualization layer: Proxmox VE (free for home use) to host lightweight Linux VMs or LXC containers.
• Containerized cluster: a small Kubernetes distribution (K3s) across 2–3 nodes (or 1 if you’re starting small).
• GitOps center: Argo CD (or Flux) deployed in the cluster to keep Kubernetes manifests in sync with a Git repository.
• Self-hosted CI: Drone CI or JFrog Pipelines running as containers, tied to your Git hosting (GitHub, GitLab, or a self-hosted option like Gitea for source control).
• Private container registry: a lightweight registry (Docker Registry or Harbor) for you to store container images.
• Ingress and networking: a reverse proxy and TLS termination (Traefik or NGINX Ingress) with Let's Encrypt certificates.
• Observability: Prometheus + Grafana for metrics, Loki for logs, and Alertmanager for notifications.
• Storage and backups: ZFS on the Proxmox host for snapshots, plus Borg/Restic backups to an NFS share or an S3-compatible endpoint.
• Secrets and security: Sealed Secrets or SOPS for secret management; regular software updates; basic network segmentation with VLANs.

Hardware and network prerequisites

• A capable host (or two) with room to grow:
• 16–32 GB RAM minimum for a compact 2-node Kubernetes cluster; 32–64 GB if you plan more services.
• 2–4 TB fast storage (SSD for OS and database logs; HDDs for bulk storage; consider ZFS for snapshots).
• A reliable NICs (at least 2x NICs for internal and external networks).
• Networking basics:
• A stable home network with at least VLAN support or an edge router that can do VLANs and firewall rules.
• DNS that you control (either Pi-hole in LAN or your own DNS server) and a domain you own (even a dynamic DNS if you’re on consumer Internet).
• Power and cooling:
• Redundant power is nice but not mandatory; ensure uptime on your main node with a small UPS if possible.
• Plan for thermal throttling if your hardware is in a small closet; keep fans on low but steady.

Step-by-step deployment plan (practical, not theoretical)

1) Get a solid virtualization host

• Install Proxmox VE on your chosen machine.
• Create a small management network isolated from your LAN for management tasks (optional but recommended).
• Create 2–3 VMs or LXC containers to host your Kubernetes cluster and ancillary services:
• VM1: Kubernetes master (or control plane)
• VM2: Kubernetes worker
• VM3: Optional extra worker or a management node for CI/CD, registry, and logging

2) Build a compact Kubernetes cluster

• Choose K3s for simplicity. If you’re multi-node, configure one as server, others as agents.
• Example high-level steps (adjust for your environment):
• Install containerd and k3s on the first node: curl -sfL https://get.k3s.io | sh -
• On additional nodes, join with: K3S_URL=https://<server-node>:6443 K3S_TOKEN=<token> sh -
• Verify with kubectl get nodes; aim for a healthy 2–3 node cluster.

3) Deploy GitOps first

• Install Argo CD in the cluster:
• kubectl create namespace argocd
• kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
• Expose Argo CD via a Ingress or LoadBalancer and secure it with TLS.
• Connect Argo CD to a Git repository that holds your Kubernetes manifests (or Helm charts).
• Create an Argo CD app that points to your app repo and the target cluster/namespace. This becomes your single source of truth for Kubernetes.

4) Set up a private container registry

• Use a lightweight registry:
• For Docker Registry: docker run -d -p 5000:5000 --name registry registry:2
• For Harbor: more features, including vulnerability scanning
• Push small images from your CI pipeline to the registry; configure imagePullSecrets in Kubernetes so your cluster can pull them.

5) Add a CI/CD system

• Drone CI is a good fit for a home lab; it’s lightweight and integrates nicely with GitHub/GitLab/Gitea.
• Deploy Drone on a VM or as a Kubernetes Helm chart inside your cluster.
• Connect Drone to your Git repo; create pipelines that:
• Build a container image
• Push to your private registry
• Update kube manifests if needed (e.g., image tag update) and trigger Argo CD to sync
• Example minimal .drone.yml:
• kind: pipeline
• name: build
• steps:
• name: build

image: docker:stable

commands:

• docker build -t <registry>/my-app:${DRONE_COMMIT} .
• docker push <registry>/my-app:${DRONE_COMMIT}
• echo "tag=${DRONE_COMMIT}" > artifact.txt
• This is a starting point; you’ll iterate to include tests, security checks, and canaries.

6) Observability and alerting

• Install Prometheus and Grafana via Helm:
• helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
• helm install prometheus prometheus-community/kube-prometheus-stack
• Add Grafana dashboards for Kubernetes metrics, CI/CD metrics, and registry usage.
• Install Loki