Homelab

Kubernetes infrastructure for personal data governance with a walled-garden for AI agents

When you think about it, a hobby is just a second job that costs money...

01 Overview

The homelab serves three purposes: keeping personal data under my own control while reducing reliance on cloud subscriptions, running the same kinds of tools I use professionally, and providing a place to experiment.

It consists of a Kubernetes cluster, two NAS units, several single-purpose hosts, and a GPU-equipped mini PC for local inference. The network is managed with UniFi and split into VLANs with zone-based firewall rules; connections between zones are denied by default and permitted only where a specific need exists. No services are exposed outside the home network.

The addresses and identifiers shown on this page are simplified and do not reflect the exact configuration nor is it exhaustive; but the overall data connections and flow is still accurate.

02 Hardware

Most compute and storage connects to the main network over a 6 GHz wireless bridge. The link is stable with only a few milliseconds of added latency.

HostHardwareAcceleratorOSVLANRole
turingpi-1…4Turing Pi 2.5, 4× Turing RK1RK3588 NPUUbuntu100 / 200k3s cluster
primeradiantSynology DS423+DSM100Primary storage
deepthoughtZimaCube 2 ProRTX Pro 2000 BlackwellUnraid100 / 200Compute and storage
titanGMKtec K11, Ryzen 9 8945HSRTX 5070 Ti via OCuLinkUbuntu200Inference host
homeassistantRaspberry Pi 5HAOS100Home automation, Zigbee
agent-sandboxVM on deepthoughtUbuntu200Agent sandbox
agent-devboxVM on MacBookUbuntu200Agent sandbox

03 Services

Services are reached through NGINX Proxy Manager, which terminates TLS using certificates issued through DNS challenge verification, so internal services use certificates from a trusted CA. Local DNS rewrites in AdGuard Home point service hostnames at the proxy.

There are two proxy instances. One on VLAN 100 handles the general services. A second instance on VLAN 200, a separate network for AI agents described below, proxies only the agentic services, including the llama.cpp servers, so agent-facing endpoints are served from within the agentic subnet.

Forgejo is the exception. It takes part in bootstrapping and deploying the rest of the infrastructure, so it should not depend on the proxy. Its hostname resolves directly to the Forgejo host, with routing configured in UniFi to support git over HTTPS.

Service request paths Clients resolve hostnames with AdGuard Home and connect over HTTPS to one of two NGINX Proxy Manager instances. The instance on VLAN 100 forwards to services on the services network; a second instance on VLAN 200 forwards only to agentic services, including the llama.cpp servers on titan and deepthought. Forgejo is reached directly after DNS resolution. LAN clients Browsers, apps, agents DNS lookup adguard-home Local DNS rewrites Ad and tracker filtering HTTPS HTTPS · agentic hostnames forgejo turingpi · VLAN 100 git over HTTPS Not proxied Direct after DNS resolution nginx-proxy-manager Services instance · VLAN 100 TLS termination DNS-challenge certificates Host-based routing turingpi · k3s VLAN 100 adguard-homegatus argocdgrafana harborjenkins longhornoverleaf other personal services primeradiant · Docker VLAN 100 garage-s3 other personal services deepthought · Docker VLAN 100 other personal services VLAN 200 · AGENTIC SUBNET nginx-proxy-manager Agentic instance · VLAN 200 TLS termination DNS-challenge certificates Agentic services only turingpi · agents pool VLAN 200 openwebuifirecrawl litellmcamofox-browser searxngjenkins-agentic rk-llama.cpp titan · Docker VLAN 200 llama.cpp-titanQwen3.8:27B deepthought · Docker VLAN 200 llama.cpp-dtQwen3.6:35B-A3B
Web services are proxied through one of two NGINX Proxy Manager instances, one per VLAN. Forgejo is resolved and reached directly so that it does not depend on the proxy.

04 Agentic VLAN

AI agents read untrusted content such as web pages, issues, and dependency code, and they act on it by running commands, cloning repositories, and triggering builds. Prompt injection, a faulty reasoning loop, or an ordinary mistake could lead an agent to probe parts of the network it has no reason to reach. For that reason, all agent traffic is confined to a dedicated VLAN.

Both agent sandboxes and both llama.cpp inference servers have an interface bound to VLAN 200 with an address on the agentic subnet, so model requests from the agents never leave that network. By default, hosts on VLAN 200 cannot initiate connections to the rest of the LAN. The one intentional exception is a route to the Forgejo git host, which lets agents work on repositories for their own development and assist with development work and pull request reviews.

Agentic VLAN topology Two agent sandbox VMs, two llama.cpp servers, and other agentic services on the turingpi cluster share VLAN 200. All traffic leaving VLAN 200 crosses the gateway firewall, which allows git over HTTPS to Forgejo on VLAN 100 and denies all other new connections. VLAN 200 · AGENTIC SUBNET Agent sandboxes Inference servers agent-devbox Ubuntu VM on a MacBook Oh-My-Pi · interactive use VLAN 200 agent-sandbox Ubuntu VM on deepthought Hermes · unattended automation VLAN 200 titan · llama.cpp Mini PC, RTX 5070 Ti via OCuLink Qwen3.8:27B VLAN 200 deepthought · llama.cpp Docker container on Unraid Qwen3.6:35B-A3B VLAN 200 inference requests inference requests stays on VLAN 200 turingpi · agents pool Other agentic related services VLAN 200 Rule Flow Scope ALLOW 200 → forgejo git over HTTPS ALLOW 100 → 200 selected inbound, return traffic DENY 200 → any all other new connections Gateway firewall UniFi Cloud Gateway Max Zone-based rules, deny by default Every flow leaving VLAN 200 is inspected here VLAN 100 · SERVICES AND HOUSEHOLD LAN Storage and clusters NAS shares, Kubernetes control planes forgejo Agent accounts only Household Management UIs, personal services and devices HTTPS
Inference traffic between the agent sandboxes and the llama.cpp servers stays within VLAN 200. Anything leaving the VLAN crosses the gateway firewall, where the only outbound connections allowed are git over HTTPS to Forgejo.

Oh-My-Pi · interactive

Runs in an Ubuntu VM on my MacBook and is directed through a terminal interface. A single shared directory is the only link to the host filesystem. The VM has its own Docker daemon and toolchains, so builds and tests do not touch the host, and it can be rebuilt at any time.

Hermes · automation

Runs in a persistent VM on deepthought and handles automation without a human in the loop, responding to messages and local webhooks. Because nobody reviews its actions in real time, containment comes from the environment: the VM holds nothing of value and its network reach is limited to explicitly granted services.

Separate identities

Agents authenticate to Forgejo with dedicated accounts and organizations, and only see repositories they have been added to. Keys held by each agent are scoped to that agent and can be revoked without affecting my own credentials.

Separate CI

Agents trigger builds on their own Jenkins instance. Build pods are created on demand in an isolated namespace on a cluster node assigned to VLAN 200, so nothing persists between jobs or mixes with my own workloads.