Tech-kutak
Sign in Subscribe

Building tomorrow, one prompt at a time

A Practical Homelab Playbook: Self-Hosting, DevOps, and Automation You Can Actually Run

Ivan Horvatić 5 min read
A Practical Homelab Playbook: Self-Hosting, DevOps, and Automation You Can Actually Run

If you’ve ever watched a cloud-native circus from the cheap seats and wondered how to bring that level of repeatability and control into your own closet, you’re not alone. The truth is, you don’t need a data center or a PhD in distributed systems to run a reliable, self-hosted stack. You need a plan, sane defaults, and the discipline to start small, automate the boring bits, and iterate. This is my practical, no-fluff guide to building a homelab that actually serves you—servers that stay up, configurations that you can version, and a workflow that makes sense when you’re juggling a dozen little projects between coffee breaks.

Hook: Why bother? Because clouds are great for experiments; your homelab is where you learn how things actually work, end-to-end, with real constraints and real ownership. The goal isn’t to replicate every service in the cloud, but to create a resilient, observable, and reproducible environment for development, automation, and personal projects.

Plan before you buy: think in layers

  • Hardware: spend on reliability and energy efficiency first. ECC RAM, a sensible CPU, and enough drives for your storage needs beat chasing the latest GPU-powered unicorn. The goal is not “the most fancy kit” but “the most boringly reliable kit.”
  • Hypervisor: Proxmox VE is my bread-and-butter for bare-metal homelab automation. It’s stable, community-supported, and plays nicely with LXC for lightweight apps and KVM for full VMs.
  • Storage: ZFS is your friend for snapshots, checksumming, and resilience. Use mirrored drives for the pool if you can; allocate a separate pool or dataset for backups and ISOs.
  • Network: don’t rely on a single device to be your firewall, VPN terminus, and DNS server. A small, robust edge routing stack (pfSense/OPNsense or a simple Ubiquiti/Untangle-ish setup) plus a WireGuard DNS/remote access strategy saves you a lot of pain later.
  • Security: automate updates, monitor for drift, and run a VPN as your default remote access channel. MFA everywhere that matters. If you’re new to this, start with network segmentation and a robust backup plan.

