Tech-kutak
Sign in Subscribe

Building tomorrow, one prompt at a time

The Pragmatic Home Lab: Self-Hosting Your DevOps Stack

Ivan Horvatić 6 min read
The Pragmatic Home Lab: Self-Hosting Your DevOps Stack

If you’re reading this, you’ve likely outgrown “one-click” cloud toys and want something that actually scales with you: a home lab where you control the stack, the backups, and the upgrade cadence. This piece isn’t about chasing the latest buzzword; it’s about building a durable, actionable setup you can grow into without breaking the bank or your sanity. Below is the path I’ve followed in my own homelab, with concrete choices, tradeoffs, and a pragmatic workflow you can steal.

Why this approach works in a real home lab

  • You can start with a single modest machine and a couple of services, then layer in more hardware or virtualization as needs grow.
  • You’re not hostage to a single cloud provider; you own the data, the deployment process, and the security posture.
  • Automation isn’t optional—it’s how you keep a growing stack maintainable. The moment you skip IaC (infrastructure as code) and repeat manual steps, you’ll curse yourself later.
  • A sensible blend of VMs and containers gives you the best of both worlds: stability for key services and lightweight silos for apps.

1) Start with the right hardware, but keep it boring

Hardware is not the secret sauce; discipline is. That said, you want something reliable and upgradable.

  • Minimal starter kit: 1-2TB storage, 16GB RAM, a quad-core CPU (older Intel/AMD is fine). A used/ refurbished small server or a modern Mini PC with a PCIe NVMe SSD works great.
  • Practical options:
  • A single modest server (e.g., used enterprise hardware with ECC RAM if you can swing it) for Proxmox.
  • A small cluster of low-power devices (e.g., 2–3 Raspberry Pi 4s or Intel NUCs) for experimentation or specific workloads, not for the core stack.
  • Don’t chase speed for its own sake. Focus on a clean drive, safe backups, and a clean power supply. RAID-1 with a separate backup drive is better than a RAID-5 you pretend is safe.

2) The backbone: Proxmox as the operating system of record

I’m a Proxmox fan for homelabs. It’s not the only choice, but it’s practical, affordable, and mature enough for real workloads.

  • Why Proxmox?
  • Simple GUI + CLI for both VMs and LXC containers.
  • Excellent backup/restore capabilities for VMs and containers.
  • Flexible storage: ZFS, LVM, and directory-based pools. ZFS is a sweet spot if you want near-zero data integrity and clean snapshots.
  • Easy to scale: add more disks, add more nodes, extend clusters.
  • Quick-start outline:
  • Install Proxmox VE on your chosen hardware. Update the system (apt update && apt upgrade).
  • Attach a fast NVMe SSD for your containers/VMs and a larger HDD for backups.
  • Enable a separate management network or at least VLANs if your home network supports it.
  • What to run in Proxmox from day 1:
  • A management VM or container for automation tooling (Ansible, Git services, CI runners).
  • A container host (LXC) for lightweight services like Pi-hole, DNS, reverse proxy, and small apps you want to isolate but not worry about heavy virtualization for.
  • A VM for more heavyweight services or anything you want to isolate from the container host (e.g., a GitLab instance if you outgrow Gitea).

3) Core services: hosting your own code, artifacts, and CI

A practical homelab needs a simple, reliable DevOps toolkit that you own.

  • Git hosting: Gitea (or GitLab if you need more features). Start with Gitea for speed and simplicity.
  • Run Gitea in a container with a persistent volume for repos.
  • Basic workflow: push to a git repo; set up webhooks to trigger your CI/CD pipeline.
  • CI/CD: Drone CI (or Jenkins if you’re more comfortable with it).
  • Drone is light, container-friendly, and easily integrated with Git repositories.
  • Basic pipeline idea: on push to a protected branch, run unit tests, build a container image, push to a local registry, deploy to a staging namespace, then to production after approval.
  • Local registry: a private Docker registry (can be a simple container running Registry v2) or use a Proxmox-based image cache to speed builds.
  • Project layout suggestion:
  • Repos in Gitea with Dockerfiles and Kubernetes manifests or docker-compose files.
  • A dedicated pipelines repository that defines your CI steps as code.
  • A charts or compose folder for your deployment definitions.

Sample practical notes:

  • Keep repository secrets out of code. Point CI to use environment security variables stored in Drone, Gitea secrets, or a secrets manager.
  • Use tags or protected branches so that production deployments don’t happen from feature branches by accident.

