Infrastructure · 07 Oct 2026 · 3 min read
Why I Self-Host Everything
I run six projects on hardware I own. A small ARM server, a couple of containers, a tunnel. The total monthly cost is close to nothing.
People assume this is a privacy stance. It isn't, or at least not primarily. The reason is simpler and much less romantic: self-hosted things do not disappear.
The thing that actually breaks
Every project I have ever abandoned died the same way. Not from a technical failure — from a bill.
A free tier ends. An API changes its pricing. A service gets acquired and the new owner sunsets the hobby plan. A model provider deprecates the endpoint you built against. Each time, the code still works perfectly. It just has nowhere to run.
Cloud is wonderful right up until the moment it isn't, and the moment it isn't is never announced with enough warning to do anything about it comfortably.
What self-hosting actually costs
The honest ledger:
Money: close to zero. A free-tier VM, an old laptop, or a Raspberry Pi.
Time: real, and front-loaded. You are now responsible for the thing being up. When it dies at 3am, it stays dead until you or something you wrote notices.
Capability: you are slower than a GPU. You are less reliable than a managed service with an SLA. You will spend an afternoon on something a paid product does in one click.
That middle item is the one people underestimate, and it is why so much self-hosted software quietly rots. The server keeps running but nobody is watching it.
The answer to that is automation, not heroism
I do not want to be the person who checks on servers. So the servers check on themselves:
- Services run under
systemdwithRestart=always, so a crash is a non-event - Health endpoints that report readiness rather than just liveness
- A local model that reads logs and decides whether something needs attention
- Anything it cannot fix gets escalated rather than silently swallowed
The goal is not a perfectly reliable system. It is a system whose failures are loud — where the default outcome of something breaking is that I find out, rather than that it quietly stopped working three weeks ago.
The part I got wrong for a long time
I used to think self-hosting was about control. It is, but not in the way I imagined. The control that matters is not over the data or the configuration. It is over whether the thing still exists next year.
A service you pay for exists at the pleasure of a company's finance department. A service you host exists until you decide otherwise. That asymmetry is worth a surprising amount of inconvenience.
What I would not self-host
I want to be balanced about this, because self-hosting has a real failure mode: doing it for things that do not need it.
I would not self-host email. Deliverability is a war fought with reputation systems, and losing it means your messages vanish into spam folders where you will never know.
I would not self-host anything where being down for a day genuinely costs money.
And I would not self-host something I am not willing to fix. The graveyard of self-hosted software is full of things whose owners moved on.
The test is simple: will I still be willing to maintain this in two years? If yes, host it. If no, paying someone is the more honest choice.