A realistic starter stack

  • Hypervisor: Proxmox VE on a compact head node (8–16 cores, 32–64GB RAM for a small home lab; more if you want more VMs and comfortable container density).
  • Containerized apps (LXC): Nextcloud, Pi-hole, Home Assistant, Glances/Portainer, a small Git service (Gitea), a CI runner (Drone or GitLab Runner), a lightweight monitoring stack (Prometheus node_exporter, cAdvisor).
  • Full VMs (KVM): a NAS VM with ZFS on Linux, a VPN gateway, a reverse proxy (Traefik or Nginx with Let's Encrypt TLS), and perhaps a small CI server if you want to isolate CI workloads.
  • Networking: WireGuard for remote access, a proper firewall, DNS with DNSSEC if you’re ambitious.
  • Observability: Prometheus + Grafana, Loki for logs, cAdvisor for container metrics.

Getting Proxmox installed and bootstrapped

  • Install Proxmox VE on a dedicated host. Use a single NVMe for the OS, and a separate pool of drives for data if you can swing it. If you’re starting small, you can host containers first and migrate to VMs later.
  • Enable Ceph or ZFS on root depending on your drive count and resilience needs. For simplicity, ZFS on Proxmox is a solid choice for home labs.
  • Create a small cluster if you have more than one node, but don’t push for a multi-node cluster until you’re comfortable with live migrations and quorum concepts.

A minimal, pragmatic install plan

  • Step 1: Baseline OS and updates. Set a static management IP, enable SSH with key auth, disable password login, and apply a basic firewall (either Proxmox’s built-in firewall or a small pfSense/OPNsense VM if you’re feeling ambitious).
  • Step 2: ZFS storage layout. Create a mirrored pool for data, a separate pool for VM images, and a backup pool.
  • Step 3: LXC containers for core services. Deploy containers for Nextcloud, Pi-hole, Home Assistant, and a small CI helper. Use static quotas to prevent one container from overwhelming the host.
  • Step 4: A VPN and reverse proxy. Spin up a small VM or container for a WireGuard server and put Traefik/Nginx in front of your apps with let's encrypt TLS managed automatically.
  • Step 5: Observability. Install Prometheus node_exporter on the Proxmox host and on containers, and set up Grafana dashboards. Consider Loki for logs if you’re collecting a lot of textual data.

Concrete service choices and rationales

  • Gitea for Git hosting; Drone or a lightweight GitLab Runner for CI:
  • Why: Gitea is light on resources, easy to install, and provides repository hosting with webhooks. Drone is a small, container-native CI system that plays nicely with Gitea without dominating your resources.
  • How: Run Gitea in an LXC container or small VM, expose a protected URL via your reverse proxy, and integrate a Drone runner with a registration token.
  • Nextcloud for file access:
  • Why: Self-hosted file sync, calendar, and notes in a single, familiar interface. It’s modern and has a good ecosystem of apps; it’s also straightforward to backup with ZFS snapshots plus external backups.
  • How: Run as an LXC container; mount your storage pool through Proxmox to keep data on fast, reliable disks.
  • Home Assistant for home automation:
  • Why: Centralized automation that isn’t hosted in the cloud. You can run many integrations locally and keep sensitive data in-house.
  • How: Run in an LXC container; use a USB Zigbee/Z-Wave stick or a GPIO-powered hub if needed; expose limited access externally via your VPN and a secure reverse proxy.
  • Pi-hole for DNS-level ad blocking:
  • Why: Simple, effective, and almost zero maintenance.
  • How: Run in a small container; point your LAN DHCP to Pi-hole; pair with DNS-over-HTTPS if you’re comfortable with it.
  • Monitoring stack (Prometheus + Grafana):
  • Why: Visibility into container health, service latency, disk I/O, and network performance. You’ll thank yourself when something goes sideways.
  • How: Deploy Prometheus with service discovery for your containers and VMs; Grafana dashboards for metrics; optional Loki for logs.

Security, backups, and recovery you can rely on

  • Backups:
  • Regular ZFS snapshots of VMs/containers.
  • Offsite backups of critical data (Nextcloud, Gitea repos, and config) to a separate, encrypted destination (synced to a remote server or object storage).
  • Periodic disaster-recovery drills: simulate a full restore from backups to confirm you actually can recover.
  • Backups to remind you of the basics:
  • Daily incremental backups; weekly full backups.
  • Verify restores quarterly (don’t wait for a failure to test your plan).
  • Firewall and isolation:
  • Put your public services behind a reverse proxy with TLS; keep administrative interfaces on private networks; restrict admin access to VPN or specific IP ranges.
  • Updates:
  • Use a controlled update cadence; do not update everything at once. Test updates in a staging container or VM if possible before rolling out to production-like services.
  • Secrets management:
  • Use environment variables or a secret store; rotate credentials regularly; do not store secrets in plaintext in repository code.

Automation and IaC: turning chaos into repeatable runs

  • Version everything:
  • Use Git as the single source of truth for infrastructure and config.
  • Keep a separate repository for Ansible playbooks or Terraform configurations if you’re provisioning in the cloud; keep Proxmox-specific configurations in a separate repo if you can.
  • Ansible for provisioning:
  • Use Ansible to establish and maintain service configurations in containers and VMs. A small set of playbooks can bootstrap a new service, apply a patch, or roll out configuration changes across multiple containers.
  • Example: a minimal Ansible snippet to install Nginx and configure a basic TLS cert via Let's Encrypt.
  • Repository-driven CI/CD for your homelab:
  • With Gitea and Drone, push changes to your config repo; CI runs tests (linting for YAML/JSON, basic syntax checks), and deploys to your lab environment if checks pass.
  • GitOps-ish pattern:
  • Treat your cluster as code; your home lab is reproducible by simply pulling a repo and running a bootstrap script or Ansible role.
  • Document drift and commit corrective changes—do not let the lab diverge into chaos.

A concrete, small starter deployment example

  • Proxmox host with 2 TB SATA drives in a ZFS mirror for data and an NVMe for the OS.
  • Containers:
  • Nextcloud: 2 vCPU, 2 GB RAM (minimum