The first time I self-hosted anything that mattered, I was 28 and overconfident. I set up a Bitwarden instance on a $5 VPS and felt like I’d hacked the system. Six months later, when the SSL certificate expired and locked me out of every account I had — at 1:17 a.m., on a Sunday, in a hotel room in another country, with a flight at 6 a.m. — I learned that self-hosting is a commitment, not a feature. You don’t just install something and graduate to a higher class of internet user. You become the operations team for whatever you installed.
I now self-host a fair amount. Vaultwarden (the lightweight Bitwarden-compatible server). Pi-hole. AdGuard Home. A small Nextcloud instance for files I don’t want to put in commercial cloud storage. A Tailscale tailnet that connects everything privately. None of it is exotic. All of it has, at one point or another, made me regret the choice for a few hours before I fixed it and moved on.
Here are the things I wish someone had told me before I started.
1. Self-hosting is not “free.” It costs ongoing time, attention, and a small but nonzero amount of money.
The marketing-adjacent framing is “stop renting; own your tools.” This is true in the same sense that “stop renting an apartment, own a house” is true. Yes, you’ll save the rent. You’ll also spend weekends fixing things that break. The total-cost-of-ownership (factoring in your time at any reasonable hourly rate) is often higher than the commercial subscription. Self-host because you want control, or because you want to learn, or because you want certain things never to leave your network. Don’t self-host because you want to save $36 a year on Bitwarden Premium.
2. Pick the boring infrastructure. Boring is reliable.
If you’re new to this, your stack should be: a small VPS at a reputable provider (Hetzner, DigitalOcean, Linode), a current LTS Linux distro (Debian or Ubuntu LTS), Docker Compose for application orchestration, Caddy or Traefik for the reverse proxy, Cloudflare in front of your domain. That’s it. Don’t run Kubernetes for one app. Don’t compile from source. Don’t pick a niche distro because someone on Reddit said it was 8% faster. Boring infrastructure has the best documentation, the deepest community, and the fewest weird edge cases at 1 a.m.
3. Backups must be tested, or they don’t exist.
I have lost data to a corrupted backup that I had been “backing up” successfully for nine months. The cron job ran. The rsync completed. The destination filled up with files. None of which were restorable because I’d never tried.
Set up automated backups, then immediately practice restoring from one. Then practice restoring on a fresh server, with no help from your existing setup, working from the backup files alone. Then put a calendar reminder to do this exercise every six months. The first time you actually need to restore will be the worst day to discover the backup process doesn’t work end-to-end.
4. SSL certificates expire silently and at the worst possible moment.
Use Let’s Encrypt with auto-renewal (Caddy, Traefik, certbot all do this). Then set up a separate uptime monitor (UptimeRobot has a free tier; Healthchecks.io is great for cron jobs) that pings your services from outside your network. The monitor catches expired certs, expired domain registrations, and your own server going down. Without external monitoring, you find out something is broken when you go to use it — which, by definition, is too late.
5. Use a domain name. Don’t run things on raw IP addresses.
Buy a cheap domain ($10/year), point a wildcard DNS record at your server, and put services on subdomains: vault.example.com, cloud.example.com, etc. This is a small upfront effort that pays for itself the first time you have to migrate IPs, the first time you want to set up SSL, the first time you want to share a service with a non-technical person. “Go to vault.lastname.family” is a much better instruction than “go to 198.51.100.42:8080.”
6. Use a VPN/mesh layer for things that don’t need to be public.
This is the lesson I wish I’d learned third instead of fifteenth. Tools like Tailscale (and the open-source equivalents: Headscale, Netbird, ZeroTier) let you put your services on a private mesh network where only your devices can see them. Most things you self-host don’t need to be reachable from the public internet. Putting Vaultwarden behind Tailscale instead of a public IP eliminates an enormous attack surface for very little setup cost.
The pattern: services that need to be public (a personal blog, a contact form) live on the public-facing reverse proxy. Services that are just for you and the people you trust (vault, cloud storage, home dashboards) live on Tailscale. Most of the privacy-related stuff fits in the second bucket.
7. Don’t run secrets in environment variables you committed to git, even for a minute, even on a private repo.
This is the lesson I learned in my first month, the hard way, in a way I still don’t like to think about. If you accidentally commit an API key, a database password, or any other secret, rotate it immediately. Don’t just delete the commit. Don’t just force-push. Assume it leaked the moment it touched your local git history, treat the secret as compromised, and replace it. GitHub’s automated secret scanning will find AWS credentials in seconds. The bots watching for accidentally-public credentials are real and fast.
Use a .env file (gitignored), or a secrets manager, from day one.
8. Update everything regularly, but not on Friday afternoon.
The cadence I’ve settled on: minor updates monthly, major updates as needed with a planned window, security patches within 48 hours of release. Schedule updates for a time when you can pay attention if something breaks. Don’t update at 5 p.m. on a Friday before a long weekend. Don’t update right before you leave for vacation. Apply updates when you can spend an hour fixing things if they break.
For Docker-based stacks, Watchtower can auto-update containers, but it can also auto-break them when an image update introduces a backward-incompatible change. Use Watchtower with caution; manual review of changelogs is sometimes worth the time.
9. The “self-hosted alternative” is sometimes worse than the commercial original.
Vaultwarden is genuinely as good as Bitwarden’s hosted offering. Pi-hole is genuinely useful. AdGuard Home is fine. Nextcloud is adequate — it works but it’s slower and rougher than the commercial Sync.com or Tresorit, and you’ll feel that whenever you actually use it.
Some self-hosted alternatives are great. Some are just acceptable. Some are noticeably worse than commercial. Pick by use case, not by category. The right answer might genuinely be “use the commercial product for this thing, self-host that other thing.” Mixed is fine. Maximalism is exhausting.
10. Plan for 2 a.m.
Imagine yourself: it’s 2 a.m., you’re in a foreign country, your phone has 30% battery, the wifi is slow, and the password manager that holds the credential to recover everything else is the thing that’s broken. What’s your plan?
This is not paranoia. It’s the situation that will happen, eventually, to anyone who self-hosts long enough. The plan should include: an offline backup of your password vault on a hardware key or printed paper in a safe location, a second authentication method on critical services, and a small amount of “I’ll deal with this when I’m home” tolerance built into your setup. If something breaking at 2 a.m. would be catastrophic, that thing should not be entirely self-hosted.
11. Don’t expose Plex, Jellyfin, or any media server to the public internet.
This deserves its own line because the temptation is real and the security history is bad. These services have all had remote-code-execution vulnerabilities. Run them inside Tailscale (or a similar mesh) so only your devices can talk to them. Yes, this means you can’t share with friends without giving them access to your tailnet (which is fine — it’s two clicks). The risk reduction is enormous.
12. Document your setup, in plain English, for Future-You.
Write a README.md for your self-hosted stack. Write down: what services run where, what domain points to what, what cron jobs do what, what the recovery procedures are. Update it when things change.
The audience is yourself, in eighteen months, having forgotten everything. Past-You is going to make decisions Future-You needs to understand. Write for the version of you that’s about to inherit this setup with no context.
I keep this README in the same git repo as my Docker Compose files, on the server itself, and replicated to a personal Obsidian vault. Belt and suspenders, but recovery from “I have no idea what this server is doing” is dramatically faster when you have written it down.
13. Decide what you’d do if you suddenly couldn’t maintain it.
The hardest lesson, and the one I’m still working out. If you got hit by a bus tomorrow, what happens to the people who depend on the services you’ve self-hosted? Does your spouse know how to recover your password vault? Does your aunt who relied on your Nextcloud share have a way to get her photos back? Is there a documented exit plan?
The privacy-tools community is good at telling you to control your own infrastructure. It is much less good at the succession planning that controlling your own infrastructure implies. Write down, somewhere your trusted people can find: how to recover the things that matter, who they should ask if they need help, what the migration path is if maintaining is no longer feasible.
You don’t have to solve this perfectly. You do have to think about it.
This is not a discouragement. I self-host more things now than I did three years ago, and I’m glad of every one of them. But the marketing makes self-hosting sound like a lifestyle upgrade. It’s not. It’s an operations job that you’ve assigned yourself. Once you accept that — once you stop expecting the experience to be like commercial SaaS but free — the trade-offs become clearer and the benefits stop feeling like tax for the freedom.
The reason to do this isn’t because it’s cheaper. It’s because, after the initial learning curve, you actually own the things you depend on. That ownership has a real, quiet weight, and it does add something to your life that no commercial subscription can quite replicate.
Just budget for the 2 a.m. nights along the way.
—
We’re working on full guides for Vaultwarden setup, Pi-hole on a Raspberry Pi, Nextcloud vs commercial alternatives, and self-hosted Tailscale (Headscale) setup. Subscribe to be notified when those publish.