Infrastructure · Self-Hosting
The case for owning your own stack, told in two acts. First, the cultural history of physical infrastructure — from toggle switches to complexity rent to the moment AI collapsed the knowledge barrier. Then, the practical playbook: what to run, what it costs, and when to graduate.
July 2026
The Homebrew Computer Club's first meeting in 1975 was not a software demo. It was a hardware show-and-tell. People brought boards they had etched themselves, chips they had scavenged, power supplies salvaged from discarded electronics. The Altair 8800 — the machine that launched Microsoft — was not a computer as we understand the word. It was a box with toggle switches and blinking lights. To program it, you flipped switches one bit at a time. The reward was a pattern of LEDs.
And this was thrilling. Not because the machine was powerful — it was barely functional — but because it was yours. You bought the chips, you wired the bus, you debugged the timing with a logic probe. The machine answered only to you because you had assembled it with your own hands. That feeling — the directness of the relationship between a person and a machine they built — is the thread that runs through every era of computing that mattered.
This is where the culture started, and it was a culture of physical making. The Homebrew Club produced Apple not because Wozniak had a brilliant software insight, but because he had designed a board so elegant and complete that it reduced a room of discrete chips to a single PCB. The revelatory moment was not a new program — it was a new piece of hardware that made computing affordable enough to put on your desk.
By the 1980s, the personal computer had become something new: a node. The BBS era was the first great wave of people running servers out of their homes. A teenager with a Commodore 64, a 300-baud modem, and a second phone line could become an island of connection. Their machine would ring at all hours. Strangers would upload files, leave messages, play games. The server lived in a bedroom, or a basement, or a closet. You could hear it when it was working — the clicks of the hard drive, the whine of the fan, the modem handshake screech.
This was not professional infrastructure. It was a tower under a desk running 24/7, getting hot, gathering dust, and somehow connecting a neighborhood of strangers into something real. The hardware was not abstract. It was a machine in your room that made the outside world arrive through a wire you had screwed into the wall jack yourself.
The warez scene grew out of this same material culture. The groups that traded cracked software and competed on speed runs were not organized through platforms. They organized through private BBS nodes, then FTP servers on rented colocation space, then IRC channels on servers running out of someone's apartment. If you wanted to be a "top site," you needed a T1 line — which meant you needed money, or access, or both. The guys with the hardware were the guys who set the rules. The server was not a metaphor. It was a box in someone's basement that you could, if you knew the right people, go and touch.
By the early 2000s, the bedroom server had a bigger sibling: colocation. You rented a half-rack in a building full of other people's racks. You drove there with a server in your passenger seat, signed in at the front desk, and wheeled your box through a hallway lined with cages. The sound hit you first — a low roar of thousands of fans. The cold air hit you second.
Racking a server in a colo facility is one of the most underrated experiences in technology. You slide the rails in. You tighten the screws. You plug in power — redundant, two PSUs. You plug in Ethernet — also redundant. You cable-manage because you have standards. And then you step back and look at your machine, one of hundreds, and you know that it is yours. The blinking light on the front panel — the one that tells you the drive is active — that light is responding to code you wrote.
This was never a cost-optimal choice. People did it because they wanted to touch their infrastructure. They wanted to be in the same room as the machine that served their users. They wanted the ritual of the drive to the datacenter, the security badge, the cold aisle, the blinking lights. That ritual was not overhead. It was the point.
Somewhere in the migration from colo to cloud, the relationship flipped. The cloud sold itself as efficiency — no more provisioning hardware, no more patching OSes, no more worrying about power and cooling. But the real product was complexity rent. The unspoken premise was: you can't do this yourself, so pay us.
The SaaS model took that premise and industrialized it. Postgres administration was a skill. TLS configuration was a skill. Load balancing, reverse proxying, storage replication — every layer of the stack was a frontier that required months or years to cross. The people who had crossed it charged a toll. Monthly. Per seat. Per request. Per GB. And because the alternative was doing it yourself — which was genuinely hard — you paid.
This produced a structural outcome that nobody talked about: the tenant relationship. Every subscription you paid meant someone else owned the keys. Someone else stored your data. Someone else decided what the next version would cost. You were a renter in your own stack. And because the complexity was real, the rent felt fair. For a long time, it was.
The subscription economy doesn't just take your money. It shapes your behavior. When every tool is a monthly payment, you stop asking "Do I need this?" — you just let the auto-pay run. The cost becomes invisible. That's the real lock-in, not the API key.
The premise that held for thirty years — that infrastructure requires deep, scarce knowledge — has a hole in it now.
A working Postgres config with Caddy reverse proxy, Tailscale auth, automated backups, and a health-check endpoint used to be a week of reading and a hundred Stack Overflow tabs. Today it is a single prompt. AI doesn't just help with the config files — it explains the architecture decisions, handles the edge cases, and debugs the connection string when something doesn't resolve.
This changes the economics fundamentally. The barrier to running your own infrastructure was never the cost of the hardware — a Hetzner AX102 is $38/month and is more machine than most teams of ten would need. The barrier was the knowledge. The barrier was knowing how to wire the thing together well enough to trust it with your data.
That barrier is gone. Or, more precisely, it has been reduced to a vanishing thin layer: you still need to want to learn. But the gulf between wanting and doing collapsed the day models could generate, explain, and debug a full infrastructure stack in natural language.
— Part Two: The Playbook —
A few years ago the pitch for managed platforms was obvious. You skip the server, skip the sysadmin work, and ship faster. For a solo builder that trade-off made sense when the first $20 was free and everything lived on a hobby tier.
That era is over. Vercel's hobby tier cuts off commercial use. Railway charges per-minute for compute that idles most of the day. Supabase is generous at zero but punishing the moment you need a second project or real connection pooling. The pattern is the same everywhere: growth thresholds are engineered to trigger exactly when a project gets interesting, and the jump to the next tier is steep.
| Component | Choice | Cost |
|---|---|---|
| Production compute | Hetzner CX42 (4 vCPU, 15 GB RAM) | ~$24–32/mo |
| Entry compute | Hetzner CAX11 (2 vCPU, 4 GB RAM) | ~$6–12/mo |
| Database | Postgres 17 on same box | $0 |
| Reverse proxy + TLS | Caddy (auto-cert, zero maintenance) | $0 |
| CDN / proxy | Cloudflare free tier | $0 |
| Deployment | Coolify (containers) + systemd (binaries) | $0 |
| LLM inference | Ollama (CPU + GPU worker via Tailscale) | $0 |
The math isn't subtle. For a side project or small internal tool, you are paying a convenience tax on infrastructure you could own outright for a fraction of the cost. The question stopped being "is it worth setting up a server" and became "what exactly am I buying with that premium."
The honest reason self-hosting fell out of fashion wasn't just laziness — it was cognitive overhead. Nginx configs you had to look up every time. systemd unit files that felt like black magic. TLS renewal, ufw rules, zero-downtime deploys, Postgres tuning. If you weren't a sysadmin by trade, you lost a weekend every time something went sideways.
AI changes this in a specific and underrated way: it doesn't make you a sysadmin, it makes it so you don't need to be one. Caddy reverse proxy with automatic TLS, SPA fallback, and API proxying? One prompt. Docker Compose with proper networking, restart policy, and environment variables? One prompt. ufw rules, migration tooling — all of it is one conversation away and immediately correct for your exact setup.
More importantly, debugging is faster too. When something breaks at 2 AM, you have a competent ops co-pilot who knows your stack, can read your journalctl output, and will walk you through the fix. The old asymmetry — managed platforms never break in ways you have to fix, self-hosted breaks in ways that cost you hours — has narrowed dramatically.
The inflection point isn't that AI writes your app. It's that AI has made the operational layer — the part that used to eat weekends — cheap enough to be irrelevant.
For Serapio Labs the stack is deliberately boring — the boring choices are the ones that survive contact with reality. A single Hetzner VPS runs the core: Postgres 17 on port 5433 for separation, Caddy as the reverse proxy with built-in automatic TLS, service containers where they make sense and systemd binaries where they don't. Tailscale is the backbone, not a footnote. Cloudflare sits in front for DDoS protection and caching, but it's a one-checkbox upgrade, not a prerequisite.
Deployment is a mix: Coolify handles the containerized services (Open WebUI, Qdrant, LiteLLM), systemd handles the compiled Go binaries. The choice isn't ideological — Postgres as a container adds complexity you don't need, but managing Qdrant and Open WebUI as raw processes would be genuinely harder.
And then there's TARS — the distributed LLM inference cluster at tars.serapiolabs.com. The Hetzner VPS hosts the control plane: Caddy, Open WebUI, Qdrant vector memory, and a CPU-bound Ollama instance running qwen2.5:7b. A Windows PC with an RTX 3060 12 GB acts as the GPU worker, serving qwen2.5:14b over Tailscale. It's the same thesis pushed further: one compute layer that works, distributed only where the bottleneck demands it.
Self-hosting isn't always right. The case for managed platforms doesn't disappear — it narrows.
For Self-Hosting
Against
The key question is scale and stakes. If you're building something with a team, external SLAs, or traffic that can spike unpredictably, managed infrastructure earns its keep. For a solo builder running internal tools, personal projects, and small client work — the math has flipped.
This is the frame the managed platforms don't want you to see: self-hosting isn't a permanent architectural choice — it's a temporal one. You self-host during the exploration phase, when unknowns outnumber users and every bottleneck is a discovery signal.
The architecture tells you what breaks first. If it's compute, you scale up on Hetzner or add a GPU node. If it's concurrency, you graduate to managed. If it's team collaboration, you pay for the seats. Each bottleneck reveals the next investment with surgical precision — no over-engineering, no guesswork.
This approach also keeps your software loosely coupled by accident. Because the natural next step when any piece outgrows Hetzner is to extract it into a commercial-grade managed service. You never design for extraction — it happens because the architecture was simple enough to understand in the first place.
The server still whispers. You just have to be in the room to hear it.