Readable infrastructure
I wanted a home for code, writing, keys, and network addresses without an application server or database. The useful constraint was not minimalism for its own sake; it was being able to trace a request all the way to the file nginx returns.
Posts begin as Markdown, a narrow generator produces reviewable HTML, and the public directory contains exactly what is deployed.
blog/*.md -> generator -> www/blog/*.html -> nginxOne content pipeline, two edges
Two machines publish the same static tree. The clearnet edge serves HTTPS. The onion edge binds nginx to loopback and lets Tor be its only intended client.
The onion hostname is treated as a deployment invariant because the address is derived from the service key. A healthy local nginx process is not enough if Tor silently generated a different identity after a failed restore.
- Validate nginx before reload
- Keep the onion listener on loopback
- Verify the expected onion hostname
- Keep identity keys outside Git
Small does not mean automatic
A static site removes application code from the request path, but the operating system, nginx, DNS, TLS, Tor, and deployment credentials still require maintenance. Simplicity is valuable when the remaining boundaries are explicit. It loses value when it hides them.