The self-hosted stack

The setup

Most of what I run, I run myself. Code lives in a self-hosted Gitea at gitea.struct.work instead of only on someone else's servers. Language models run locally through Ollama, which is what powers the search and diagnosis in ETABuddy without shipping a single warning off my machine. A customized Pi-hole handles DNS and filtering across the network. This site ships through a pipeline I wrote end to end. Analytics is the next piece, a self-hosted Umami instance staged to go on the same box.

None of it is exotic. That is the point. It is an ordinary stack, owned rather than rented.

The deploy pipeline

The site you're reading is the clearest example, because you can see the whole path. One script does it: it pulls my latest blog posts over RSS and injects them into the page, compresses the post images to WebP at a fixed size, minifies the Tailwind build, then copies the whole set over SSH to the server. On the far end, Docker Compose runs an nginx container that serves the files, with gzip on and cache headers set per file type.

There is no CI service in the middle, no platform doing it for me. When I change the deploy, I change a bash script and a compose file, and I can read every step. That readability is worth more to me than the convenience of a hosted pipeline I'd have to trust blind.

Why own it

Two reasons, and the first is selfish: I wanted to learn DevOps by doing the whole thing, not the middle 60% a managed platform leaves you. Setting up the server, the reverse proxy, the TLS, the DNS, the container lifecycle, the backups. You learn where the sharp edges are by getting cut on them, and you can't get cut on the parts a platform hides.

The second is ownership. My code, my models, my data, my uptime. When a model runs on my hardware, the prompt never leaves the building. When my git server is mine, no pricing change or policy shift moves my repositories for me. That independence costs some evenings. It buys a stack that behaves the way I decided it should.

What an engineer gets out of it

Structural engineers already think in systems, load paths, failure modes, and what happens when one element gives. Infrastructure is the same shape. A request comes in, passes through DNS, a proxy, a container, a file, and back out, and any link can fail. Running your own stack turns that from an abstraction into something you have debugged at 11pm.

It also changes how you build tools. Once you can stand up a server and a domain in an afternoon, shipping a calculator or an internal tool stops being someone else's job. The distance between "I could build that" and "it's live at a URL" collapses. Most of the tools on this site exist because that distance got short enough to cross on a weekend.

You don't need a homelab to be a good engineer. But if you build tools, owning the ground they run on removes a whole category of excuses.