Self-Hosting

I gave the lab VM more memory recently, which left room to try another service. NetBox was the one I wanted to test, because it does two jobs I currently do badly in scattered markdown: DCIM — sites, virtualization, and how infrastructure relates to itself. IPAM — prefixes, VLANs, address ranges, individual IP assignments. The trial was deliberately conservative. I wanted to find out whether NetBox suited the lab without handing it unnecessary exposure, and without letting an automated import invent facts I hadn’t verified. ...

A while back I built a front door for the home lab — one Homepage dashboard listing every service, with live status dots. It’s the page I look at most. On a phone it’s a browser tab. It works, but it’s a shrunk web page: no icon, no native controls, and every visit is a fresh Authentik redirect. I wanted the same thing as an actual app. This is how that went, including the parts that didn’t work. ...

My Obsidian vault has 61 notes in it — study notes, homelab runbooks, session logs — and it syncs between this box and my laptop. The only way to see what I’d touched recently was to open Obsidian and read Home.md, a hand-maintained index that goes stale the moment I forget to update it. So I wanted a small dashboard: recent notes, pinned notes, what’s still unticked. Local only. I didn’t write this code. I gave Claude Code the prompt and reviewed, tested and corrected what came back. That’s how most things on this blog get built now, and it seems worth being plain about. The prompt was: ...

Claude Code is the main LLM running my homelab. It builds, debugs, and documents most of what happens on the Debian VM. But I wanted to try other models — and give the CLI tools a shared backend — without wiring up a different SDK and API key for every provider. So I put a gateway in front: one endpoint, many models. Claude stays the main driver; everything else is now one config line away. ...

We all tend to focus on the output of whatever LLM we’re using — did it get the answer right, was it fast, was it useful. What I’d stopped paying attention to was the background: how many tokens a session was actually burning, where they went, and whether I’d have any way of knowing if something had gone quietly wrong. Claude Code runs natively on my homelab now, doing real work against real infrastructure, and I wanted more than “the output looked fine” as my only signal. ...

At some point my lab crossed a line. I had a firewall, an identity provider, a password vault, dashboards, a log system, an alert router, and a vulnerability scanner — and I was typing subdomains from memory to reach any of them. Half the time I’d get one wrong. So this project is small: one page that links to everything. It took under an hour, and it’s the thing I now look at most. ...

The blog you’re reading was published by the pipeline this post describes. Why Hugo, and why self-hosted I needed somewhere to document real technical work — networking, security, mod projects — that I could point to from LinkedIn. Hosted platforms were out: no content ownership, paywall friction, someone else’s branding. Hugo won on attack surface. It’s a single Go binary — no Node, no node_modules, no npm dependency tree to patch and audit. For a security portfolio, the blog itself should be as defensible as the work it documents. It builds to plain static files, so serving is trivial; the trade-off is owning uptime and patching, which for this use case is a feature. ...