When Not to Self-Host
Self-hosting is not a moral obligation. It is a trade-off.
Running your own services can give you privacy, control, portability, and deep technical understanding. It can also give you 2am alerts, broken upgrades, spam reputation problems, and a new hobby you did not ask for.
Do not self-host what you cannot maintain
If a service needs regular security updates and you will not apply them, do not expose it to the internet.
This matters for:
- Mail servers
- Identity providers
- Password managers
- Public file sharing
- Federated social platforms
- Anything with user uploads
Self-hosting without maintenance is not freedom. It is risk.
Email is the classic trap
You can self-host email. Many people do.
But deliverability, spam filtering, DNS records, IP reputation, abuse handling, and mailbox recovery make email unusually demanding. For most projects, a privacy-respecting hosted mail provider is a better default.
Run your own mail because you want to learn or because your requirements justify it, not because it looks like a simple checkbox.
Use managed FOSS when the data matters
There is no shame in paying for managed open source.
If Nextcloud is critical to a team, a managed provider with tested backups may be more aligned with FOSS values than a neglected VPS under one person’s desk.
The right question is: can you leave with your data and keep using the same open software elsewhere?
If you want managed FOSS hosting that uses the same providers and tooling you’d pick yourself — OpsHelp runs on Hetzner and Cloudflare with documented, portable configurations.
Self-host the things that benefit from control
Good self-hosting candidates:
- Static websites
- Documentation
- Git mirrors
- Internal dashboards
- Monitoring
- RSS readers
- Small web apps
- Development tools
These are easier to back up, easier to migrate, and less likely to harm users if something breaks.
A quick decision checklist
Before you spin up a new service, run it through five questions. If you answer “no” to any of the first four, you are signing up for risk you may not want.
- Maintenance — Will you actually apply security updates within days of release, not months?
- Backups — Do you have automated, off-site, tested backups, and do you know the restore steps?
- Recovery time — If the box died tonight, could you rebuild it from notes in an afternoon?
- Blast radius — If it breaks or leaks, who is harmed — just you, or your users?
- Motivation — Are you doing this to learn or because the requirements justify it, or just because the install command was short?
A “yes” to all five is a green light. A “no” on backups or blast radius is a strong signal to use a managed option instead.
Count the cost of failure, not just the cost of hosting
The €5/month VPS is the cheap part. The real cost shows up when something goes wrong: hours spent chasing a deliverability problem, a weekend lost to a botched upgrade, or — worst case — a breach of data you were responsible for.
When you compare self-hosting to a managed FOSS provider, put the expected operational cost on both sides of the ledger: your time, the probability of an incident, and the consequences if one happens. For low-stakes services the math favours self-hosting easily. For anything that holds user data or money, a managed provider with real backups and an on-call rotation is often the more responsible — and cheaper — choice.
A useful rule
If downtime would merely annoy you, self-hosting is often fine.
If downtime would harm users, block donations, lose legal records, or compromise sensitive data, either invest properly in operations or use a trustworthy managed provider.
FOSS values include responsibility.