When not to self-host

Most of this site is about how to run things. This page is about the four or five times a year you should not. The people who stay in self-hosting for a decade are not the ones who host everything; they are the ones who picked a boundary early and kept it.

The decision test#

Before you migrate anything off a paid service, answer these five out loud. They take two minutes and they are more useful than any feature comparison.

1. If this is down for 72 hours while you are unreachable, who is harmed, and can they route around it? If the answer includes someone who did not choose this, you have taken on an obligation, not a hobby.
2. If the data is destroyed, where is the other copy, and when did you last restore from it? "I have backups" is not an answer. "I restored one in March" is.
3. Does success depend on a third party that does not know you exist? Deliverability, app store review, a vendor API you do not control. You cannot fix a reputation problem with a better config.
4. Is there a second person who could bring it back without you? Not who would want to. Who could.
5. Would you notice a silent failure within a week? Not a crash. A backup job that stopped running, a disk that started returning errors, a sync that quietly stopped.

Two or more uncomfortable answers is a signal to keep paying someone. That is not a defeat. It is the correct use of money.

Email#

This is the canonical bad case and it deserves the specifics rather than the folklore.

Receiving mail on your own server is genuinely fine. Sending it so that it lands in inboxes is a reputation system you are not a member of. Google's published requirements for anyone sending to Gmail include a valid forward and reverse DNS record on the sending IP, SPF and DKIM set up on the sending domain, TLS on the connection, and a spam rate kept below 0.3% as measured in their Postmaster Tools, with 0.1% recommended as the working target. Bulk senders above 5,000 messages a day additionally need DMARC and one-click unsubscribe.

You can satisfy every technical item on that list and still be filtered, because the remaining variable is the history of your IP address and your domain, neither of which you can inspect and both of which start neutral at best. Consumer ISP address space and cheap VPS ranges start worse than neutral. Outbound port 25 is blocked by default on most residential connections and throttled or blocked on several cloud providers until you file a request.

Before you spend a weekend on this, spend two minutes finding out whether the internet will accept mail from you at all:

