Self-hosting

Running a service on infrastructure you control instead of renting it from whoever wrote it. The software is usually the same software; what changes is who is responsible when it stops working.

The claim and the bill

The pitch is control, and it is real: your data on your disk, no subscription, no vendor deciding your feature set, no account to be locked out of. hometube states the standard version of it — "No cloud dependencies, everything runs locally."

The cost is paid later and in a different currency, which is why the trade is easy to misjudge. Backups, upgrades, TLS certificates, disk pressure, an OS that needs patching, and — the one that actually decides whether a self-hosted install survives — somebody noticing when it breaks. A hosted service has a team paid to notice. A self-hosted one has whoever set it up, and their attention is not on a rota.

The sources here bracket the range. hometube is one container that a household can plausibly run for years. ever-gauzy is a monorepo application with PostgreSQL, Redis, OpenSearch, MinIO and Jitsu behind it, running the payroll-adjacent functions of a business, where the same operator now owns disaster recovery. openpanel sits between them at seven containers, three of which hold state, and alexandrie just below that at four containers, two stateful.

Only one of the three writes the bill down. OpenPanel's self-hosting docs say updating means reading the changelog and applying the changes to your instance, and that managed Redis needs a config flag set by hand. Naming the recurring chore is rarer in this corpus than promising there isn't one.

Relocation, not removal

The finding this corpus supports most strongly is that self-hosting moves a dependency rather than deleting one, and that the marketing consistently describes the move as a deletion.

HomeTube is the clean demonstration because both halves are in its own README. Storage and playback genuinely move in-house — the library is yours and nothing phones home to watch it. Acquisition does not move, and cannot: the tool needs cookies from an authenticated session because the upstream platform still decides what can be fetched, at what quality, using "encrypted signatures" the downloader has to keep up with. The operator is independent of a vendor's player and entirely dependent on a vendor's platform.

The test to apply to any self-hosting claim: name the resource the software needs that you do not own. If there is one, autonomy stops there. anysoftkeyboard passes the test by needing nothing remote at all, which is why it can promise more than either self-hosted service here.

alexandrie fails it in a way worth naming, because the failure is internal rather than external. It depends on no vendor — but its "one command" brings up four services, two of them stateful (MySQL 8.0 and an S3-compatible object store), and the README that promises "total ownership over your binaries, media streams, and backups" never mentions the database at all. The resource you do not own is nobody else's; it is the two backup jobs you have just acquired without being told. On the spectrum above it sits just under openpanel and well above hometube.

calibre's content server passes it too, and is the smallest self-hosted thing in the corpus: one desktop binary already on the machine, serving the library it manages over HTTP to a browser, with no container, no database process and no reverse proxy. The project says it works offline. It is worth naming because it breaks an assumption the sources above smuggle in — that self-hosting starts with a compose file. Here the operator installs an application for its own sake and the server is a checkbox inside it, so the recurring bill is whatever the desktop app already cost.

The operators have been counted once

self-host-user-survey-2025 asked 4,081 self-hosters what they run, and two of its numbers bear directly on the bill above. 85% update their containers manually or case-by-case; 15% automate it, and the survey attributes the reluctance to breaking changes — so the ongoing attention this page calls the deferred cost is not something these operators have failed to notice, it is work they have looked at and chosen to keep doing by hand. 34% keep their data in exactly one place and 542 respondents keep no backup at all, which is the closest thing this wiki has to a measure of what an unnoticed failure would cost.

The motives are the other surprise. Hobby (3,862 selections) outranks privacy (3,520) and cost (2,596). The pitch this page examines is an autonomy argument; the people running the software mostly say they are doing it because they enjoy it.

Read it as a survey of enthusiasts, not of operators generally: 81% work in technology and everyone found it through a self-hosting newsletter.

The case that comes closest to removal, and what is left (added 2026-09-07)

syncthing is the strongest test this page's rule has had. There is no server to rent, no host to administer and no account: two of your own machines connect to each other and sync. The storage dependency really is gone, which no other source here can say.

What remains is a rendezvous dependency, and the project documents it precisely. Global discovery resolves a device ID to an IP address; relays carry the traffic when two devices cannot reach each other directly, are "run by volunteers all over the world," and are on by default. The content stays end-to-end encrypted — a relay "only retransmits the encrypted data much like a router" — but "the relay knows your IP and device ID" and "the relay operator can see the amount of traffic flowing between devices."

So the answer to name the resource you do not own is: the rendezvous layer, run by strangers, used whenever NAT gets in the way. A real dependency and a much smaller one than a host — metadata rather than files, and only for connections that cannot be made directly.

The disclosure shape is worth separating from hometube's too. There, the loose claim was the marketing and the dependency was buried. Here the loose claim is the marketing ("There is no central server that might be compromised") and the dependency is in the manual, spelled out in more detail than a user would think to ask for. Summary looser than documentation is the ordinary failure; documentation that omits it is the other one.

Where the seam runs to other spokes

Operating a service in production — SRE, observability, incident response, the whole discipline of keeping distributed systems up — belongs to ../platform-ops-wiki. This spoke's interest is the decision and the operator: one person, no SLO, no on-call, deciding to take that work on. The two meet exactly at the question of what happens at 2am, and the answers are different because the staffing is.