How-To Geek’s Jorge A. Aguilar describes five everyday-PC workloads: Jellyfin, Pi-hole, Vaultwarden, Syncthing paired with Photoview, and Uptime Kuma. It is a useful starting lineup, but the projects’ own documentation adds several important qualifications—particularly around Jellyfin’s Windows support, password-vault security, and the difference between photo synchronization and backup.
What Docker Desktop changes—and what it does not
With Docker Desktop’s WSL 2 backend, Linux containers run in a managed Linux environment. Docker documents dynamic memory allocation and currently specifies WSL 2.1.5 as the minimum, while recommending an up-to-date WSL installation and compliance with its Windows system requirements. That makes an existing PC a practical experimentation platform, not a guarantee that every workload will be negligible.
Storage deserves attention before collecting containers. Docker’s WSL 2 guidance says Linux-filesystem bind mounts perform substantially better than accessing files through the Windows host filesystem. Separately, Docker warns that bind mounts are writable by default: a container can modify or delete the host files it receives unless access is restricted.
The practical lesson is straightforward: decide which data must persist, which folders an application may change, and what would happen if the PC became unavailable.
1. Jellyfin: useful media hosting, with a support boundary
Jellyfin can organize and serve a personal media library, and its official container configuration separates configuration, cache, and media storage. Its examples also demonstrate read-only media mounts, a useful option when the server only needs to consume an existing collection.
However, Jellyfin explicitly does not support containers hosted on Windows or macOS. Its documentation recommends native installation on those platforms and identifies hardware-accelerated transcoding among the features known to be broken outside Linux container hosts. A container that starts successfully is not necessarily a supported deployment.
For Windows readers, that changes the recommendation: experiment with the container if you understand the limitation, but prefer Jellyfin’s native Windows installation when following the project’s supported path. Do not assume a gaming GPU will automatically become a working container transcoder.
Aguilar also describes slow scans through Windows-mounted storage. Docker’s guidance supports the broader performance concern, but not a universal scan time or an inevitable playback stall. Treat storage layout as something to evaluate with your library, rather than importing somebody else’s stopwatch results.
2. Pi-hole: DNS filtering makes your PC infrastructure
Pi-hole’s Docker configuration publishes DNS on both TCP and UDP port 53 and preserves its configuration through mounted storage. Those details matter: making its administration page accessible does not, by itself, establish that household devices are successfully using its DNS service.
The Windows port-conflict warning needs precision. Microsoft documents that Internet Connection Sharing, whose service name is SharedAccess, provides DNS services on its private network interface. That establishes a possible conflict—not that every Windows PC already has port 53 occupied. Disabling Internet Connection Sharing indiscriminately is therefore not a sensible first step; identify the actual conflict and consider what depends on that service.
There is also an architectural consequence. If the household depends exclusively on the Pi-hole instance, its Windows host becomes a dependency for name resolution. Sleep, shutdown, or a stopped container can interrupt that service. This follows from the deployment arrangement, rather than being a special Docker defect.
Practical takeaway: test Pi-hole with a limited set of devices before making it a network-wide dependency. Plan how to restore working DNS if the host is unavailable.
3. Vaultwarden: small deployment, serious responsibility
Vaultwarden’s upstream project describes it as an unofficial Bitwarden-compatible server written in Rust. That is a more accurate description than treating it as the official Bitwarden server with identical support and compatibility guarantees.
Its maintainers explicitly state that the web vault requires HTTPS and a secure context for the browser’s Web Crypto API. They recommend a reverse proxy and demonstrate persistent storage mounted at /data. Simply publishing the container’s HTTP port is not a complete secure deployment.
Before entrusting it with your primary credentials, establish three things:
- HTTPS works correctly from the devices you intend to use.
- Persistent vault data is included in a deliberate backup plan.
- You can restore that backup, rather than merely confirm that a backup file exists.
Those are operational recommendations based on the project’s HTTPS, persistence, and backup documentation—not claims of firsthand testing. Vaultwarden maintains a dedicated backup guide, underscoring that recovery is part of running the service, not an optional finishing touch.
The compelling feature is control. The corresponding obligation is becoming the person responsible when synchronization or recovery stops working.
4. Syncthing and Photoview: distinguish copying from protecting
This entry is a combined workflow, not literally one container. In Aguilar’s arrangement, Syncthing runs natively on Windows to synchronize photos into a normal folder, while Photoview supplies a self-hosted gallery through Docker. Photoview’s own project describes it as a photo gallery for personal servers.
The essential correction comes from Syncthing itself: creation, modification, and deletion can propagate between devices. Its documentation explicitly distinguishes synchronization from an ideal backup solution. A second synchronized copy is useful, but it is not automatically protection against an accidental deletion being faithfully repeated elsewhere.
Android users also need a platform-specific clarification. The discontinued component was the official Syncthing Android wrapper, whose repository was archived on December 3, 2024—not the entire Syncthing project. A community Syncthing-Fork project exists separately.
Practical takeaway: use synchronization for convenient transfer and a separate recovery strategy for irreplaceable photographs. Adding a gallery improves browsing; it does not turn synchronization into backup.
5. Uptime Kuma: a dashboard cannot watch its own blackout
Uptime Kuma supports checks including HTTP(S), TCP, ping, DNS records, and Docker containers, with notification integrations such as Discord, Telegram, and email. Its official Docker example preserves application data in a volume and publishes its interface on port 3001.
That makes it useful for seeing whether individual services are responding. But placing the monitor beside everything it monitors creates a shared failure point: when that Windows machine is asleep or unavailable, the monitoring application cannot execute checks or send live alerts either. This is an architectural limitation of the arrangement, not evidence that Kuma necessarily produces a particular burst of notifications after every reboot.
Use it to understand service health while the host is operating. If detecting failure of the whole PC is important, the monitoring perspective must also exist somewhere independent of that PC.
Start with convenience, then decide what needs reliability
These five workloads make a persuasive case for experimenting with hardware you already own. They do not make an equally persuasive case for treating every service as equally disposable.
The useful dividing question is: What breaks when this PC stops? A temporarily unavailable gallery may be acceptable. Household DNS and access to password-vault synchronization deserve more deliberate planning.
Start small, preserve persistent data, respect each project’s platform boundaries, and test recovery before relying on the result. You may not need another computer—but you still need an operating plan.