Why#
There is a moment in any infrastructure project when the work shifts from building to inhabiting. The services are running. The backups complete overnight. The alerts fire when they should. The question stops being “will this work” and becomes “how do I live with this.”
Two things mark that shift more clearly than anything else: a control panel that shows you the state of everything at once, and a public voice that explains what you built and why.
This week produced both.
Family#
The admin dashboard is invisible to everyone except the person who operates the stack. It is a single page — reachable only from inside the home network or through the management VPN — that shows every running service, the state of every host, and live metrics from the tools that watch over the infrastructure. Not for anyone else. For the person who needs to know, at a glance, whether everything is fine.
The public site is the opposite. It is for anyone who wants to understand what this project is, why it exists, and how it was built. Not a tutorial. Not a feature list. A record of decisions, their reasoning, and what they cost.
The family is not mentioned by name anywhere on the public site. That is a deliberate rule. The people this infrastructure is built for are described by their relationship to it — a partner, a daughter, a guest — not by who they are. Privacy-first applies to the documentation as much as to the stack itself.
Tech#
The admin dashboard required solving a problem that sounds simple and is not: how do you show live data from twenty-seven services, spread across three hosts, without giving the dashboard software more access than it needs?
The answer involved three layers. A read-only proxy sits between the dashboard and the container runtime, allowing the dashboard to see which containers are running while blocking every write operation. Secrets — API keys, passwords — never appear in configuration files; they are injected at runtime from a separate file that stays out of version control. And cross-host metrics flow through the central monitoring system that already collects everything, rather than having the dashboard reach out to each host separately.
Several widgets did not make it. The log aggregation system listens only on the local machine, not accessible from containers. The reverse proxy on the gateway server shares its network with the tunnel manager and does not expose its dashboard. These are not failures — they are correct security decisions that happen to be inconvenient. The dashboard shows what it can without compromising what it should not touch.
The public site had a different kind of problem: too many moving parts at the start, not enough at the end. The original plan had five separate Hugo projects, each with its own subdomain and configuration. Running them locally required five terminal windows. Navigating between them opened new browser tabs. The theme state did not persist across origins.
The solution was obvious in retrospect and invisible in planning: consolidate to one project, one URL, one configuration to maintain. The subdomains that disappeared became redirects. Nothing was lost. The operational overhead dropped by four-fifths.
The site launched with twelve notes covering the full history of Part I — written retrospectively from project logs, following a four-part structure that forces every technical note to include why the decision mattered, what it meant for the people who use the system, and what pattern it established. The structure is a constraint. Constraints are useful.
Project#
The admin dashboard and the public site are different tools built for different audiences. But they share an underlying intent: making the stack legible.
The dashboard makes it legible to the operator — one place to see whether the system is healthy, whether anything needs attention, whether the tools that watch the infrastructure are themselves being watched.
The public site makes it legible to anyone else — a record of what was built, the reasoning behind it, and the honest account of where the plan changed when it met reality. The architecture document that required three complete rewrites before the implementation started. The subdomains that seemed essential on paper and were obviously redundant in practice.
A system that cannot be explained is a system that cannot be handed over. Both of these tools are, in the end, about the same thing: making sure that the infrastructure exists for the people it serves, not just for the person who built it.