Make Your Homelab AI Agent Ready
homelab
claude-code
devsecops
gitlab
sonarqube

Make Your Homelab AI Agent Ready

WWade Woolwine
January 29, 20265 min read

Here's the uncomfortable truth: if you work in infra, security, or platform engineering and you don't have a place to break things on purpose, you're getting worse at your job. And if you're not practicing safe AI-agent use in that same sandbox, you're stacking two failures at once. You'll ship faster. You'll think slower.

A homelab is where you earn your scars:

  • Break stuff on purpose (real failure modes, not toy demos)
  • Build muscle memory tutorials can't give you
  • Train agents in a cage and watch how they fail

Tutorials work right up until 2 AM, when your cluster starts screaming CrashLoopBackOff and you realize the NFS mount disappeared (again).

I built a homelab where Claude Code runs real infrastructure tasks—upgrades, provisioning, troubleshooting all while boxed in by access controls, secrets scoping, logging, and quality gates. If your plan is "Claude has SSH," your plan is a smoking hole.

The Foundation: Hardware and Network Architecture

My homelab does three+ things:

  • Cloud-native experimentation
  • Product security tooling
  • A safe sandbox where Claude Code (and other agent frameworks) touches real infrastructure
  • Anything I want to explore and test (like N8N, where I'm building a bunch of automations)

Compute

  • 3 bare-metal boxes running Proxmox
  • 1 GPU box (4x Tesla V100S) for AI workloads

Storage

  • 42TB TrueNAS for backups and shared storage

Network

  • 4 zones: trusted, untrusted, control-plane, production
  • Pi-hole for DNS (and DHCP where needed), with explicit allow/deny between zones
  • NGINX Proxy Manager for anything that isn't inside the cluster

Kubernetes + delivery

Stateful services

  • Redis, Postgres, MariaDB, ChromaDB, Mem0, Neo4j

Managing this infrastructure becomes a part-time job. I lean on Claude Code—but making it safe took real engineering.

Access Control: Giving Claude the Keys (Carefully)

I gave Claude an SSH key. Then I treated it like a loaded weapon and scoped it down until it could do useful admin work without trashing my hosts.

What I implemented:

Identity + SSH

  • Dedicated account: Claude has its own dedicated user account on each system
  • Constrain the SSH key (authorized_keys): Allow only safe SSH features (no TTY, no port/X11/agent forwarding)

Privilege boundaries

  • Hardened sudo with explicit allowlists + safe defaults: Use a dedicated sudoers file with exact command paths, minimal arguments, env_reset/secure_path, and TTY + logging enabled—no shells, no interpreters, no "anything goes" wildcards.
  • Remove privilege-escalation tools from the sudo surface: Don't allow commands that can spawn shells, edit arbitrary files, or escape to root (editors, pagers, scripting runtimes, docker/kubectl/ansible, file-archivers with write capability).
  • OS-level confinement (SELinux/AppArmor/systemd sandboxing): Enforce mandatory access controls and/or run privileged actions in locked-down systemd units so even "allowed" commands can't read/write outside defined boundaries.

Network + data controls

  • Restrict network egress and lateral movement: Apply egress allowlisting (host firewall + security groups/proxy) so the agent can only reach required endpoints (e.g., git/artifact repos) and can't scan or exfiltrate data freely.
  • Strict secrets hygiene: Keep secrets out of the agent's reachable filesystem (use a secrets manager, least-privilege service accounts, and redaction) because agents will eventually read and echo what they can access.

Auditability + scope

  • High-fidelity auditing and session recording: Log sudo I/O, SSH sessions, and privileged file/network events (auditd/FIM + centralized logs) so you can reconstruct exactly what happened when things go sideways.
  • Clear boundaries: Claude handles maintenance, frees disk on GitLab runners, runs upgrades, and creates Proxmox containers—nothing else.

Logging

I log everything. Grafana aggregates it and alerts me in Discord.

Claude could explore. I don't let it. I wrote an infrastructure engineer skill that spells out my stack (Proxmox, NGINX Proxy Manager, Pi-hole, the whole mess), shows safe example commands, and draws a bright line between allowed and forbidden actions. Think of it as a constitution: what Claude can do, what it can't, and how I audit it.

My last fail-safe is boring on purpose. Backups. Tested restores. I don't trust a backup until I've watched it come back to life.

Secrets Management: The Non-Negotiable

I use HashiCorp Vault for secrets. Every username/password, API key, and non-SSH credential lives there. For Claude's access, I created:

  • A specific role with associated policy and token
  • Read and write permissions scoped to what Claude needs
  • Vault integration into Kubernetes so application secrets are readily available during deployments

Vault also holds keys for external services like Cloudflare. Claude uses those to create tunnels, update DNS, and wire up deployments. That's real power, which means you need real guardrails.

This is the one that should keep you up at night if you're not doing it right.

Rules I follow:

  • Never give an agent direct access to credentials without scoping + audit trails
  • When onboarding a new API service, I ask Claude for the minimum explicit permissions required for the task
  • If Claude asks for too much, that step becomes manual-only until I can scope it safely

Quality Gates: Trust But Verify

Here's the thing. If you build with agents like Claude, your repos and pipelines must catch quality and security problems before you merge. Never assume Claude writes secure, quality code. I've watched assistants build what I explicitly rejected—and slip in subtle security bugs that look fine at first glance.

In my CI/CD pipelines, I run:

  • A variety of open-source tools for quality and security verification
  • SonarQube as a cross-language quality and SAST tool
  • Blocking gates on critical and high security issues

Claude and I don't merge on vibes. The pipeline checks quality and security, and it blocks the merge when it finds something ugly.

These controls matter only if Claude can see findings and fix them. I built two MCP servers that connect Claude to GitLab and SonarQube, so it can pull pipeline results and remediate quality and SAST issues.

The Scale Problem of Going Agentic

I run strict TDD—80%+ coverage plus full end-to-end tests—but it still can't prove Claude matched my intent at scale.

Think about that. By hand, a good weekend meant 500 to 1,000 lines. With Claude, it's 10,000 to 50,000. That's not "a bit more." That's a firehose.

I can't review every line like I used to. So the gates aren't a nice-to-have. They're the only thing standing between speed and a repo full of landmines.

What's Next

If you want an agent-ready homelab, start here:

  • Build a homelab: One Proxmox box gives you a playground
  • Learn the tools: SonarQube, GitLab CI, HashiCorp Vault—these make AI-assisted development safe
  • Assume defects: Build verification into pipelines from day one
  • Split roles: Let Claude run routine infra tasks while you handle architecture and decisions

People who can run AI agents safely are going to run circles around everyone else. Build the homelab. Break it. Put the agent in a cage. Then bring those habits to work without setting your employer's systems on fire.

If you're looking for a SonarQube community edition MCP server or a Gitlab community edition MCP server, checkout my Github