Tech-kutak
Sign in Subscribe

Building tomorrow, one prompt at a time

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

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

Hooked yet? If you’re a software person who’s tired of chasing the latest SaaS feature and paying twice for reliability, your home lab can be a better steward of both your time and your wallet. I built mine to stop fighting with flaky cloud credits, to keep sensitive projects in my control, and to learn by doing rather than by reading endless glossed-over tutorials. The payoff isn’t a flashy stack; it’s a repeatable, boringly reliable engine you can dial up or down as needs change. This is the playbook I wish I had years ago: practical, opinionated, and ruthlessly focused on what actually works in a real home environment.

1) Start with goals you’ll actually maintain

The fastest way to waste a homelab is to chase every new tech fork because it sounds cool. Instead, write down concrete outcomes:

  • A versioned, IaC-driven home infrastructure you can reproduce on a new machine.
  • Self-hosted CI/CD for your personal projects, with secure credentials and automated testing.
  • A small NAS for backups, media, and shared storage with proper snapshotting.
  • A home network that isolates services, logs activity, and blocks most surprises.
  • A maintainable on-call routine: weekly checks, sanity tests, and documented disaster recovery.

Your goals should be modest, repeatable, and scalable. If your plan can be explained in one screen and kept current in a single notebook, you’re off to a good start.

2) The guts of a practical stack (and what to prune)

What follows is a lean architecture that fits a homelab budget and a busy life. It’s not the “latest sexy” Kubernetes demo; it’s a reliable, local-first setup you can grow with.

  • Hypervisor: Proxmox VE on commodity hardware. It’s efficient, easy to manage, and yields clean VM and container boundaries. It also plays nicely with ZFS, which makes backups and snapshots trivial.
  • Storage: A single or dual-drive ZFS pool (mirror if you care about writes; RAIDZ-1/2 if you want capacity). Use storage pools for VMs and containers, with periodic snapshots and off-host backups. Don’t overengineer Ceph for a home lab; it’s a maintenance burden unless you genuinely need multi-OS, multi-node redundancy.
  • Firewall/Router: A dedicated VM or physical appliance running pfSense or OPNSense. Put it at the edge, create VLANs, and route sensible traffic to your internal services. If you’re starting small, you can run a basic firewall in a VM, but don’t skip isolation.
  • Kubernetes (optional but powerful): A small K3s cluster (one master, one worker) inside Proxmox VMs. It’s not required for every project, but it’s incredibly convenient for multi-service deployments, GitOps, and learning Kubernetes in a low-stakes environment.
  • CI/CD and code hosting: Drone CI or GitLab Runner inside a VM/Container, plus a lightweight Git host like Gitea or a self-hosted GitHub runner approach. The goal is to keep pipelines local and reproducible, not to mimic a cloud-scale pipeline.
  • Apps and services: A containerized stack (Traefik as a reverse proxy, Let's Encrypt for TLS, Portainer or Rancher for management, and a small set of services you actually use). Keep only what you need, then iterate.
  • Backup and observability: A dedicated backup VM with rsync/borgbackup for critical data, and a lightweight monitoring stack (Prometheus + Grafana) or a simpler local script-based health checks if you’re starting out.

The truth: you don’t need everything at once. Start with a single VM for domain services (Git host or CI runner) and a NAS for backups, then add the firewall, then the hypervisor, etc. Each addition should have a clear win and a well-documented rollback.

3) Hardware reality checks and budgeting

  • Budget envelope: A solid home lab can be started for under $600–$1000 if you already own a home server or a consumer-SSD/NVMe drive. Expect $200–$400 for a used or refurbished server, $100–$200 for a decent NAS drive, and $100–$300 for a small switch or firewall hardware. Add $50–$100 for a basic UPS to avoid power glitches corrupting disks.
  • Hardware choices:
  • CPU: A modern Xeon E5/8xxx era or Ryzen Pro/AM4 era machines are cheap and plentiful in the used market. Look for 16–32 GB RAM minimum if you plan to run multiple VMs and a Kubernetes node.
  • RAM: 32 GB is comfortable for a practical starter; upgrade later if you run Prometheus or a larger cluster.
  • Storage: Start with 2 drives for mirror (RAID 1) and expand to 3–4 as you grow. Use ZFS with a dedicated pool for VMs and a separate pool for backups.
  • Networking: A gigabit switch is fine; consider one with VLAN support and PoE if you plan to power a small AP or a smart switch.
  • Quiet, reliable operation: Homelabs are not data centers. Prioritize reliability and noise control. Solid-state drives for the host OS, regular backups, and a smart power strategy keep you sane after updates.

