Tech-kutak
Sign in Subscribe

Building tomorrow, one prompt at a time

Building a Practical Self-Hosted Homelab for DevOps and Automation

Ivan Horvatić 3 min read
Building a Practical Self-Hosted Homelab for DevOps and Automation

I didn’t start a homelab to chase buzzwords. I started one because the problems I encounter in production—deploy speed, reproducibility, and incident response—are the same ones I want to practice solving at home. The goal here isn’t to build the fanciest rack in the room; it’s to assemble a pragmatic, resilient setup that teaches you real DevOps discipline, without sinking your budget or your time into perpetual tinkering. This is a blueprint for a compact, self-hosted environment you can actually maintain, with a workflow you can scale when you grow.

Why you should care about a practical homelab

  • You gain hands-on experience with the tooling you’ll use in work: virtualization, configuration management, CI/CD, containerization, and observability.
  • You create a reproducible infrastructure. Small mistakes in the lab become cheaper to fix than in production.
  • You automate everything you can: backups, deployments, updates, and monitoring. If you can’t automate it, you’ve probably designed it wrong.
  • You’ll finally have a safe place to trial new ideas (security hardening, service mesh concepts, backup strategies) before risking real systems.

Core philosophy: keep it simple, reliable, and boringly automated

  • Start small, aim for a handful of services, then expand with discipline.
  • Use a single source of truth (code, not “a bunch of notes scattered across machines”).
  • Automate, but keep things observable and debuggable. If you can’t explain it, you can’t fix it.
  • Favor idempotent operations. You should be able to run the same playbook or script multiple times without breaking things.

1) Plan, hardware, and virtualization: the pragmatic baseline

Hardware decisions

  • Start with a used or refurbished server in a 1U–2U form factor, ideally with ECC RAM if your budget allows. ECC helps with reliability on home hardware, and you’ll thank yourself when you’re running long-running backups and multi-day migrations.
  • CPU: a few cores with a decent clock (15–25W low-power CPUs are common in older servers). Don’t chase raw cores at the expense of noise and power.
  • RAM: 16–64 GB is reasonable for a small lab. If you plan to run multiple VMs and containers, aim for 32 GB+.
  • Storage: an SSD for the host OS and a larger HDD/SSD pool for data. Use ZFS on the host or a dedicated storage VM/container if you’re comfortable; otherwise, a simple LVM or ZFS on Proxmox data drives works well.
  • Networking: at least two NICs if you can swing it (one for management, one for data). A dedicated VLAN for lab traffic helps segmentation later.

Hypervisor choice: Proxmox VE as the practical default

  • Pros: straightforward, well-documented, decent performance, strong LXC support, and an easy way to manage containers and VMs under one roof. It’s easy to back up entire containers/VMs, and Proxmox has a clean web UI plus a robust CLI.
  • Cons: you’ll still need to design storage and backups properly; Proxmox doesn’t abstract all cloud-like services away, but it makes on-prem easier to manage.

If you prefer a Docker-first approach, you can still start on Proxmox with LXC containers; the point is to keep your control plane reproducible, not to force one technology habit over another.

Networking and segmentation

  • Put the firewall/router in a dedicated VM (pfSense or OPNsense are the common choices). This gives you proper firewalling, NAT, and VPN capabilities in a portable, testable way.
  • Create a management VLAN (for Proxmox UI and SSH access) and a data VLAN (for your services). If you’re new to VLANs, start with flat networks and add segmentation as you need it.
  • Consider a small, local DNS (Pi-hole or dnsmasq) to speed up local name resolution and block ads in your lab. It’s a nice-by-default security/efficiency win.

Storage strategy

  • Use ZFS where you can for data integrity (mirror pools for reliability, RAID-Z for capacity).
  • Separate OS disk from data pools to simplify backups and OS updates.
  • Regular backups of your important data are non-negotiable. Use 3-2-1: three copies, two different media, one offsite.

2) The stack: Proxmox as control plane, VMs and LXC for services

  • Proxmox VE hosts your hypervisor layer, enabling VMs and LXC containers for lightweight, portable services.
  • VMs are ideal for heavier, isolated services (e.g., a pfSense/OPNsense firewall VM, a GitLab instance if you’re feeling ambitious).
  • LXC containers offer lightweight, fast-starting environments for apps like Nextcloud, Jellyfin, Vaultwarden, Home Assistant, and monitoring tools.

Proxmox setup quick-start guidelines

  • Create a dedicated VLAN for the management network and bind the Proxmox web UI to a management interface only. This reduces exposure.
  • Use a separate storage pool for VMs (local-lvm) and a separate pool for containers (local-zfs or another dataset if you’re comfortable with ZFS).
  • Snapshots and backups: enable periodic backups of critical VMs/containers to either a local backup dataset or an external NAS. Test restores occasionally.

A practical service catalog (minimal viable set)

  • Firewall/Router: pfSense/OPNsense VM
  • DNS/DHCP: Pi-hole or a small DNS