Home Media + Automation Server

This project is a self-hosted home server built on a repurposed desktop running Ubuntu. The goal was to create a reliable personal server for media streaming, remote access, local file storage, automation, and future experimentation with local AI tools.

The project started as a way to host a personal media library, but it grew into a broader systems project involving Linux administration, Docker containers, private networking, public tunneling, file permissions, storage management, service reliability, and automation.

The server currently supports media streaming, private remote administration, local network file sharing, and automated media organization. Jellyfin provides the media interface, while Docker keeps the main services isolated and easier to manage.

The public-facing media site is available at watch.danielwendland.com. The server also has private remote access configured separately for administration, so public access and admin access are not treated as the same thing.

This project is intentionally documented at a high level here. Sensitive details such as private IP addresses, usernames, internal credentials, tokens, exact tunnel identifiers, and private configuration values are not included.

The server uses Ubuntu as the host operating system and Docker to run application services. The main storage drive is mounted as a dedicated media and data volume. Media files are organized into separate library folders for movies and TV shows, which are then exposed to Jellyfin.

Cloudflare Tunnel is used to make the Jellyfin web interface reachable through a custom domain without exposing the entire home network directly. Tailscale is used for private administrative access, which allows secure remote management without opening traditional inbound admin ports to the public internet.

Samba file sharing is also configured so files can be moved and managed from other machines on the local network.

Jellyfin is the core media application. It scans organized media folders and provides a browser-accessible interface for watching movies and shows. The setup prioritizes direct play whenever possible because direct play is much more efficient than transcoding.

One of the main performance considerations was matching media format choices to the server hardware. The server is better suited for 1080p direct-play content than heavy 4K transcoding. For that reason, the preferred media format is practical and compatibility-focused: 1080p video, common codecs, and standard subtitle formats.

The automation stack is built around Prowlarr, Radarr, Sonarr, and qBittorrent. Prowlarr manages indexer connections centrally. Radarr handles movie organization. Sonarr handles TV organization. qBittorrent acts as the download client.

The general workflow is that a movie or show is added through the appropriate application, the automation tools search for matching releases, the download client retrieves the file, and the completed file is imported into the organized media library. Jellyfin then detects the updated library content.

This stack required careful coordination between applications running inside Docker and applications or services interacting with host-level storage.

The most important technical challenge was path mapping between the host machine, Docker containers, and the download client. The host operating system sees storage paths one way, while Docker containers see mounted volumes through container-specific paths.

At one point, completed downloads were visible to the download client but could not be imported by the automation tools because the applications were referring to different versions of the same storage location. The fix was to configure remote path mappings so the automation tools could correctly translate host paths into container paths.

This was a useful lesson in Docker volume mapping, filesystem permissions, and how multi-service automation stacks communicate across boundaries.

The networking design separates public access from private administration. The media interface is reachable through a custom domain, while administrative access is handled through a private network layer.

This separation is important because a media website and a server administration channel have different security needs. The public side should expose only what is necessary for media access. The private side should be reserved for trusted devices and server maintenance.

I also configured the server so important services can survive restarts and continue running without needing to be manually relaunched after every reboot.

The public writeup intentionally avoids sensitive implementation details. It does not include private IP addresses, login names, passwords, API keys, tunnel tokens, exact internal paths that are not needed for explanation, or private account details.

From a design perspective, the project uses separation of concerns: public media access is handled through a tunnel, private administration is handled separately, and individual services are isolated where possible. The goal is to make the system usable without unnecessarily exposing the underlying machine.

This project taught practical Linux server administration in a way that a normal class project usually does not. I had to work through storage mounting, Docker containers, networking, public DNS, service restarts, firewall-style thinking, file sharing, remote access, and troubleshooting.

It also helped me understand how real systems fail. Most of the hard parts were not about installing one application. They were about making several tools agree on storage locations, permissions, networking rules, and startup behavior.

The project gave me hands-on experience with self-hosting, system design, and debugging across multiple layers of a stack.

Future improvements could include a cleaner status dashboard, better backup automation, expanded monitoring, stronger alerting, and a dedicated local AI workspace. Another possible extension is to use the server as a private development environment for running local models, testing automation scripts, and hosting small internal tools.

The long-term goal is to keep the server useful as both a personal media system and a practical home lab for learning infrastructure, automation, and applied AI.