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 runs through a self-hosted Umami instance on the same server.

None of it is exotic. That is the point. It is an ordinary stack on a rented VPS, and I run every piece of it myself.

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.

The checks run in Gitea Actions on the Gitea I host: partial drift, the build, HTML validation, links, the rule lint and a secret scan. Deploying is still a bash script and a compose file I can read end to end, which is worth more to me than a hosted pipeline I would 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 locally through Ollama, the prompt never leaves the machine. 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 to run your own servers to be a good engineer. If you build tools, though, running your own means the gap between a script on your laptop and a URL a colleague can open is an afternoon, and that changes what you bother to build.