4) Proxmox + ZFS: the boring-but-necessary foundation

Proxmox VE is the workhorse that makes this practical. It gives you a single pane of glass to manage KVM VMs and LXC containers, with snapshots, backups, and a simple REST API. ZFS gives you strong data integrity, easy snapshots, and robust replication across host machines.

  • Quick start (high level):
  • Install Proxmox on bare metal. Use the current ISO, enable the web GUI, and configure a management network.
  • Create a ZFS pool: mirror for performance and safety.
  • Create VMs and/or LXC containers for your core services: firewall/router VM, NAS VM, K3s control plane, CI/CD runner, and a general app host.
  • Snapshots: Establish a cadence (e.g., every night at 2am) for VM backups; keep at least 2 backups per VM, plus periodic off-host replication for critical data.
  • Concrete tips:
  • Separate your OS disk from data disks in ZFS to avoid a single point of failure affecting everything.
  • Use Proxmox backups (pbkrs) and ZFS snapshots as parallel safety nets.
  • For the firewall VM, disable unnecessary services and limit admin access to a dedicated admin host via SSH keys.

5) Networking and security as a design constraint, not an afterthought

Your homelab is only as trustworthy as your security model. The mistake many make is treating internal services as “free” from risk because they’re on a home network. Treat it like a small business:

  • Segment with VLANs:
  • VLAN 10: IoT and guest devices (isolate as much as possible).
  • VLAN 20: Production/dev services (Git host, CI runner, NAS, K3s control plane, dashboards).
  • VLAN 30: Management (admin machines, jump hosts).
  • Zero-trust-ish defaults:
  • Use a central reverse proxy (Traefik) with mTLS for internal services where feasible. Use TLS everywhere and rotate certificates regularly.
  • SSH into boxes using key-based auth only; disable password login; restrict root access.
  • Monitoring and alerting:
  • Centralize logs and metrics from your services. Keep a local Grafana dashboard with Prometheus data, but push critical alerts to your phone or email.
  • Basic heartbeat checks: ensure your proxies, vault/secrets, and CI, plus K3s nodes, report health at 5-minute intervals.

6) Git, CI, and GitOps in a homelab that actually works

One of the most valuable things you can do in a homelab is to treat your own infrastructure like production. That means versioning everything, having test environments, and automating deploys.

  • Git host:
  • Gitea (small, self-contained) or a lightweight GitLab Community Edition instance.
  • Keep your own infrastructure as code (IaC) in Git in a dedicated repo.
  • CI/CD:
  • Drone CI or GitLab Runner on a VM or container. Use pipelines to build, test, and deploy your own projects to your local cluster or VMs.
  • Example: a pipeline that runs unit tests, builds a Docker image, pushes to a private registry (inside the same network), and then triggers a deployment to your Kubernetes cluster or a docker-compose-based app on a separate VM.
  • GitOps:
  • For Kubernetes, Argo CD or Flux can auto-sync manifest repos with the cluster. For a tighter homelab, you can implement a minimal GitOps approach: push changes to a repo; a small controller polls, validates, and applies changes to your K3s cluster.
  • Keep a small, readable manifest set: namespace definitions, deployments, services, and Ingress with Traefik. Everything can live alongside app code in the same repo.
  • Local container registry:
  • Run a private registry (at minimum, a Harbor or a simple Docker registry) inside your network to host custom images and CI artifacts.
  • Practical example:
  • A monorepo with:
  • apps/service-a for a personal microservice
  • infra/k3s-manifests for Kubernetes deployment manifests
  • ci/drone-pipelines.yml for CI
  • When a PR is merged to main, CI builds, pushes a container image to the internal registry, and Argo CD (or a simple script) updates the K3s deployment.

7) A concrete starter stack you can actually assemble this weekend

  • Proxmox VE host:
  • Create a VM for the firewall (OPNsense), a VM for NAS (Samba or Nextcloud), a VM for K3s control plane, a VM for Drone/Gitea, and containers for Traefik, Grafana, and a small log collector.
  • K3s cluster (one master, one worker):
  • Install K3s on the master node; join the worker with the token. The node count can stay small to begin with; scale later.
  • Traefik + TLS:
  • Run Traefik as an ingress controller in the K3s cluster, with a