IP=$(curl -s https://ifconfig.me)
echo "sending IP: $IP"
dig +short -x "$IP"                       # PTR: is it your domain, or your ISP's generic name?
dig +short TXT example.com | grep -i spf1  # SPF record present?
dig +short TXT _dmarc.example.com          # DMARC policy present?
nc -zv -w 5 gmail-smtp-in.l.google.com 25  # can you even reach port 25 outbound?

A generic PTR such as host-203-0-113-45.isp.example that you cannot change, or a nc that hangs, ends the discussion. Both are normal on residential and low-cost VPS address space.

The failure mode is what makes it dangerous: no bounce, no error, a 250 OK and a message in someone's spam folder. You find out when a job application, an invoice or a school form goes unanswered.

The honest middle path is to run the mailbox and rent the sending. Host a full mail stack if you want, but relay outbound through a transactional provider with an established reputation, and keep a second address on a service you do not run for anything with consequences. Replace Gmail goes through what that migration actually costs.

Anything the household depends on, with one admin#

The test is not whether you can build it. It is what happens on the Tuesday you are in another timezone and it breaks.

DNS-level ad blocking is the sharpest example. Pi-hole and AdGuard Home are excellent, low-load services, and they are also the single most load-bearing thing you can put on a home network: when the DNS server stops answering, nothing resolves for anybody, and the symptom presented to your family is "the internet is broken". Pi-hole's v6 rewrote every Docker environment variable and removed the static API token; AdGuard Home's schema_version migrations are one way and it rewrites AdGuardHome.yaml underneath you while it runs. Neither is unsafe. Both are upgrades where a bad ten minutes takes the house offline.

If you run one anyway, and many people should, do two things: hand out a second, unfiltered upstream resolver as the secondary DNS server in DHCP, and write the one-line recovery instruction on paper where someone else can find it.

The same test applies to Home Assistant the moment automations control lights, locks or heating. It is a 600 MB, operational-load-4 system that ships monthly, deprecates aggressively, and whose custom components regularly break on release day. That is a fine trade for you. It is a bad trade for a housemate who cannot turn on the bathroom light because an integration failed to load. Keep physical switches working.

Password managers, if you will not do backups#

There is a version of self-hosted password management that is straightforwardly better than the alternative: an encrypted vault, on hardware you control, with an offsite backup you have restored. There is another version that is worse than any commercial product, and the difference between them is entirely whether you do the boring part.

Vaultwarden stores everything under one directory: db.sqlite3, attachments/, and the rsa_key* files that sign auth tokens. Copying that SQLite file while the server is writing to it, which is what a naive nightly cp does, produces a backup that restores into a corrupt or truncated vault. You will not find out until the day you need it, which is by definition the worst day.

Here is the test. If you will not run this monthly, use a hosted vault:

# Correct hot backup of a Vaultwarden SQLite database, then verify it.
sqlite3 /srv/data/vaultwarden/db.sqlite3 ".backup '/tmp/vw-check.sqlite3'"
sqlite3 /tmp/vw-check.sqlite3 "PRAGMA integrity_check;"   # must print exactly: ok

# And prove the offsite copy is real, not just present.
restic restore latest --target /tmp/restore-test --include /srv/data/vaultwarden
ls -l /tmp/restore-test/srv/data/vaultwarden/

The uncomfortable truth a self-hosting article usually skips: for a person who genuinely will not do this, a commercial password manager with a tested recovery process protects their data better than your server does. Replace LastPass or 1Password is worth reading either way, because the argument for leaving is real; it is just not an argument for skipping backups.

Public-facing services on a residential connection#

A personal site with a hundred visitors a day is fine on a home line. What you are signing up for, and should say out loud:

• Asymmetric upload. Typical residential upload is a fraction of download. Anything that saturates it degrades every video call in the house.
• A dynamic address, and often CGNAT, which means no inbound connections at all without a tunnel.
• Terms of service that frequently prohibit running servers, and blocked inbound ports on many providers.
• No DDoS absorption. A trivial flood aimed at your address takes out your household's internet, not just your service.
• Your home address in DNS. A public A record on a residential IP is a geolocatable data point about where you live.

The right shape for most people is: private services stay private behind an overlay network (Remote access without port forwarding), and anything genuinely public lives on a small VPS with a tunnel back, or in front of a CDN. That is not less self-hosted. It is the same software with a better blast radius.

Anything where the failure mode is losing photos of dead relatives#

This is the category that matters most and gets the least honest treatment.

Immich is one of the best projects covered here, and it is also a system where the trash is not a soft view over preserved copies: emptying it removes originals from UPLOAD_LOCATION for real, and the mobile app offers to free up space on your phone after upload. Downgrades are unsupported even within a minor version, because migrations run forward on startup, so the recovery path from a bad upgrade is the database dump you took before it. It idles around 900 MB with Postgres and a machine learning container behind it and scores 3 out of 5 on operational load.

None of that is a criticism. It is a description of a system that must be backed up properly, and the specific mistake people make is treating replication as backup. Syncthing's own FAQ states plainly that it is not a good backup application because every change, deletions included, propagates to all devices. Three copies of a deleted folder is zero copies.

The rule: until you have restored a photo library from your offsite backup into an empty directory and opened one of the files, the cloud service you are migrating away from is still your primary. Keep paying for it for a year. That year costs less than the alternative.

Where self-hosting genuinely wins, and why#

Being fair about this is the point of the page.

• Media you already own the files for. Jellyfin gates nothing: hardware transcoding, remote access and downloads are features rather than entitlements. That contrast got sharper when Plex Media Server began requiring a Plex Pass on the server side, or a Remote Watch Pass on the viewer's side, for remote playback of your own files, with enforcement reaching the major TV platforms in April 2026. When the vendor can put your own library behind a subscription, running the server yourself is the durable option. Same argument for Navidrome and Audiobookshelf.
• Paper archives. Paperless-ngx turns a filing cabinet into full-text search, and its export format is documented and self-contained. There is no equivalent subscription doing this well, and the data is yours in a plain directory.
• Anything priced per seat or per gigabyte. Wikis, feed readers, bookmarks, budgets: linkding at 90 MB and one container, or FreshRSS at 90 MB, will outlive several rounds of SaaS pricing changes.
• Anything a vendor can switch off. Local-first home automation survives a company retiring its cloud. Cameras, hubs and doorbells that depend on a vendor API are one product decision away from being landfill.
• Privacy that is actually structural. Search, notes and photos where the only copy is on your disk is a different guarantee from a privacy policy.

What to do next#

Run the five-question test on the one service you are currently tempted by. If it passes, start with Your first self-hosted server and get the backup working before the service does. If it fails on question two, fix that first: Backups that actually restore is short and it is the difference between a hobby and a liability.