Self-host the things you'd be sad to lose
Self-hosting isn't a religion; it's a triage question about which of your data you can't afford to have someone else delete.
The question that matters isn't "can I self-host this?" It's "if this vendor vanished overnight, would I be annoyed or would I be ruined?"
That question sorts everything. Most of what you use lands on the "annoyed" side, and that's fine. I will never self-host email — fighting spam filters and IP reputation is a full-time job I do not want. I will never self-host my calendar sync or my password manager's infrastructure. The convenience is worth the dependency, and losing a vendor there is a bad week, not a catastrophe.
But some data is different. The photos of my kid. Twelve years of writing. The notes that hold the shape of how I think. If a company decided tomorrow that my account violated a policy I never read, and a support bot replied with a link to a help-center article — that's not a bad week. That's a hole in my life. The asymmetry is the whole argument: the vendor's downside is a churned customer; mine is permanent loss of something irreplaceable.
Sort by replaceability, not by ideology
Self-hosting people tend to argue from principle — privacy, ownership, sticking it to Big Tech. Those are fine motivations, but they make you over-host. You end up running a mail server out of spite and neglecting the one folder you'd actually cry over. Triage beats ideology. Walk your digital life and put every category in one of three buckets:
- →Convenience data. Streaming history, ride receipts, the grocery app. If it vanished you'd shrug. Leave it.
- →Annoying-to-lose data. Bookmarks, RSS, your reading list. You'd grumble and rebuild. Maybe back it up; don't host it.
- →Sad-to-lose data. Photos, original writing, family records, anything you made that exists nowhere else. This is the list. This is the only list that matters.
The mistake I see most often is treating all three the same. People either host nothing and trust everyone, or host everything and burn out on maintenance. The sad-to-lose bucket is usually small — small enough to protect properly, which is the point.
Hosting is a means; survivability is the end
Here's the part the self-hosting forums underplay: a server in your closet is not safety. It's a different single point of failure, and often a worse one, because now you're the ops team and you're not on call. A drive dies, a rm -rf goes sideways, the house floods. You have not escaped data loss; you've just changed who's to blame.
What you actually want is survivability, and the test is boring and old: 3-2-1. Three copies, two kinds of media, one of them somewhere else entirely. Self-hosting is one good way to own the primary copy. It is not a backup strategy by itself.
So the real architecture for the sad-to-lose bucket looks like this. Own the primary. Keep a local backup you can touch. And — this is the part the purists hate — keep an encrypted off-site copy with a vendor. The vendor can't read it, can't ransom it, and can't hold it hostage, because it's just opaque bytes to them.
Off-site copies stay encrypted; the vendor only ever sees ciphertext.
That check line is the one people skip, and it's the one that matters. A backup you've never restored isn't a backup; it's a hope. I restore a random file from each archive every quarter. It takes ten minutes and it's the only thing that turns "I have backups" into "I have backups that work."
Pick tools you can walk away from
The trap inside the trap is self-hosting something with its own lock-in. If your photo server stores files in a proprietary database blob, you've recreated the original problem with extra steps and worse uptime. The right tools keep your data in formats that outlive them.
- →Photos as files on a filesystem, in a folder tree you understand — not entombed in an app's internal store.
- →Notes as plain text or Markdown, readable in any editor for the next thirty years.
- →Writing in flat files under version control, where the history is the archive.
The test is simple: if the software you're running disappeared tonight, could you still open your data tomorrow with something else? If yes, the host is replaceable and you've won — you can move, the tool was just a convenience over files you already controlled. If no, you've built a fancier cage.
This is also why I don't agonize over the perfect self-hosted stack. The stack is the easy part and the replaceable part. The formats and the backups are what carry the weight. Pick boring formats, automate the off-site copy, restore-test it, and the choice of server software becomes a detail you can change your mind about later without losing anything.
Run the triage once a year. Most of your life will sit happily in the cloud, rented and convenient, and you should let it. But walk the sad-to-lose bucket deliberately, own the primary copy, keep one encrypted copy somewhere you don't control, and prove you can get it back. Self-hosting isn't about distrust or principle. It's about making sure the things you couldn't bear to lose don't depend on a stranger's policy decision you'll never get to argue with.
