The homelab Kubernetes space has matured dramatically. What used to require expensive enterprise hardware and arcane configuration can now be done on used enterprise servers from eBay, mini PCs, or even Raspberry Pi 5s. The tooling has caught up to where building a genuinely production-grade home cluster is accessible and fun rather than masochistic.
Here’s the complete stack I’d recommend for a serious homelab Kubernetes setup in 2026—the kind where you’re actually learning skills that transfer to production environments, not just running toys.
Hardware Considerations
You don’t need much. A functional homelab cluster can run on:
Minimal (learning/development):
- 3x Intel NUC or comparable mini PC
- Each: 32GB RAM, 500GB NVMe, 2.5Gbps NIC
- Cost: ~$600-900 total
Solid homelab:
- 3-5x used Dell PowerEdge R630/R730 (eBay: $150-300 each)
- Each: 64-128GB RAM, 1TB SSD
- More RAM = more room for learning
High-end:
- AMD EPYC or recent Xeon-based servers
- ECC memory, IPMI/iDRAC for remote management
- 10Gbps networking
For storage, you’ll want at least 3 nodes with local disks for Longhorn replication. SSDs for your etcd and fast storage; HDDs are fine for bulk data if you separate disk pools.
The OS: Talos Linux
For a serious homelab, Talos Linux is the right choice. No SSH, no shell, managed entirely through the Talos API. It’s what you’d run in a well-configured production environment, and it eliminates an entire class of configuration drift and security problems.
# Talos bootstrap
talosctl gen config my-homelab https://192.168.1.10:6443
# Apply config to control plane node
talosctl apply-config --insecure --nodes 192.168.1.10 --file controlplane.yaml
# Bootstrap the cluster (first control plane only)
talosctl bootstrap --nodes 192.168.1.10
# Get kubeconfig
talosctl kubeconfig --nodes 192.168.1.10
If you want an easier on-ramp with more familiar operations, RKE2 is a solid alternative with good CIS compliance defaults.
The Platform Stack
This is what you install once and then build everything on top of:
1. Flux for GitOps
Everything managed from a Git repository. Every change goes through Git. No kubectl apply from your laptop.
flux bootstrap github \
--owner=your-username \
--repository=homelab \
--branch=main \
--path=clusters/homelab
2. MetalLB for Load Balancer Services
Without MetalLB, LoadBalancer services stay in Pending forever on bare metal:
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: homelab-pool
namespace: metallb-system
spec:
addresses:
- 192.168.1.200-192.168.1.250 # Reserve in your DHCP server too
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: l2-advertisement
namespace: metallb-system
3. NGINX Ingress Controller
Single ingress point for all HTTP/HTTPS traffic:
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: ingress-nginx
namespace: ingress-nginx
spec:
chart:
spec:
chart: ingress-nginx
values:
controller:
service:
loadBalancerIP: 192.168.1.200 # Pin to a specific MetalLB IP
metrics:
enabled: true
serviceMonitor:
enabled: true
4. cert-manager for Automatic TLS
Free TLS certificates from Let’s Encrypt (or self-signed for internal services):
# Let's Encrypt DNS-01 challenge for wildcard certs
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
email: [email protected]
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-prod-key
solvers:
- dns01:
cloudflare:
email: [email protected]
apiTokenSecretRef:
name: cloudflare-api-token
key: api-token
Once deployed, getting a wildcard cert for your home domain is automatic:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: wildcard-homelab
spec:
secretName: wildcard-homelab-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- "*.homelab.yourdomain.com"
5. Longhorn for Storage
Distributed block storage using your nodes’ local disks:
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: longhorn
namespace: longhorn-system
spec:
values:
defaultSettings:
defaultReplicaCount: 2 # 2 replicas for 3-node cluster
backupTarget: "s3://homelab-backups@us-east-1/"
6. kube-prometheus-stack for Observability
Complete observability: Prometheus + Grafana + Alertmanager + Loki:
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: kube-prometheus-stack
namespace: monitoring
spec:
values:
grafana:
ingress:
enabled: true
ingressClassName: nginx
hosts:
- grafana.homelab.yourdomain.com
defaultDashboardsEnabled: true
7. Vault for Secret Management
For a production-grade homelab, HashiCorp Vault provides centralized secret management:
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: vault
namespace: vault
spec:
values:
server:
ha:
enabled: true
replicas: 3
storage: longhorn
ingress:
enabled: true
ingressClassName: nginx
hosts:
- host: vault.homelab.yourdomain.com
Or keep it simple with SOPS for secrets in your Git repo—perfectly appropriate for homelab scale.
What to Run on It
Once the platform is running, the fun begins. Common homelab applications:
- Immich: Self-hosted Google Photos alternative
- Gitea + Woodpecker CI: Self-hosted Git + CI/CD
- Authentik: Identity provider (SSO for all your apps)
- Paperless-ngx: Document management
- Home Assistant: Home automation
- Jellyfin or Plex: Media server
- Actual Budget: Personal finance
- Nextcloud: Self-hosted Google Drive
The point isn’t just to run these apps—it’s to practice the patterns you’d use in production. Every app you deploy with Helm and GitOps, every ingress you configure, every PVC you provision is skill building.
Backup Strategy
A homelab isn’t production, but you still don’t want to lose your data:
- Longhorn → S3: Longhorn backs up volumes to S3-compatible storage (Backblaze B2 is cheap)
- Velero: Kubernetes resource backup including PVCs
- GitOps repo: Your configuration is already in Git—it’s backed up
For photos and important data, the 3-2-1 rule still applies: 3 copies, 2 different media, 1 offsite.
The Learning Value
A homelab Kubernetes cluster run this way teaches skills that directly transfer:
- GitOps workflows identical to enterprise usage
- Helm chart development and management
- Kubernetes networking, storage, and security
- Certificate management and TLS
- Observability stack operation
- Incident response (your cluster will break; debugging it is educational)
The difference between homelab Kubernetes and enterprise Kubernetes is scale and SLAs, not fundamentally different technology. The patterns are the same. The tools are the same. That’s what makes it worth doing properly.
