A service can be open source, privacy-friendly and technically interesting while still being the wrong thing for me to operate. Every service adds updates, storage, monitoring, backups, permissions and another failure mode. The aim is not to recreate every cloud product at home. The aim is to keep control where control is valuable without turning the homelab into a second job.

I do not self-host everything

I am cautious about services that handle especially sensitive information, need constant availability or have a large operational burden. A hosted provider can be the more sensible choice when it offers better security, accessibility or recovery than I could realistically provide myself.

That is not a failure of self-hosting. It is the point of making a deliberate choice instead of following a slogan.

Email is where I draw the line

I deliberately do not self-host email. Reliable delivery requires reputation management, filtering, authentication, security, storage, backups and recovery. AI-powered filtering and mailbox automation add another layer of risk because sensitive messages may be processed by systems that can be manipulated by malicious content or given too much access.

For me, hosted email with my own domain, clear export options and independent backups is the more sensible choice. That is not giving up on digital ownership; it is choosing not to operate a difficult and security-sensitive service when the benefit is not worth the work.

Questions I ask first

Before adding a service, I ask:

• What problem does it solve for me?
• Can I export the data in a useful format?
• Can I back up and restore it without guesswork?
• What happens if the project stops being maintained?
• Does it need internet exposure or privileged access?
• How often will it need attention?
• Would I still want to operate it after the novelty disappears?
• Is a hosted alternative cheaper in time and risk?

If the answers are weak, I do not add it simply because it is popular.

What I prefer to self-host

Self-hosting makes the most sense to me for services where local control has an obvious benefit:

• personal photos and media;
• documents and bookmarks;
• local DNS and network services;
• monitoring and notifications;
• backups and recovery tooling;
• services where a provider could change access, pricing or availability;
• data that I want available on my own network even when the internet is unavailable.

These still need sensible backups and security. Local does not mean indestructible.

The practical answer

The right question is not “Can I self-host this?” Almost anything can be made to run somewhere.

The better questions are:

Does operating this service improve my control, resilience or privacy enough to justify the work?

Can I leave it later without losing the data?

If the answer is no, I would rather use a hosted service, keep a local export, or not use the service at all.

That is a more useful form of digital ownership than collecting dashboards.

Features disappear. Prices change. Limits arrive. Advertising takes over. A product that began as useful becomes harder to use, less private or dependent on an account that can be closed.

Cory Doctorow calls this process enshittification. In Enshittification: Why Everything Suddenly Got Worse and What to Do About It, he argues that platforms can first attract users with convenience, then lock in users and businesses before shifting value away from both groups.¹ The Creative Salon article supplied alongside this book is another useful reference point for the discussion.²

What this has to do with self-hosting

Self-hosting is not a cure for every problem. It does not remove the need for electricity, updates, backups, domains, broadband or sensible security. It also does not mean every cloud service should be replaced.

It does provide something valuable: an alternative place for important data and services to exist.

A local photo library means a company changing its storage rules does not become the only authority over the family archive. A self-hosted media server means access to an owned collection does not depend entirely on one catalogue or subscription. An encrypted backup means a hardware failure is not automatically a permanent loss. A service such as Karakeep can keep bookmarks and saved material in a system you can back up and inspect.

The goal is not technological purity. The goal is to avoid making one company the only place where an important service, memory or copy of a file exists.

The practical test

Before adopting a service, ask:

• Can the data be exported?
• Is the export usable somewhere else?
• Does it work without a mandatory cloud account?
• Are open formats or documented APIs available?
• Can the application data be backed up and restored?
• What happens if development stops?
• What happens if the company changes its pricing or licence?
• Can the service be replaced without losing the underlying data?

A nominal export is not necessarily an exit route. A collection of files that cannot be opened elsewhere is only a different kind of lock-in.

A balanced approach

Cloud services remain useful. They can provide availability, collaboration, off-site protection and less maintenance. The mistake is not using them. The mistake is allowing a provider to become the only copy, the only login and the only route to something important.

A reasonable arrangement is often mixed:

1. Use a hosted service where it is genuinely convenient.
2. Keep local copies of important data where practical.
3. Prefer open or widely supported formats.
4. Maintain an independent backup.
5. Test restoring something before it is urgent.
6. Know what you would use if the provider disappeared.

This is why the principle here is simple: keep it simple, keep it local, keep a copy.

Self-hosting is not about building a private version of every website. It is about keeping enough control that a platform becoming worse does not automatically make your own data, memories or workflow worse with it.

Sources