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

This list deliberately excludes tools already used here, including Beszel, Dockhand and youtube-dl workflows. Karakeep is also excluded as a recommendation because it is already in use and has proved to be good in practice.

Homelable — worth testing

Homelable is a self-hosted homelab infrastructure visualiser with an interactive network diagram and live status monitoring.¹

This is interesting because a homelab eventually becomes difficult to explain. A diagram that reflects service status could be useful for documenting hosts, networks and dependencies without maintaining a completely separate diagram by hand.

The project is still a watch-and-test item rather than a recommendation. Check authentication, how stale or missing services are represented, whether the diagram can be backed up or exported, and whether the licence is clear before relying on it as the authoritative record of a network.

Status: Worth testing.

Open questions: maturity, licence, authentication and accuracy of live discovery.

Pangolin — worth testing cautiously

Pangolin is a self-hosted networking and security platform built around WireGuard, with zero-trust VPN access, reverse proxying, identity-aware access and a dashboard.²

It is not an obvious replacement for Tailscale when Tailscale is already working well. Its interest is different: it may give a self-hoster more control over the access and publishing layer, particularly when private services need to be reached through a central gateway.

Pangolin is security-sensitive and appears to be moving quickly. The Community Edition is reported as AGPL-3.0, while additional enterprise functionality uses a commercial licence, so the current boundaries need to be checked carefully.³ Client compatibility, identity-provider integration, failure recovery and upgrade procedures should all be tested before putting it in front of important services.

Status: Watching, with a possible controlled test.

Flags: security-sensitive; licence boundaries need checking; not a casual Tailscale replacement.

youtube-dl-nas — useful idea, but already tested here

youtube-dl-nas provides an authenticated yt-dlp queue for NAS use, including video, audio, subtitles, mobile sharing, restart-safe downloads and Docker.⁴

The project matches a real self-hosting need: turning downloads into a controlled queue rather than relying on a desktop session. It is also a good example of a narrowly focused tool solving one practical problem.

It is not a new recommendation here because it has already been used. Anyone evaluating it should still check authentication storage, cookie handling, download legality, update behaviour when yt-dlp changes and whether the project has enough maintenance depth for their collection.

Status: Previously tested; not a new candidate.

Dockhand — already useful here

Dockhand is a Docker management application with container management, Compose stack support, remote-host features, logs and an in-browser shell.⁵

Its practical value here is not replacing manually written Docker Compose files. It is useful for checking containers and managing updates while keeping the Compose definition as the source of truth. That separation matters: a UI should make routine operations easier without hiding how the service is actually deployed.

Docker management interfaces deserve careful treatment because they can have host-level privileges. Authentication, remote-agent security, secret handling and audit behaviour should be checked before exposing one outside the local network.

Status: Used here; positive practical experience.

Beszel — already used here

Beszel is a lightweight monitoring system with historical data, Docker statistics and alerts.⁶ A 0.19.0 release was published on 3 September 2026.⁷

It is already used here, so it belongs on the app shelf rather than this list of new things to try. Its continued release activity is worth tracking, but repeating the recommendation would add little value.

Status: Used here; report updates rather than recommend again.

What I would test first

If I were starting a small evaluation, I would begin with Homelable because it fills a documentation and visibility gap rather than duplicating an existing service. Pangolin would come next, but only in an isolated test path with a rollback plan. The other projects are either already used or already tested here.

That is the useful distinction: a project can be interesting without being a new recommendation for a particular homelab.

Sources