From Zero to Self-Hosted DevOps: A Practical Homelab Blueprint

Ivan Horvatić 28 Jul 2026 5 min read

I built my homelab to feel less like a pile of gadgets and more like a productive, repeatable platform. The truth is: you don’t need a data-center-sized footprint to ship real software, run reliable CI pipelines, or learn scalable ops patterns. You need discipline, a sensible stack, and a clear path from “I have a thing” to “this thing is repeatable, observable, and recoverable.” This article lays out a practical blueprint you can actually implement in a spare corner of a home office — with real-world choices, concrete steps, and the occasional contrarian stance you’ll recognize from long nights wrestling automation.

Why you should care about a practical homelab

It’s the safest playground for release engineering, IaC, and disaster recovery without risking customer data or production SLAs.
It makes you faster at debugging in production because you’ve already lived through failure modes locally.
It gives you a portable, reproducible baseline for job interviews, side projects, and personal automation experiments.

A lean hardware foundation: what to buy and why

You don’t need a rack full of hardware to start. The goal is a predictable, upgradeable baseline you can scale from.

Starter hardware:
A used server or a consumer-grade machine with 8–16 cores and 32–64 GB RAM. If you’re lucky, you’ll find a former office server with ECC-capable memory. ECC is nice but not strictly necessary; prioritize quiet operation, decent RAM, and a reliable PSU.
Fast storage: at least 1–2 TB NVMe for the host OS and critical services, plus a larger HDD/SSD pool for data. If you can swing it, a small ZFS pool (or btrfs) gives you simple snapshots and redundancy.
Networking:
A reliable router/firewall (pfSense or OPNsense on dedicated hardware, or a consumer router with VLAN support). Consider a separate Unifi AP if you want wireless separation for guests and devices.
A managed switch with VLAN support so you can separate management, workloads, and backups.
Power and cooling:
A simple UPS to cover graceful shutdowns during outages. Homelabs aren’t climate-controlled data rooms; they’re meant to be quiet and energy-conscious.

If you’re starting from scratch, a compact, quiet server with 32 GB RAM and a pair of NVMe devices will serve most projects well for 12–18 months before you outgrow it.

Virtualization: Proxmox as your base layer

Proxmox VE is my default starting point for a practical homelab. It’s cheap (free community edition), rock-solid, and it makes it painless to split the hardware into multiple VMs and containers. You’ll want:

Proxmox install on bare metal or a dedicated drive
A few VMs or LXC containers for core services
A separate VM or two for Kubernetes (or micro-cluster) nodes if you’re going container-native
Regular backups of VMs and containers (Proxmox snapshotted or offloaded to a NAS)

Why not just run everything in containers on a single host? You can, but a two-node-ish cluster (or a VM-based cluster) gives you realistic failover scenarios and makes you practice upgrades and migrations without wrecking your entire stack.

A pragmatic stack: Kubernetes vs. lightweight clusters

There’s a lot of hype around Kubernetes, but you don’t need a full-blown, multi-master cluster to get value. In a homelab, you’ll often be better off with:

K3s (or K3d) for a small, easy Kubernetes footprint
Or, even simpler: Docker Compose with a small orchestration layer like Portainer or Rancher Desktop for a more digestible experience

What I recommend:

Start with K3s on 1–2 nodes (master + worker) in Proxmox VMs or LXC containers. It’s low friction, and you’ll learn cluster concepts (namespaces, RBAC, resource limits) without wrestling with multi-master complexity.
For non-Kubernetes workloads, run classic Docker Compose stacks (or Podman Play/Compose) on a dedicated VM to mirror real-world deploy steps.

A practical, reproducible CI/CD story

DevOps is not just about code; it’s about pipelines, reproducibility, and observability. You’ll want a small set of services that enable you to push code, run tests, build artifacts, and deploy to your homelab environment.

Source control: self-hosted Gitea or GitLab CE. Gitea is lightweight and easy to run; GitLab CE provides more out-of-the-box CI but is heavier.
CI runner: if you use GitLab, you get runners integrated; if you go with Gitea, you can run Drone or a small GitHub Actions-like runner workflow (Drone + GitLab/Gitea webhook works nicely).
Artifact store: a simple minio or S3-compatible storage for build artifacts if you intend to publish containers or packages.

This combination yields a practical, reproducible pull-request-to-deploy loop that you can actually maintain in a home environment.

A minimal stack you can assemble this weekend

Hypervisor: Proxmox VE
Node 1 (control plane): Ubuntu 22.04 LTS as a K3s server (master)
Node 2 (workloads): Ubuntu 22.04 LTS as a K3s agent
Git host: Gitea in a container or VM
CI: Drone CI server (or GitLab CE)
Proxy and TLS: Traefik or NGINX plus Let’s Encrypt
Monitoring: Prometheus + Grafana (and Loki for logs if you’re ambitious)
Backups: Proxmox backup jobs, plus a separate backup VM or NAS

A concrete install and configuration rhythm (high level)

1) Proxmox setup

Install Proxmox on your chosen hardware; assign a stable management IP; enable the firewall on the host; set up a basic backup schedule to your NAS.
Create two VMs or LXC containers: a K3s master (or single-node) and a K3s worker. If you’re new, start with single-node K3s on one VM.

2) Kubernetes cluster bootstrap

Install K3s on the master: curl -sfL https://get.k3s.io | sh -
Retrieve the node token and join worker: K3s agent --server https://<MASTER_IP>:6443 --token <TOKEN>
Optional: enable a lightweight CNI (Flannel is default). Verify with kubectl get nodes.
Install Helm for package management (Helm 3).

3) Core services on Kubernetes

Deploy Traefik as the ingress controller, configured for TLS via Let’s Encrypt (ACME).
Deploy a Gitea/GitLab instance for source control.
Deploy Drone if you go with Drone-based CI; otherwise rely on GitLab CI runners or a separateCI container.
Create a sample app, wire a Git repo to CI, and set up a pipeline that builds a container image and pushes to a local registry or to an S3-compatible artifact store.

4) Local registry and storage

Run a local container registry (docker://registry:2) behind Traefik with TLS.
Use persistent volumes on Proxmox to back the cluster data, CI artifacts, and database storage.

5) Monitoring, logging, and alerting

Deploy Prometheus and Grafana via Helm. Set up a few dashboards for node health, pod status, and resource usage.
Optional Loki for logs if you’re collecting container logs.

6) Backups and disaster recovery

Proxmox can snapshot VMs/CTs; schedule weekly snapshots and nightly incremental backups to a NAS.
For Kubernetes, enable etcd snapshot or rely on K3s built-in snapshot features. If you’re not using a multi-node cluster, a clean backup of manifests and a daily container image backup can be enough for a home lab.

Networking and security: practical patterns

Separate networks with VLANs: management, clients, IoT, and backups should live on distinct subnets.
Ingress TLS: automatically renew with Let’s Encrypt via ACME and Traefik. Keep private services off the public internet unless they’re fronted by TLS and authenticated.
Access control: use RBAC in Kubernetes and tighten SSH access on your hosts. If you expose services, enable basic authentication or OIDC where possible.
Remote access: use a VPN (WireGuard) to reach your home network rather than exposing services directly to the internet.

Observability without becoming a data-dump

Start with dashboards that show:
Node CPU/memory/disk pressure
Pod status and restarts
Network latency to key services (CI, registry, git host)
Keep logs centralized but not overwhelming. Loki is nice, but if you’re new, start with basic container logs and add Loki later.

Automation playbook: what to