This is the whole thing in one place: a segmented VMware lab behind a pfSense firewall, one identity provider enforcing MFA everywhere, a full metrics-and-logs monitoring stack, and encrypted off-site backups that have actually been restored. It runs on a single gaming PC and it’s built to be operated, not just stood up — so the point of this page isn’t the parts list, it’s how they fit and what happens when one breaks.
The Lab
The home lab as one system — the topology, every component, and how it's secured. Each box links to the post where I built it.
1
inbound port — WireGuard only, all else closed
MFA
on every login, enforced centrally
3
firewall-isolated VLANs
21
components, each with a write-up
9
telemetry & egress flows
Topology at a glance
Want the design underneath it — addressing, trust zones, the firewall policy matrix? See the network design →
How it's actually run
No pretending this is a datacentre. It's a virtual lab on one machine — so here's the real operating model, including what it doesn't do yet.
Environment
Virtual
VMware VMs on a single workstation (my main PC) — a learning and build environment, not dedicated always-on hardware.
Availability
While in use
Powered up when I'm working and shut down nightly. Monitoring, alerting and log detection run during uptime — not 24/7 yet.
Backups
Two layers · restore-tested
Off-site disaster recovery: consistent DB snapshots (pg_dump / SQLite .backup), age-encrypted, pushed off the host — and restored into a throwaway container to prove they work. Local full VM clones sit alongside for fast rollback (same host, so not DR on their own).
Recovery
Returns on boot
Every service is restart:unless-stopped or systemd-enabled, so the stack comes back on its own once the machine powers on.
Secrets
Encrypted off-box
age public-key encryption; the private key is deliberately kept off the cloud storage that holds the backups.
Change control
Two agents, split roles
Claude Code makes the changes, under root-managed hooks that log every tool call to a hash-chained ledger. Kimi Code runs separately as a read-only auditor: it reports findings and ranks them, but is not allowed to remediate, and its launcher refuses to start if a policy file's checksum has changed. Neither one approves its own work — that stays with me.
Next step
Always-on host
Moving the load-bearing services onto dedicated hardware, so identity, firewall and detection stop depending on a VM that sleeps.
The machine it all runs on
No rack, no datacentre — every VM in the diagrams above lives on one desktop PC. Here's the hardware underneath, and how much of it the lab is actually given.
CPU
Ryzen 7 7800X3D
8 cores · 16 threads
GPU
PNY RTX 4090
24 GB VRAM
Memory
64 GB DDR5
6000 MHz
Storage
1 TB NVMe
+ 2 TB HDD
Hypervisor
VMware Workstation Pro
17.6.4
Cooling
360 mm AIO
10 fans · Lian Li EVO 11
What the lab actually gets
vCPU
8 of 16 threads
Memory
26 of 64 GB
Disk
333 GB virtual disk · 74 GB used
Everything on the topology diagram sits inside that one slice. The rest of the box carries Windows and the pfSense VM — which is exactly why the lab is a nightly-shutdown environment and not an always-on one.
The AI plane
Three coding agents have real access to this lab, so the interesting question is not which models run here — it is what sits between them and anything that matters. Read it top down: every tier constrains the one beneath it.
Controls
What actually stops a bad change. Deterministic, not prompt instructions.
- Human approval bound to a SHA-256 of the exact plan — edit the plan, the approval is void
- Exclusive scope claims, so two agents cannot work the same service
- Intent recorded before a change; an unsettled one blocks any automatic retry
- Fail-closed redaction on every message stored, shown, or passed between agents
Orchestration
One request, three agents, a structured review rather than three opinions.
- Round 1 answered blind and committed before anyone sees anyone else
- Round 2 each reviewer sees the others' findings as labelled data
- Further rounds only when an agent asks for one
- A fourth model merges the panel and lists unsupported claims separately
Agents
Different powers on purpose — the one that builds cannot be the one that signs off.
- Claude Code — plans, and is the only agent permitted to change anything
- Codex — implementation and test plans, review; prepares but never deploys
- Kimi — independent read-only audit, behind an integrity-checked launcher
Gateway
One endpoint for every model, with the spend limit enforced outside the caller.
- LiteLLM routes, authenticates and caps spend per virtual key
- Open WebUI for humans, behind single sign-on; the API takes keys, not logins
- Per-project keys scoped to specific models with their own budget
Observability
Every call recorded, so a claim about what an agent did can be checked.
- Langfuse traces every gateway call and every Claude Code session
- A hash-chained evidence ledger for agent tool calls, projected into the SIEM
- Tamper-evident, not tamper-proof — and the docs say so
How the three agents actually review one request: Three agents, one approval gate →
Every layer, every component
The lab as defence in depth — and every box below links to the post where I built it.
Boundary & network
A firewall VM is the only thing the rest of the lab talks to the world through — default-deny, private ranges blocked outbound, segmented into isolated zones.
pfSense firewall
runsDedicated VM · WAN + LAN 10.10.0.0/24
securedDefault-deny rules; MFA admin login
VLAN segmentation
runsVLANs 10 / 20 / 30 — Trusted, IoT, Guest
securedInter-VLAN traffic firewalled by default
WireGuard VPN
runsOn pfSense, reached from mobile data
securedKey-based, through the nested firewall
AdGuard Home
runsDocker on the Debian VM — DNS sinkhole for host + phone
securedBound to lab + tailnet IPs only; admin UI via Authentik SSO
Identity & access
One identity provider with MFA is the single login authority — for web dashboards and for the firewall's own admin login. Who you are and what you may do are decided in one place.
Authentik IdP
runsDocker on the Debian VM
securedMFA enforced centrally, group-based roles
pfSense ↔ Authentik LDAP
runsFirewall auth against the IdP
securedMFA + group admin on a device with no browser
Vaultwarden
runsDocker + Caddy, wildcard TLS via DNS-01
securedZero inbound ports; reached over WireGuard
Compute & automation
One hardened Debian VM hosts the containers and the agent workflow. It runs the services above and the monitoring below, and it's locked down as its own audited surface.
Debian VM
runsVMware host for Docker + native services
securedAuto-updates, nftables, Tailscale-only SSH, sandboxing
MCP hub
runsCustom server on the VM, over Tailscale
securedNo inbound ports, narrow tool surface
Claude Code pipeline
runsDrives the blog + lab work from the VM
securedDeterministic hooks gate posts, builds, commands
AI gateway
runsLiteLLM + Open WebUI, Docker on the VM
securedSSO for the UI, API keys for agents; no inbound ports
NetBox
runsDCIM + IPAM, Docker on the VM
securedSSO in front, its own app login behind; resource-capped
Observability & detection
Metrics answer 'what's the number', logs answer 'what happened', and alerts reach out so nothing waits to be noticed. Dashboards, alerting, and a log SIEM on one stack.
Prometheus
runsNative systemd on :9090 — loopback plus the Docker bridge, so containers can query it
securedScrapes the VM + pfSense; reachable from outside only through Caddy behind SSO
Grafana
runsDashboards over the metric + log stores
securedSSO via OIDC, admin by group membership
Alertmanager → ntfy
runsDocker :9093 → phone push
securedMetric + log alerts, formatted, loopback-bound
Loki SIEM
runsLoki + Promtail + rsyslog, in Docker
securedpfSense/auth/syslog centralised, LogQL detection
Homelab Council
runsLocal orchestrator over Claude, Codex and Kimi, with a web dashboard behind single sign-on — per-run review plus an overview of where runs stop, how each agent replied, and every approval on record
securedHuman approval bound to a plan hash; dry-run by default; the dashboard records an approval and can spend one, but holds no credential and never invokes an agent itself
Langfuse
runsTraces every Claude Code session, Docker on the VM
securedOwn app login behind Caddy; web container publishes no host port
Agent assurance plane
runsOwn systemd service + user, loopback only — audits the Claude Code agent
securedRoot-managed hooks, hash-chained ledger, reduced feed to Loki; observe-only
Resilience & edge
The parts that decide whether the lab survives a bad day: encrypted off-site backups that have actually been restored, and a physical glance display that never crosses the isolation boundary.
From signal to phone
Both halves of monitoring feed one alert path: a number crossing a threshold, or a log line matching a pattern, ends up as the same buzz in my pocket — with an all-clear when it resolves.
📈 Prometheus · metrics
🪵 Loki · logs
rules evaluate
🔔 Alertmanager
ntfy
📱 phone
🔎 investigate
Runs while the lab is up. The nightly shutdown is exactly why alert rules wait 10m before firing — so a morning boot isn't mistaken for an outage.
Every rule on that path — the live LogQL/PromQL and its ATT&CK mapping — is catalogued: See the detections →