Tech-kutak
Sign in Subscribe

Building tomorrow, one prompt at a time

Build a Pragmatic Self-Hosted Homelab: From Bare Metal to Automated Ops

Ivan Horvatić 7 min read
Build a Pragmatic Self-Hosted Homelab: From Bare Metal to Automated Ops

If your homelab looks impressive on paper but never ships in practice, you’re not alone. The real value of a self-hosted environment isn’t pretending to be a mini production; it’s learning through friction, delivering repeatable recipes, and growing automation muscle without sinking money into vanity gear. This article is a field-tested playbook for building a focused, maintainable homelab that actually teaches you something and pays you back in fewer headaches later.

Why a pragmatic homelab matters

  • It’s not a tech showcase; it’s a learning engine. A well-scoped lab helps you master virtualization, containers, IaC, CI/CD, and monitoring without becoming a full-time ops engineer.
  • It forces you to confront reliability and security early. If you can make backups, recoveries, and secure access in a lab, you’ll scale those skills to real deployments.
  • It’s a tax write-off you can’t predictably cash in, but it delivers compounding value: faster local development, offline backups, and private tooling that reduces cloud spend.

The approach I advocate

  • Start with a minimal but solid base. Pick a target stack you can actually maintain, not the entire modern stack you see in flashy blogs.
  • Embrace GitOps from day one. Store your infrastructure and application manifests in a versioned repo, automate deploys to a reproducible environment, and keep a clear rollback path.
  • Keep it boring, predictable, and observable. A boring stack with good metrics, logs, and backups beats a flashy stack that’s fragile.

Minimal viable architecture

Your lab can be effectively small and still be a powerhouse. Here’s a practical baseline that balances hardware, cost, and learnings:

  • Hypervisor/VM host: Proxmox VE or bare-metal Linux with KVM
  • Core services: 2–3 hosts total (a small cluster)
  • Primary: Proxmox host with 16–32 GB RAM and extra NVMe for fast VM storage
  • Secondary/backup: A modest machine or NAS for backups and some containers
  • Containerization: Docker inside Proxmox LXC or Proxmox VMs for clean separation; optional Kubernetes (k3s) if you’re itching to practice cluster ops
  • Storage: ZFS on the primary host for simple, reliable storage pools; snapshots for backups
  • Networking: VLANs if you can, otherwise flat network with a robust firewall and per-app access controls
  • DNS and identity: Unbound/DNS or Pi-hole for ad-blocking DNS; local DNS with static records for your services
  • Security and access: SSH keys, MFA on management interfaces, a VPN for remote access
  • Observability: Prometheus + Grafana, node-exporter, blackbox/blackbox-exporter for uptime checks; Loki/Tempo optional
  • Backup/DR: Restic or BorgBackup to a separate storage target; offsite replication if feasible

Hardware options and a sane rule of thumb

  • Reuse and repurpose: A consumer-grade PC with ECC RAM is nice but not strictly necessary. If you have a spare workstation with 16–32 GB RAM, you’re already in a good spot.
  • Budget-friendly: A modern quad-core PC or a used small server (think Dell/HP microservers) with 16–32 GB RAM, NVMe for caching, and a decent PSU.
  • Small cluster for learning: A couple of Raspberry Pi 4/400s can be enough to learn Kubernetes basics and simple service orchestration; pair with a central NAS and a robust Proxmox host.
  • Storage considerations: Get at least one fast SSD/NVMe for the OS and VM storage; a HDD pool can handle large data, but avoid using spinning disks as your boot pool if you want predictability.

A practical starter setup (example hardware)

  • Proxmox host: Dell OptiPlex or a small HP ProLiant with 16–32 GB RAM
  • Secondary: A cheap NAS or a repurposed NAS device with 4–8 TB usable storage
  • Networking: A small managed switch; a basic firewall appliance (pfSense/OPNsense on a dedicated box or VM)
  • DNS and VPN: A Pi-hole VM or container, plus WireGuard on a management host
  • Optional learning cluster: 2x Raspberry Pi 4 (4–8 GB) or a single powerful Raspberry Pi 4 + k3s on the Proxmox host

A simple software stack that scales

  • Base virtualization: Proxmox VE
  • Orchestration: Docker (for apps) with optional k3s (for a tiny Kubernetes cluster)
  • Configuration management: Ansible or Terraform for consistent provisioning
  • GitOps: ArgoCD or Flux for Kubernetes; or a Git-based workflow with Ansible playbooks and a local runner
  • CI/CD: Self-hosted GitLab Runner, or Jenkins with a small agent pool
  • Monitoring/Observability: Prometheus (node_exporter), Grafana, Alertmanager
  • Storage: ZFS on the Proxmox host, Restic/BorgBackup for backups
  • Ingress and TLS: Traefik or Nginx Proxy Manager
  • Logging: Loki or a simple EFK stack if you’re into logs

A concrete starter after you acquire hardware

  • Install Proxmox on the primary host
  • Create a VM for a DNS/DNSSEC and Pi-hole
  • Create a VM for a CI/CD runner or GitLab Runner
  • Create VMs or LXC containers for a small app stack (WordPress, Wiki, internal tools)
  • Add a NAS-backed storage dataset for backups
  • Install Prometheus node_exporter on the VMs and configure Grafana
  • Deploy a GitOps workflow for your infrastructure: store your Proxmox templates, VM provisioning, and app manifests in a repo; run Ansible to apply configs

A sample, boring but effective starter playbook and templates

  • Ansible basics: install Docker on Debian, set up a simple container, and ensure it runs on boot

Example: Ansible playbook to install Docker

  • hosts: all

become: yes

tasks:

  • name: Ensure apt cache is up to date

apt:

update_cache: yes

