Building My Own Cloud at Home: Homelab the Best DevOps Investment
One of the biggest challenges in learning infrastructure and system architecture in depth is that it’s very hard to replicate. It’s a lot like learning to swim. You can read every book about it, watch hours of videos, memorize the technique, but until you actually get in the water, you don’t really know how to swim. Cloud and DevOps work the same way. It’s not just about designing an architecture on paper. It’s about considering countless cases and choosing the right compromise and balance for your needs. Various edge cases come up only when you maintain real systems over a long period of time.
After trying different approaches, I found that one of the best investments you can make as an engineer in this arena is building and maintaining a homelab. It gives you hands-on experience with the underlying networking of cloud platforms, a real environment to practice Kubernetes, and a playground to run services and applications that you actually depend on. When something breaks, you fix it not because a tutorial told you to, but because a part of your system is down.
In this article, I want to walk you through my homelab setup and share how I built a complete, production-grade infrastructure on a single bare-metal server at home.
What I Built (And Why It Looks Like This)
My homelab runs on a single bare-metal server with Proxmox VE as the hypervisor, with plans to expand to a multi-server setup in the future for high availability. Everything on top of it is provisioned via code, configured via automation, and deployed via GitOps.
Here’s the high-level architecture:
Let me walk you through the layers.
Layer 1: The Foundation (Proxmox + Terraform)
Proxmox VE is an open-source server virtualization platform. It is a Type 1 hypervisor that runs directly on bare metal with a web-based management interface. Think of it as your own private cloud. It runs VMs and lightweight LXC containers.
To manage all these resources in Proxmox, I am using Terraform as the IaC (Infrastructure as Code) platform. The infrastructure is split into two completely separate environments:
Development Environment — An Ubuntu-based Kubernetes cluster (1 master + 2 workers) meant for experimentation. This is where I break things. New tools, new configurations, and new ideas all get tested here first. The VMs are provisioned from cloud-init templates, so spinning up a fresh cluster is a terraform apply away.
Production Environment — This is where real services live. It consists of a Talos Linux Kubernetes cluster (1 control plane + 2 workers) and several lightweight LXC containers running standalone services. Talos was a deliberate choice here. It’s a Kubernetes-optimized Linux distro that’s immutable and API-managed, meaning there’s no SSH, no shell, and no way to accidentally misconfigure something by hand.
The LXC containers in production handle services that don’t need Kubernetes overhead: Pi-hole for DNS, HashiCorp Vault for secrets, Traefik for reverse proxying, a TurnKey NAS for file storage, n8n for automation, and Homepage for a centralized dashboard. These boot up very quickly and are lightweight.
Why the separation? The dev cluster gets destroyed and rebuilt regularly. The prod cluster stays stable. This mirrors how real companies operate, and learning to manage that boundary is invaluable.
Layer 2: Configuration Management (Ansible & TalosCtl)
Once Terraform provisions the bare VMs for the development cluster, Ansible takes over for configuration. It handles everything from base OS setup to Kubernetes cluster bootstrapping:
- Installing containerd and Kubernetes packages across all nodes
- Initializing the control plane with
kubeadm - Joining worker nodes to the cluster
- Setting up ArgoCD for GitOps deployment
- Configuring NFS clients for distributed storage
The entire process is a single command:
ansible-playbook playbooks/site.yaml -e @secret.yaml --ask-vault-passFrom zero to a fully functioning Kubernetes cluster. All secrets are encrypted with Ansible Vault, so sensitive data like IPs and credentials never appear in plaintext in the repository.
For the production Talos cluster, Ansible isn’t needed — Talos is configured entirely through its own declarative API with config patches and talosctl. The config files are encrypted with SOPS (using age keys), maintaining a consistent security posture across both environments.
Layer 3: GitOps (ArgoCD)
This is where things get elegant. Once the clusters are up no need to dokubectl apply anything manually. ArgoCD watches the Git repository and automatically syncs the desired state to the clusters.
The repository uses a Kustomize-based structure with base manifests and environment-specific overlays:
argocd/
├── apps/
│ ├── monitoring/ # Prometheus + Grafana
│ ├── gitea/ # Self-hosted Git
│ ├── harbor/ # Container registry
│ └── nfs_provisioner/ # Distributed storage
├── environments/
│ ├── dev/ # Dev-specific overrides
│ └── prod/ # Prod-specific overridesEach environment has its own App of Apps, a root ArgoCD application that bootstraps all other applications. Push a change to the repo, and ArgoCD picks it up, diffs it, and applies it. Want to deploy a new service? Add the manifests, push, done.
The ArgoCD Vault Plugin integrates with HashiCorp Vault to inject secrets at deploy time, so sensitive values never exist in the Git repository, not even in encrypted form.
Layer 4: Networking & Access (Traefik, Pi-hole, Cloudflare)
Networking is one of those things that looks simple on a diagram but gets complicated fast in practice. This setup addresses three distinct problems:
Local DNS (Pi-hole): Every device on my network uses Pi-hole as its DNS server. Beyond ad-blocking, it serves as the local DNS resolver for my internal domain.
Reverse Proxy (Traefik): A Traefik instance running on a dedicated LXC container serves as the HTTPS entry point for the entire homelab. It resolves internal certificates and traffic
External Access (Cloudflare Tunnel): For services that need to be accessible from outside the local network, Cloudflare Tunnel provides a secure path without exposing any ports on the home router. No port forwarding, no dynamic DNS headaches.
Get Parvez Hossain Saurav’s stories in your inbox
Join Medium for free to get updates from this writer.
The flow looks like this:
Client → Pi-hole DNS (*.phsaurav.net → Traefik IP) → Traefik (:443) → Backend serviceEvery service is accessible over HTTPS with a valid certificate. Locally. On a homelab.
Layer 5: Secrets Management : (HashiCorp Vault + SOPS + Ansible Vault)
It’s tempting to skip proper security in a homelab since nothing is public-facing. But secrets have a way of leaking through a careless Git push, a hardcoded password in a config file, or a backup that ends up in the wrong place.
My setup uses a layered secrets strategy:
- HashiCorp Vault: The central secrets engine running on a dedicated LXC container. Integrated with ArgoCD via the Vault Plugin for runtime secret injection into Kubernetes workloads.
- SOPS: Encrypts Talos cluster configurations (certificates, networking secrets) in the Git repository using age keys using AWS KMS.
- Ansible Vault: Encrypts inventory secrets used during configuration management.
The philosophy is simple: no secret should ever exist in plaintext in the repository. Different tools handle different layers because each has its strengths: Vault for runtime application secrets, SOPS for infrastructure configs, and Ansible Vault for provisioning data.
Layer 6: Observability (Prometheus + Grafana)
Running infrastructure without monitoring is driving with your eyes closed. The homelab runs a full Prometheus + Grafana monitoring stack deployed through ArgoCD on both clusters:
- Prometheus scrapes metrics from all nodes and tracks Kubernetes state via kube-state-metrics
- Grafana visualizes everything through dashboards.
Both use NFS-backed persistent volumes, so data survives pod restarts. The monitoring stack itself is Kustomize-managed with environment-specific PVC sizes (dev gets smaller allocations, prod gets more headroom).
This is one of those things you don’t appreciate until something goes wrong. When a worker node starts running low on memory, or a pod enters a crash loop, Grafana shows it before you notice symptoms.
Layer 7: Self-Hosted Services (Gitea, Harbor, NAS, Homepage)
Beyond the infrastructure itself, the homelab hosts services that support development workflows:
Gitea: A lightweight, self-hosted Git service. Private repositories, CI hooks, and the satisfaction of owning your code hosting. Deployed via ArgoCD with persistent storage on NFS.
Harbor: A self-hosted container image registry. When you’re building and deploying containers within the homelab, having a local registry eliminates the dependency on Docker Hub and keeps image pulls fast. It can also be used as a caching layer to bypass image pull limits.
TurnKey NAS: A very lightweight file server running on an LXC container, providing NFS storage that’s consumed by the Kubernetes clusters for persistent volumes and as a NAS system for my whole network
Homepage: A centralized dashboard running on its own LXC container that ties everything together. One URL to see the status of every service at a glance.
The Physical Setup
You don’t need enterprise hardware to start homelabbing. As the base server, I bought an HP MP9 G4 with an Intel i5–8500T 6-core processor, 16GB RAM, and a 256GB SSD for around $170, with a 3-month warranty, from the second-hand market. The performance has been very stable.
After that, I added another 16GB of RAM for $40 and upgraded the storage with an additional SSD for $70, bringing the total to around $280, with a final configuration of an i5–8500T 6-core, 32GB RAM, and two SSDs totaling 1.5TB of storage. A comparable compute setup on a cloud provider like AWS would cost over $100 every month, while this machine draws an average of only 30W of power.
When choosing hardware, here are a few things I considered that might help you as well:
- Supports VT-x and VT-d from the firmware, which makes virtualization performant
- Uses a T-series processor that is very energy efficient
- RAM and NVMe storage are both upgradeable
- Spare parts are widely available, making it a reliable long-term investment
Should You Consider One?
If you are someone interested in infrastructure, cloud, DevOps, and Kubernetes, someone who wants to know what happens after git push and what it takes to maintain a system with high availability, security, and scalability over time, homelabbing gives you the perfect environment to learn, break, and experiment. On top of that, you get practical benefits like your own NAS, network-wide ad blocking with Pi-hole, and a self-hosted dashboard, all at a fraction of what similar compute power would cost on any cloud provider.
You don’t need to replicate my setup. Start with Proxmox on any spare machine, spin up a couple of VMs, install Kubernetes the hard way (or the kubeadm way), and start breaking things.
The gap between “I deployed to Heroku” and “I understand how production infrastructure works” is enormous. A homelab bridges that gap in a way no tutorial, course, or certification can. Because it’s yours, it’s real, and it will break in ways you never expected.
The entire setup is open-source. Feel free to explore, fork, or use it as a reference for your own:
