Synchronisation keeps copies convenient

Synchronisation keeps data available on more than one device. Syncthing is useful for this kind of direct device synchronisation, and it makes working files available where I need them.

But synchronisation also copies mistakes. If a file is deleted, corrupted or encrypted, that change may travel to the other copy. Synchronisation improves availability; it does not replace a backup.

A backup gives you a recovery point

A backup is a separate copy that can take you back to an earlier state. It should be protected from the normal failure of the source and should be possible to restore without relying on memory.

For my homelab, that means thinking about:

• what data is included;
• how often it is copied;
• how long old versions are retained;
• whether credentials are protected;
• whether the backup is encrypted;
• whether the restore procedure has been tested.

Restic is useful for encrypted, verifiable backup jobs, but the tool alone does not create a complete backup strategy. The source paths, schedule, retention and restore test matter just as much.

Preservation keeps meaning and access

Preservation is a longer-term job. It is not only about keeping bytes. It also means retaining enough context to understand what the files are, checking that they have not silently changed, using formats that remain practical to read, and keeping more than one recovery path.

For web material, a saved URL is not preservation. The page may change or disappear. Tools such as ArchiveBox can create local captures, while larger institutional workflows such as Archivematica show how preservation involves ingest, processing, metadata and access.

A simple test

For each important item, ask three questions:

1. Do I need it available on another device? That is synchronisation.
2. Do I need to recover an older version after loss or damage? That is backup.
3. Do I need to understand and access it years from now? That is preservation.

The same file may need all three, but the design is different for each job.

How this applies to my lab

The live data on TrueNAS-Normandy is the working copy. Replication to another system can provide another local recovery path, but it should not be treated as the only backup. Restic configuration backups protect the information needed to rebuild services, while service data and databases need their own explicit inclusion and restore plans.

The most important question is not “Where is the copy?” It is:

Can I prove that I can find, understand and restore the thing I care about?

That is the difference between having copies and having a recovery system.

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.

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