Tech-kutak
Sign in Subscribe

Building tomorrow, one prompt at a time

A Practical Self-Hosted Homelab: DevOps, Automation, and Real-World Reliability

Ivan Horvatić 4 min read
A Practical Self-Hosted Homelab: DevOps, Automation, and Real-World Reliability

If your homelab is basically a pretty dashboard on your router’s status page, you’re leaving a ton of value on the table. A pragmatic homelab is not a toy; it’s a development platform, a CI/CD runner, a backup target, and a learning lab all at once. This is the blueprint I actually use, with a focus on reliability, reproducibility, and day-to-day usefulness rather than shiny gimmicks. You’ll see concrete hardware choices, a lean software stack, and actionable steps you can follow this weekend without turning your life into a second full-time job.

Why this approach works in a real home lab

  • Self-hosting saves money and gives you autonomy. You own your CI/CD pipelines, your code hosting, and your monitoring tools.
  • A small, well-designed stack reduces drift. Infrastructure as code, repeatable deployments, and modular services make it easy to evolve without breaking your entire environment.
  • You learn by doing. Running Kubernetes on a few nodes isn’t about chasing the latest buzzword; it’s about operational discipline: backups, monitoring, and disaster recovery.

Plan and architecture: keep it lean, keep it sane

Hardware (realistic baseline)

  • A dedicated but practical server box with room to grow:
  • CPU: 8–16 cores (e.g., 2–4 x modern Xeon/Ryzen-class CPUs or equivalent)
  • RAM: 32–64 GB to start; 128 GB if you plan for 4–6 VMs/containers running in parallel
  • Storage: 2–4 drives for ZFS storage pool; add a separate NVMe tier if you can swing it
  • Network: Gigabit is fine; 2.5G/10G is nice but not required at the start
  • Optional secondary NAS/backup target: a small one-bay NAS or a Raspberry Pi with backups to an external drive if you’re starting lean.

Software stack (the practical lineup)

  • Hypervisor: Proxmox VE. It’s VM-centric, has ZFS integration, snapshots, thin provisioning, and a friendly web UI. It lets you separate workloads cleanly.
  • Orchestration: k3s (lightweight Kubernetes) on 1–3 nodes. It’s simpler than a full Kubernetes install but gives you real experience with clusters, deployments, and operators.
  • Source control and CI/CD:
  • Git hosting: Gitea (self-hosted, lightweight, easy to back up)
  • CI: Drone CI or GitLab Runner (Drone is lighter; GitLab CE is feature-rich but heavier)
  • Configuration management and IaC: Ansible for host config, Terraform for infrastructure-ish state, and a GitOps approach for cluster apps (ArgoCD or Flux can be used, but keep it manageable).
  • Observability: Prometheus + Grafana for metrics, with Loki for logs if you’re feeling fancy; simple dashboards early on are enough.
  • Backups: BorgBackup or Restic for backups, with off-site replication to the NAS or another box.
  • Security and access: SSH keys, a jump/bastion host, basic firewall rules, fail2ban on exposed services, and simple mutual TLS where feasible.

A minimal, pick-two-start plan

  • Start with Proxmox on hardware and a single VM for Kubernetes (k3s) plus one VM for Gitea + Runner.
  • Add a second worker node as you grow.
  • Add Prometheus/Grafana on a separate VM or as containers on the cluster.
  • Add backups to NAS or external USB/SSD pool.
  • Expand with Drone CI and ArgoCD as comfort allows.

Step-by-step: getting it running

1) Proxmox VE install and initial network

  • Install Proxmox VE on the host hardware. Use a dedicated management IP on the admin network (no VMs on that NIC initially).
  • Create a sane VM network layout: a management bridge (vbr0) and a separate internal bridge for VM data traffic. If you have a switch that supports VLANs, segment lab traffic (e.g., 10.10.100.0/24 for lab, 10.10.200.0/24 for services).
  • Enable ZFS on Proxmox if you want built-in snapshots, compression, and easy backups. Create a single vdev (e.g., mirror or RAIDZ) if you have multiple disks.
  • Set up a basic firewall on Proxmox or rely on your router for north-south security. If you want a lab firewall, you can spin up a pfSense/OPNsense VM later.

2) Create templates and VMs

  • Create a Debian/Ubuntu minimal template that you’ll clone for each service. This keeps images small and consistent.
  • VM1: Kubernetes control plane (k3s server) + optional single node for admin tooling.
  • VM2: Gitea (and Runner if you want to keep CI local). Consider separating the runner if you expect heavy CI usage.
  • Optional VMs: Worker nodes for k3s, Prometheus/Grafana, Portainer/ colorful UI, backups agent, a bastion host.

3) Install k3s on the cluster

  • On the first node, install k3s (the server). On the subsequent nodes, install k3s with --server and join-token to connect as agents.
  • Example (simplified):
  • On first node: curl -sfL https://get.k3s.io | sh -
  • Retrieve token: sudo cat /var/lib/rancher/k3s/server/node-token
  • On second node: curl -sfL https://get.k3s.io | K3S_URL=https://<server-ip>:6443 K3S_TOKEN=<token> sh -
  • For a minimal home-lab, 1 master + 1 worker is enough. For reliability, add a second worker.

4) Networking and ingress

  • Install a basic ingress controller (nginx-ingress) or use Traefik in the cluster to expose services externally when you’re ready.
  • Set up a simple DNS hack for lab domains (e.g., mylab.local) by using a local DNS on your router or Pi-hole to resolve to the cluster’s ingress IP.
  • If you’re exposing services publicly, enforce TLS with Let's Encrypt (cert-manager on Kubernetes is a decent path) and consider a basic WAF approach if needed.

5) Git hosting and CI