Reliability & Observability

Running my own infrastructure

A self-hosted stack on Proxmox behind Cloudflare and Caddy, running real services I depend on daily. It's where I keep the operational instincts sharp that contract React work tends to let atrophy.

Context
Personal infrastructure, fully owned and operated. Everything here is mine to describe in full.
Core technologies
Proxmox, Cloudflare, Caddy, FastAPI, self-hosting

Here’s a thing I’ll say out loud that most candidates won’t: years of contract frontend work, plus leaning hard on AI tooling day to day, will quietly soften your systems instincts if you let it. You stop touching the layer below the framework. The homelab is partly how I refuse to let that happen, and partly just that I genuinely enjoy running real systems.

rosewire.net and everything around it runs on my own hardware. Not a hobby in the “abandoned Raspberry Pi in a drawer” sense. An actual stack I depend on:

  • Proxmox as the hypervisor, with services split across containers so a problem in one doesn’t take down the rest. Blast-radius thinking, same as anywhere else.
  • Cloudflare out front for DNS, proxying, and access control, with Caddy as the reverse proxy doing TLS and routing. This is the same Caddy that serves the site you’re reading.
  • A handful of services I actually use rather than just demo: media streaming, a music server, a local OpenWebUI front end for models, and a small FastAPI app I wrote to handle signups for the improv group I perform with. That last one is my favorite, because it has real users who are not me and who complain when it breaks.

The point isn’t the service list. Anyone can follow a tutorial and end up with a Jellyfin install. The point is operating it: TLS that renews without me thinking about it, access control that actually controls access, deploys that are reversible, and an honest understanding of what happens when a piece falls over.

A homelab where nothing ever breaks isn't impressive, it's unused. The value is in having broken it, at 11pm, and built the thing that stops it from breaking that way again.

This is also where the reliability case study gets its “proof you can poke at.” The deploy discipline I describe for the enterprise work, dry-run by default, archive before replace, minimal runtime surface, is not theoretical for me. It’s how this site ships, and the colophon documents it down to the command.

If you’re hiring and you want to know whether someone actually understands the systems under their frontend, “show me something you run yourself” is a better question than any whiteboard prompt. This is my answer to it.