The lab / general map
This is enough context to make the storage and playback articles understandable. The arrangement grew from a straightforward media server into separate software, shared storage and a network that all of them rely on. It was not designed all at once on a whiteboard by somebody wearing a clean lab coat.
The sections explain the jobs and dependencies, not an exact inventory or deployment diagram. There are many valid ways to run a home server; the interesting part is what each extra layer gives you and what new failure it makes possible.
I keep every layer understandable enough to repair when I am already annoyed, because that is exactly when a clever undocumented shortcut becomes folklore.
The layers below describe responsibility rather than exact physical placement. Their most important feature is the connection between them: applications depend on compute, many services depend on shared storage and all of it depends on a network that should not require daily encouragement.
A home network links the devices to each other and to the internet. Wired connections are worth considering for fixed equipment because they remove the variability of wireless signal. Wi-Fi remains the right tool for phones and moving devices. Managed networking can show more detail when a connection misbehaves, but a simpler router is sufficient for many homes. Exact devices and rules are not part of this public map.
The physical computer provides processing power; Proxmox can divide it into separate environments, and Docker can package smaller applications. That division helps with maintenance and recovery. Running everything directly on one computer is simpler when there are only a few programs. Separating software does not erase shared dependencies such as storage and networking.
A NAS keeps shared files apart from the programs that use them. That makes storage management independent, but it also makes the network connection part of the storage system. The faster-connection experiment described in the field notes lost that reliability; returning to the known working arrangement mattered more than its peak speed. Directly attached drives would remove that network dependency for a simpler setup.
Plex provides a familiar way to find and watch a library on household devices. Jellyfin is an alternative with a different approach to local control. Neither removes the need for the viewing device to understand a file's picture, sound and subtitles. Running a second platform can help compare behaviour, but it also means maintaining another application.
Backups help recover data or an entire service after mistakes or hardware trouble. Basic checks can tell an owner whether a device or page answers. More sophisticated monitoring becomes useful only when it answers a question worth acting on; a mystery that runs on a schedule is still a mystery, only more punctual.
How it grew
The current setup can look like the result of a master plan. It was mostly the result of solving the next visible limitation. More storage moved data to a NAS. More services made separation and backups valuable. Remote access increased the importance of network security. An intermittent storage path justified monitoring.
Each step was reasonable on its own. Together they created a system with enough relationships that changing one part can have distant consequences. This is why the field notes focus less on installation and more on what happened after everything had been running for a while.
Failure boundaries
Virtual machines and containers reduce the chance that one application update damages every other service. They do not prevent a failed NAS connection from affecting every application that needs the same files.
The dependency map matters more than the number of separate boxes shown in a dashboard. Isolation helps with software changes. Shared storage, network and power still define the larger failure boundaries.
What is omitted
The public version leaves out addresses, names, credentials, exact storage paths, firewall rules and complete configurations. It also avoids publishing raw logs because logs have a habit of containing details that were not obvious in the first screen.
That limitation is deliberate. The purpose of this page is to explain why the parts depend on one another. Anyone who needs the private operational details is already inside the house and can consult the private documentation.