4) IaC and automation: what actually matters in a homelab

Automation saves time and reduces drift. Don’t overcomplicate it, but do something repeatable.

  • Infrastructure as Code:
  • Use Ansible for provisioning host configuration and software deployment across VMs/containers.
  • Consider Terraform for any bare-metal provisioning (DNS records, firewall rules) if your setup grows to multi-host or you want reproducible environments.
  • Example workflow:
  • Ansible playbook installs Docker, configures Docker Compose, sets up a user, enables SSH key-based access, and hardens the host.
  • A separate Ansible playbook deploys Gitea and Drone as containerized services with volumes mapped to a dedicated data store.
  • Practical starter playbook tips:
  • Idempotence is king. Ensure your playbooks can be safely re-run.
  • Use Ansible Vault for secrets. Never commit credentials to repo.
  • Keep inventory in a simple YAML file; start with a single host, then scale to a few VMs/containers.
  • Example playbook skeleton (high-level):
  • Install Docker
  • Create a docker-compose directory
  • Copy a docker-compose.yml for Gitea/Drone
  • Start services with docker-compose up -d
  • Harden SSH and disable password authentication
  • Gentle reminder: test playbooks in a safe test VM before applying to production-like hosts.

5) Networking, DNS, TLS, and external access

The cornerstone of a usable self-hosted stack is accessible services with sane security.

  • DNS and ad blocking:
  • Pi-hole or AdGuard Home as your DNS sink to block ads and trackers in your home network.
  • Forward internal domains to your internal services; set up split-horizon DNS if you’re using dynamic IPs.
  • VPN and remote access:
  • WireGuard as your VPN for remote access to your home lab. A single, well-guarded VPN endpoint keeps admin access consistent without exposing services publicly.
  • Reverse proxy and TLS:
  • Nginx Proxy Manager or Traefik to terminate TLS and route to your internal services.
  • Always-on TLS via Let's Encrypt; rotate certificates automatically.
  • Example setup:
  • Nginx Proxy Manager container on a dedicated LXC/VM.
  • DNS entries for internal hostnames (git.yourdomain.tld, ci.yourdomain.tld) pointing to your public IP; if you’re behind CGNAT, you’ll want to handle dynamic DNS via a dynamic DNS provider.
  • WireGuard server container or VM that allows you to connect to your network securely from outside.

6) Storage strategy: keep data safe and recoverable

Your data strategy is a non-negotiable pillar of a useful homelab.

  • Local storage choices:
  • ZFS on Proxmox: great for data integrity, easy snapshots, simple replication.
  • Alternatively, Btrfs or ext4 with periodic rsync backups—but you’ll miss some ZFS conveniences.
  • Backups:
  • Proxmox backup jobs for VMs and containers; snapshotting is your friend.
  • Restic or Duplicacy for file-level backups; store backups on a separate drive or remote object storage if you like. Include your critical repos and config files.
  • Offsite backups: at least one version offsite (or in a different physical location) to protect against fire/flood theft.
  • Data lifecycle:
  • Periodic pruning: delete stale logs, rotate database backups, and archive old artifacts to long-term storage.
  • Encryption at rest for sensitive data; use LUKS or ZFS native encryption where possible.

7) Observability and security posture

If you can’t see what’s happening, you won’t fix it before it bites you.

  • Monitoring stack:
  • Prometheus for metrics, Grafana for dashboards.
  • node_exporter on hosts; cAdvisor for container metrics; blackbox_exporter for uptime checks.
  • Loki/Promtail for logs (optional, but helpful).
  • Security basics:
  • Centralize access with SSH keys; disable password login.
  • Rotate credentials; use 2FA where possible (Gitea/Jira/docker registries).
  • Firewall rules that are as tight as possible; default deny with explicit allow rules.
  • Regular OS updates and vulnerability scanning (e.g., have a standing routine to run unattended-upgrades on Debian-based systems).
  • Minimal container privileges; avoid running containers as root.

8) Practical example: a small, concrete, incremental rollout

If you’re starting from scratch, here’s a realistic, minimal-to-grow plan you can actually implement this weekend.

  • Day 1: Install Proxmox on a single server
  • Allocate 1 VM for management (Proxmox web UI, Ansible control, monitoring).
  • Create a local ZFS pool (two disks: pool/data).
  • Create 1 Linux container for DNS/redirects (Pi-hole + Nginx Proxy Manager in another container) and a VM for Docker host if you want a separate Docker layer.