why I self-host the boring stuff

There's a version of self-hosting that shows up on Reddit and Hacker News: someone running their own mail server, their own password manager, their own photo library, their own everything, all behind a rack that hums in the basement. It's impressive. It's also not what I do.

My email and calendar live in iCloud. I pay for them, and I'm happy to.

What I self-host is the boring stuff: the home automation hub, the dashboards, the reverse proxy, the little agent that runs on a VPS. Nobody envies any of it, and I'd argue that's exactly why it belongs on hardware I control.

The rule: self-host what's cheap to lose and expensive to rent

Before I stand anything up, I ask two questions:

1. If this breaks at 2 a.m., does anything bad happen?
2. If I rent this instead, what am I really paying for?

Email fails question one badly. If my mail server goes down, or gets blocklisted, or I misconfigure DKIM, I miss things that matter: closing documents, school notices, invoices. The cost of getting email wrong is high, and providers who do nothing else are very good at it. Renting it is the right call.

A Home Assistant dashboard passes question one easily. If it goes down, the lights still work at the switch. Worst case, I'm annoyed for an evening.

Question two is where the boring stuff wins. Rented versions of boring tools are rarely expensive in dollars. They're expensive in other ways:

• Lock-in. Your automations, layouts, and integrations live in someone else's format.
• Cloud round-trips. A light turning on shouldn't need a server in Virginia.
• Feature drift. The vendor changes the UI, kills a tier, or gets acquired, and you get to rebuild.
• Data exhaust. Motion sensors, door states, and presence detection make up a detailed record of when my family is home. I'd rather that not be someone's product.

So boring tools are cheap to lose and quietly expensive to rent. That's the sweet spot.

What's actually running

Here's the honest inventory:

• Home Assistant runs the house: lights, sensors, presence, and the slow, ongoing project of getting every room mapped and every device talking. Not everything is integrated yet (the security system is still on its own app), and that's fine. It grows when I have a weekend.
• A VPS behind Traefik handles the things that need to be reachable from outside. Traefik does routing and TLS so I'm not hand-managing certificates for every subdomain.
• A self-hosted AI agent instance, my own gateway that I can wire into my tools on my terms instead of whatever integrations a SaaS decides to ship.
• Dashboards like dash.georges.co: small, personal, and built for exactly one user.

None of these is a platform. Each one is a utility.

The real reason: boring stuff is where you learn

I'm a programmer and an IT tinkerer by temperament, and the boring stuff is where the tinkering pays off.

When I stood up the agent instance, the app itself was the easy part. Then:

• Host networking conflicted with Docker's bridge networking.
• The port mappings were wrong, and it took a while to find the one that actually worked.
• A network declaration was missing from the compose file, so Traefik couldn't see the container.
• The container hit EACCES writing to its own data directory because the volume's ownership didn't match the user inside the container.
• A gateway token mismatch kept me out of the control UI.
• The Discord integration failed silently until I enabled the privileged gateway intents in the developer portal.

None of that is glamorous, and none of it was in the README. But each one taught me how the pieces actually fit: how containers see the network, how reverse proxies discover services, how file permissions cross the container boundary. That knowledge carries over to my day job in a way that "I clicked Subscribe" never will.

High-stakes services are bad places to learn because mistakes are costly. Boring services are great places to learn because mistakes are cheap. Learning on email means missed mail. Learning on a dashboard means a 404 until I fix it.

The rules I follow so it stays boring

Self-hosting goes wrong when the hobby turns into a second job. These keep it in check:

1. Everything goes in a compose file or it doesn't exist. If I can't rebuild it from a file, I don't really have it. Hand-tuned containers are a liability waiting for a reboot.

2. One reverse proxy, one pattern. Every service gets a subdomain, Traefik labels, and automatic TLS. No one-off nginx configs, no special cases.

3. Nothing critical depends on it. The house has to work if Home Assistant is down. Light switches are the fallback, and I don't automate anything that would leave someone stuck if it failed.

4. Back up the config, not the world. Configs and small state get backed up. I'm not trying to be a backup provider for terabytes of media.

5. If it starts to matter, re-evaluate. The day a self-hosted service becomes something my family depends on, it gets a hard look. Either it gets proper monitoring and redundancy, or it goes back to being rented.

What I'll never self-host (for now)

• Email. See above. Deliverability is a full-time job I don't want.
• Passwords. The failure mode is catastrophic, and the good hosted options are end-to-end encrypted anyway.
• Anything with a compliance burden. If it touches someone else's sensitive data, it gets real infrastructure, real audits, and real on-call. A VPS I tinker with on Saturdays doesn't qualify.

This isn't purity. It's triage.

The point

Self-hosting isn't really about independence from Big Tech, or saving $8 a month, or having a cool rack. For me, it's about owning the parts of my digital life that are low-stakes, high-touch, and personal. Those are the parts where control matters most and the risk of getting it wrong is smallest.

Rent the stuff that has to work. Own the stuff you want to understand.

And keep it boring.