cache_valid_time: 3600

  • name: Install required packages

apt:

name:

  • apt-transport-https
  • ca-certificates
  • curl
  • gnupg-agent
  • software-properties-common

state: present

  • name: Add Docker GPG key

apt_key:

url: https://download.docker.com/linux/debian/gpg

state: present

  • name: Add Docker repository

apt_repository:

repo: deb [arch=amd64] https://download.docker.com/linux/debian {{ ansible_distribution_release }} stable

state: present

  • name: Install Docker Engine

apt:

name: docker-ce

state: latest

  • name: Ensure docker group exists

user:

name: "{{ ansible_user | default('root') }}"

groups: docker

append: yes

  • name: Start and enable Docker

systemd:

name: docker

state: started

enabled: yes

Example: docker-compose for a small app

version: '3.8'

services:

app:

image: nginx:alpine

ports:

  • "8080:80"

networks:

  • appnet

db:

image: mariadb:10.5

environment:

MYSQL_ROOT_PASSWORD: example

volumes:

  • db_data:/var/lib/mysql

networks:

  • appnet

networks:

appnet:

volumes:

db_data:

GitOps in practice

  • Store everything as code: VM birth templates, Docker Compose files, Kubernetes manifests
  • Use a single source of truth: a Git repo with branches like main, dev, prod
  • Automate drift detection: a nightly job that checks currently deployed state against repo state and reports diffs
  • Rollbacks: versions in Git; for apps, revert to the previous manifest; for infrastructure, revert to a previous VM/template snapshot

Backups, disaster recovery, and data safety

  • Snapshots: Use Proxmox to snapshot VMs before major changes
  • Offsite backups: Mirror important data to a separate location (cloud or another site) at least weekly
  • Verification: Regular restore drills to ensure you can recover quickly
  • Data hygiene: Separate data from apps where possible to simplify backups and restores

Networking and security: pragmatic defaults

  • Firewall first: Put a firewall in front of your homelab; don’t expose arbitrary services to the internet
  • SSH hardening: Use SSH keys only, disable password auth, consider a non-standard port, and use fail2ban or similar
  • TLS everywhere: Use free TLS certs via Let’s Encrypt; automate renewal with your reverse proxy (Traefik or NGINX Proxy Manager)
  • VPN for remote access: WireGuard or OpenVPN; only allow admin IPs to admin interfaces
  • Secrets management: Use a secret store (Sops + Vault/Sealed Secrets) or at least AES256-encrypted environment variables in your apps

Operational discipline: 3 knobs that drive success

  • Documentation: A living wiki for your lab (what’s deployed, how it’s configured, why decisions were made)
  • Change control: Use a PR workflow for any infrastructure change; avoid ad-hoc tweaks on production-like environments
  • Incremental upgrades: Don’t upgrade everything at once; test changes in dev, then move to prod in small steps

Day-2 operations: observability without drowning

  • Focused metrics: uptime, latency, error rates, resource usage, and backup success
  • Alerts that matter: alert only on actionable conditions; suppress noisy signals
  • Logs that are searchable: centralize logs for the core services; keep only what you need for debugging
  • Maintenance window: schedule a monthly “housekeeping” time for updates and review of your automation

A realistic deployment scenario (step-by-step)

1) Define goals and constraints: What do you want to learn? What services will you run? What’s the budget?

2) Buy and assemble hardware: A Proxmox host, a NAS for storage, a small switch, and a VPN gateway if remote access is needed.

3) Install Proxmox on the primary host. Create a VM for DNS/Pihole, a VM for the CI runner, and a storage-backed VM or LXC for your apps.

4) Deploy monitoring: Install Prometheus and Grafana; add node_exporter to each VM.

5) Set up backup: Create a Restic backup job to push backups to the NAS; test restore.

6) Add a GitOps workflow: Put your VM provisioning and app manifests into a Git repo; configure ArgoCD or Flux if you’re on Kubernetes; otherwise, script Ansible to converge desired state.

7) Harden exposure: Put Traefik/Nginx Proxy Manager in front of your apps; configure Let’s Encrypt TLS.

8) Iterate: Add a new service; codify its provisioning; ensure it’s covered by a backup and a monitoring alert.

Common mistakes and how to avoid them

  • Over-engineering early: It’s easy to chase the latest trend. Start with a simple stack you can actually operate. Only add Kubernetes if you have a concrete reason.
  • Skipping backups: Never assume backups will happen automatically. Test restores regularly, and keep offsite copies.
  • Ignoring security: A lab that’s open to the internet invites trouble. Start with a closed environment and expose only what you truly need, with strong authentication.
  • Fragmented tooling: Choose a coherent stack and stay with it for a while. Fragmentation creates maintenance drag and drift.

A 30/60/90-day ramp you can steal

  • 0–30 days: Build the minimal Proxmox host, set up a DNS/VPN container, a monitoring box, and backup storage. Document everything.
  • 30–60 days: Add a CI/CD runner, an app VM, and a basic GitOps flow for your VM/state. Introduce a small Kubernetes cluster (k3s) if you’re ready.
  • 60–90 days: Harden security, implement TLS, create a proper backup/DR plan, and automate more of the provisioning with Ansible/Terraform. Start removing manual steps; codify what you deploy.

A short, actionable conclusion

  • Start small with a single Proxmox host and one or two VMs that cover DNS, app hosting, and CI. Build from there with a focus on automation and backups. Document every decision, keep security tight, and use Git as the single source of truth. If you can’t automate it, you can’t scale it—so automate the boring parts first: provisioning, backups, and monitoring. Then iterate toward a more capable, sustainable, and learnable homelab.

Remember: the goal isn’t to imitate production gear; it’s to build a controlled learning environment that makes you faster and more confident with real-world ops.