Scattered port numbers converging into one dashboard URL

I had 18 services running across two Raspberry Pis and a Chrome bookmarks folder full of different ports. Every few weeks I’d need one and end up clicking through bookmarks trying to remember which port was which.

How I got here

I use Claude Code on a couple of Raspberry Pis. Over the past few months I kept asking it to build me things — a performance report for Podly so I could see podcast processing stats visually. A SvelteKit spec browser so I could review generated codebase specifications and give Claude specific feedback. MOSAIC prototypes so I could compare three UI directions in browser tabs and pick one. Some were full apps, some were just a python3 server pointing at an HTML file.

Podly Ad Detection performance report — F1 scores, regression analysis, deployed config

“This section is wrong” is better feedback than “I think the specs might be off.” “Move the sidebar left” beats “I think the layout might need work.” Rendered output gives you something to point at.

So the pages kept coming. A session-mining report that analyzed 470+ conversation transcripts and surfaced patterns across 810MB of logs. A network topology diagram. A project roadmap dashboard.

After 267 sessions I had 18 of these spread across two Pis on different ports. Each one was useful. I just couldn’t find half of them anymore.

Claude’s first idea

I built a workflow called /build-dev specifically for infrastructure work — modeled after Anthropic’s feature-dev but adapted for a domain where mistakes take down networks instead of failing a test. It has a multi-phase structure: discover the current state, audit access and dependencies, design the approach, then execute step by step with verification and rollback plans. Planning and execution happen in separate sessions so the execution agent starts with clean context and unambiguous instructions.

/build-dev workflow — discovery, parallel audit, competing approaches, security and sysadmin review, then execute with rollback

The key part is Phase 4 — approach design. Three agents design competing approaches in parallel (minimal, robust, pragmatic), then a security reviewer and a sysadmin reviewer critique the chosen approach before any artifacts get created. Every step in the plan gets a verification command and a rollback command. Nothing executes without both.

I started in Claude’s normal plan mode. The first draft: spin up python3 -m http.server on port 3080, create a systemd unit, and route it through Caddy as a reverse proxy at home.chughes.co. Something about that felt off — home.chughes.co didn’t sound right, and another python3 server to fix a python3 server problem seemed wrong. So instead of approving the plan I ran /build-dev and let the proper workflow handle it.

The sysadmin reviewer flagged the domain conflict — home.chughes.co is the DuckDNS base domain that all other *.chughes.co subdomains point to. Using it as a Caddy route would break every service on the network. The security reviewer flagged the unnecessary server:

“Caddy already has file_server for static sites — used by blog.chughes.co and analytics.chughes.co. Eliminates the systemd unit, port 3080, and the reverse_proxy hop entirely.”

The plan collapsed from six steps to four. Download Homer. Copy files. Add a Caddy block. Reload.

Six lines

homer.chughes.co {
    root * /var/www/homer.chughes.co
    file_server
    encode gzip
    basic_auth { ... }
}

TLS cert auto-provisions, BasicAuth reuses the existing password hash — same pattern as the blog and the analytics dashboard.

Homer dashboard — 4 sections, 18 services, one URL

The whole thing took about ten minutes.

Don’t theme it

Claude also built a custom CSS theme — premium fonts, glowing emerald accents, film grain overlay. I took one look at it and said no. It looked like a sci-fi movie prop.

The point of a dashboard is finding your services. Not admiring it.

Written with Claude.