Home Lab · Kubernetes · Generative AI · Platform Engineering

I run several small AI applications for real users. They live on free hosting, they work, and I have never seen their infrastructure. This is the blueprint for rebuilding all of it on one 20 GB laptop, layer by layer, with a free open-source tool at every layer, so I can learn how a production platform is actually put together: cluster, delivery, security, observability, AI serving, backup and cost. Beside every open-source pick there is a drop-down of the enterprise products that do the same job, so the lab maps directly onto what customers buy.

My applications are DrJhaGPT Pro (a technical-training studio grounded in my own articles), the Neevalay educator and parent bots, and a few smaller tools. They are Streamlit apps written in Python. They run on Streamlit Community Cloud, keep their data in Supabase, and get their model answers from Groq. Total monthly cost: zero. Total visibility into the platform underneath: also zero.

That is fine for a hobby. It is not fine if you want to understand how an enterprise runs the same thing, because an enterprise does not have a “Deploy” button. It has a cluster, a pipeline, a registry, an identity provider, a secrets vault, a policy engine, three kinds of telemetry, a backup schedule and a bill. I want to build all of that at home, break it, fix it, and then be able to draw it for a customer.

Step 0 · HardwareWhat one laptop can actually do

Before choosing tools, the honest inventory. Everything below was read from the machine with two PowerShell commands (Get-ComputerInfo and Get-CimInstance Win32_VideoController).

Memory cap lives in one file, C:Users<you>.wslconfig. The two “experimental” lines matter on a small machine: the first hands idle RAM back to Windows, the second stops the Linux disk file from growing forever.

[wsl2]
memory=12GB
processors=6
swap=4GB
localhostForwarding=true

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

LayoutWhere everything sits

Why k3d and not minikube or Docker Desktop’s built-in Kubernetes: k3d runs the lightweight k3s distribution as Docker containers, one per node, so you get a real multi-node cluster. That is what lets you practise draining a node, replicating storage across nodes and spreading pods with anti-affinity. A full rebuild is one command and about ninety seconds.

Layer mapEvery layer: what I have today, the free pick, and the enterprise equivalent

This table is why I wrote the post. The groups follow my Kubernetes Stack Builder, so each row is one question a platform team has to answer. Column two is the truth about today. Column three is what goes into the lab, all free and open source. Column four is a drop-down: pick any product a customer might name and the line underneath tells you where it fits and what it replaces.

Reading the drop-downs: the first entry in each list is the one I would name first in a VMware or Nutanix shop; the rest are the usual alternatives in Red Hat, SUSE and public-cloud estates. “Same” in the enterprise column means the open-source tool is what enterprises actually run, often with a paid support contract.

Order of workSix weekends, one folder each

Order matters more than tools. Each phase adds one group from the table and ends with a test you can actually run, so you know it is finished. Each phase is also a folder in the GitOps repository, which is what makes switching one off later a one-line change.

What “nothing by hand” looks like

Phase 2 is the one that changes how you work. After it, every change follows the same loop, and every later phase only adds a gate or a sensor to it.

Memory budget, honestly

What to leave out, on purpose

Kubeflow, KServe, Backstage, Istio and GitLab are all real production tools. They are also each heavier than the whole rest of the lab, and none teaches anything the table above does not. Add them when the laptop becomes a second-hand server.

Day oneFirst three commands

Inside the Ubuntu terminal, once Docker is reachable:

# install k3d
curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash

# a 3-node cluster with ports 80 and 443 mapped to the laptop
k3d cluster create homelab --servers 1 --agents 2 
  -p "80:80@loadbalancer" -p "443:443@loadbalancer" 
  --k3s-arg "--disable=traefik@server:0"

kubectl get nodes

Disabling the bundled Traefik is deliberate: the ingress controller and the CNI are the first two things the GitOps repository will install, which is exactly the habit the lab is meant to build.

Disclosure: DrJhaGPT Pro and the Neevalay bots are my own tools. Product names in the drop-downs are the vendors’ current names at the time of writing; several of the VMware products have been renamed under VCF 9 and the older Aria and Tanzu names are given in brackets where people still use them. Memory figures are what I measured on this laptop and will differ on yours.