No Cloud Landlords
Every service on this site — the callbooks, the satellite feed, the aircraft map, the scanner, this very blog — runs on hardware I own, sitting in my own space, on a network I control. None of it lives in somebody else's cloud. That's a deliberate choice, and it's the same instinct that got me into radio in the first place.
The radio parallel
Ham radio is fundamentally about not needing permission. No carrier, no monthly bill, no terms of service that change on a Tuesday. You and your gear and the ionosphere. When the normal infrastructure goes down, that independence stops being a philosophy and starts being useful.
Self-hosting is the same idea pointed at computers. When a service you rely on lives on someone else's machine, you're a tenant. The landlord can raise the rent, change the locks, discontinue the building, or start reading your mail — and mostly you find out after it already happened. I'd rather own the building.
What "the lab" actually is
Under the hood it's a small four-node cluster running Proxmox, and I'm almost proud of how unglamorous the hardware is: a couple of low-power boxes, a recycled office desktop, and an old network-attached-storage unit I wiped and reimaged into the fourth node. Cheap, secondhand, boring silicon — running around fifty-odd containers and a stack of virtual machines. A WireGuard mesh stitches in receive sites at other locations, so a radio on a good hilltop miles away shows up like it's plugged in next to me. My own DNS resolves everything internally, and a reverse proxy puts clean, encrypted addresses on all of it.
It sounds like a lot. It is a lot — but it grew one "huh, I wonder if I could host that too" at a time. That's how these things always go.
The 6 days of silence
Let me tell you about the humbling one, because self-hosting means the ops team at 2 a.m. is you.
One of my little monitoring scripts had a bug: when a step failed, it left a zero-byte temp file behind instead of cleaning it up. Individually, harmless. Over time? It created millions of empty files and ran the server clean out of inodes — the filesystem's index of "how many files can exist," which you can exhaust long before you run out of actual disk space. Once inodes were gone, nothing new could be written. And here's the cruel part: the scheduled jobs that email me reports and take my backups didn't crash with a big red error. They just… couldn't write their output, and quietly gave up. For six days I got no reports and took no backups, and nothing told me. The system didn't fall over. It went silent, and silence looks exactly like "everything's fine."
I'll be honest about another one, too: my cluster has an even number of nodes, which is a mild sin in clustering circles — four machines can split two-against-two and argue about who's in charge. I know. It's on the list. Running your own infrastructure means keeping an honest list of the things that are one bad day away from biting you.
The honest tradeoff
I'm not going to pretend it's free. I've lost an afternoon to a firewall rule and a whole evening to a config file that got clobbered on reboot. The cloud absolutely has its place, and I use it where it earns its keep.
But the tradeoff buys something I value more than the convenience: nothing here gets rate-limited, sold, sunset, or held hostage by a business decision I didn't make. It's a place to learn where breaking things is allowed, because they're my things. And when it's running well, there's a quiet satisfaction in knowing exactly where every byte lives.
No cloud landlords. Just a rack I can put my hand on, humming away, doing exactly what I told it to — even the parts I told it wrong.