Homelab & Self-Hosted Infrastructure

The edge: a reverse WireGuard tunnel

The home lab never exposes its own IP. Instead, a small rented node acts as an edge ingress: it holds the public IP and the DNS records, and forwards traffic to the lab over a WireGuard tunnel that the lab dials outbound. Nothing at home listens on a public address, so the residential IP never leaks. And if the edge ever takes abuse, it's a disposable lever I can null-route or rebuild without touching a single service.

The network: OPNsense, VLANs and real wires

Behind the tunnel is a network I run myself, not an ISP box with an admin page I'm locked out of. Routing and firewalling are handled by an OPNsense router that I configure and maintain, and the LAN is carved into multiple VLANs: the servers sit on one segment, trusted personal devices on another, and untrusted gear on its own island. Firewall rules decide exactly what is allowed to cross between them, so when a smart-anything misbehaves, the worst it can reach is its own little corner.

The physical layer is mine too. Every machine in this writeup hangs off switching and cable runs I put in myself, with VLANs tagged across the trunks. When a link goes flaky there's no help desk to call; tracing it back to a port, a cable or a NIC is part of the job.

Storage: TrueNAS and ZFS

Bulk storage lives on a dedicated TrueNAS box running a redundant ZFS pool. ZFS checksums every block, scheduled scrubs walk the whole pool looking for silent corruption, and snapshots give me point-in-time rollback before I trust any risky change. Managing it is a real, ongoing job: pool layout, disk health, capacity planning, and the occasional resilver when a drive starts throwing errors.

The NAS is also the backbone of the backup story. Services on the Docker host back up to it on a schedule, snapshots keep history, and a second copy still leaves the building, because redundancy inside one chassis is not a backup. Losing a disk here is an errand, not an event.

What's running

Thirty-odd containers, each defined in its own Docker Compose project, behind a reverse proxy that terminates TLS and routes each subdomain. A few of these back the links elsewhere on this site; most are just how I choose to own my own data. The AI platform gets its own section below.

Federated & social

Files & personal

Media libraries

Knowledge & archival

Operations, privacy & the boring bits

The AI platform: “Task Studio”

This is the part I'm proudest of. On top of the homelab runs a self-hosted, agentic AI platform: a private console I call Task Studio that turns a plain-English request into a finished deliverable, whether that's a researched report, a small website, generated images, or a fully narrated, scored and captioned marketing video. Every model runs on my own hardware. There is no OpenAI, no Anthropic, no third-party API anywhere in the loop. The LLM that reasons, the diffusion models that render, the voice that narrates, and the model that turns an image into a 3D mesh are all local.

It started as something smaller: a worker for an online task marketplace (built with the platform operator's permission) that polls open bounties, uses a local model to judge which are genuinely AI-suitable, drafts a proof, routes it through a human-review queue, and submits it. That pipeline of classify, draft, review and dispatch became the spine everything else hangs off.

Three hosts, one agent

The work is split across three machines so a weak orchestration box never blocks the GPU, and the GPU box never has to hold state. A bot host takes the request and dispatches the agent; the agent host runs the agent runtime and the media tooling; and a GPU rig serves the actual models. The hosts talk to each other only over locked-down, token-authenticated internal channels, never anything public-facing.

A local media pipeline the agent drives

The agent doesn't just write text. It can call a full production toolbox, review its own output (a vision model describes each render so the agent can judge it), and composite the pieces together. All of it local, much of it able to fan out across both GPUs:

Eva: one assistant, every platform

The same brain is reachable as Eva, a chat assistant that lives on Discord, Matrix and Nostr at once through a microservice hub: platform-specific bots forward commands to a central service (with accounts, permissions and bans) that answers from the local model and can queue Task Studio jobs, pinging you back when the work finishes.

Several machines' worth of hardware

None of this is rented. The bot host, the agent host and the GPU rig are physical machines on the server VLAN that I built and keep running myself. That means NVIDIA driver and CUDA upkeep, budgeting VRAM so the LLM, diffusion and speech services can share two cards without evicting each other at the wrong moment, hundreds of gigabytes of model storage, and the fans, power supplies and cabling underneath it all. When a card overheats or a disk starts failing, there is no cloud console to click. The fix is a screwdriver and an afternoon.

Rebuildable on purpose

All three hosts are captured as Ansible. If hardware dies, the reproducible parts (the bot stack, the agent runtime, every media CLI, the model manifest) come back with a command, and the hand-built GPU rig has an honest runbook rather than a fantasy one-click. Model swaps are a deliberate, documented playbook, not a scramble. It's a research toy in scope and a production system in discipline.

The stack

Boring on purpose: everything here is standard, reproducible, and something I'd be comfortable handing to a client.