Plex Homelab Architecture: Storage, GPU Transcoding, and Library Design

A beginner-friendly but technical architecture guide for building a Plex, Sonarr, Radarr, SABnzbd, Prowlarr, and Tdarr homelab that is fast, recoverable, and easy to operate.

Who this is for: This guide is written for someone new enough to need the concepts explained, but detailed enough for a technical homelab builder to turn it into real configuration decisions.

Why Architecture Matters Before App Settings

Most Plex homelabs start with one app and one folder. That works until the library grows, multiple users start streaming, downloads happen during playback, and background transcoding begins competing with Plex for GPU time. At that point, the problem is rarely a single bad checkbox. The problem is architecture. A stable Plex and Arr environment needs a clear separation between media storage, application configuration, download staging, transcode cache, GPU work, reverse proxy access, and backups.

The beginner version is simple: Plex should serve clean final media folders, Sonarr and Radarr should organize media, Prowlarr should centralize indexers, SABnzbd should download into staging folders, and Tdarr should optimize completed media after import. The technical version adds a few rules: consistent paths, predictable Linux permissions, local cache for heavy temporary writes, scheduled GPU workers, safe remote access, and configuration backups stored away from the host.

Series note: This is the foundation article for the Plex and Arr homelab series. The later Sonarr, Radarr, Prowlarr, SABnzbd, storage, GPU, reverse proxy, backup, and monitoring guides all build on this architecture.

The Core Components

• Plex Media Server is the playback layer. It should read final media folders and avoid heavy background work during peak viewing.
• Sonarr is the TV authority. It tracks series, episodes, monitoring, quality profiles, imports, and upgrades.
• Radarr is the movie authority. It tracks movies, root folders, custom formats, lists, imports, and upgrades.
• Prowlarr is the indexer manager. It keeps Usenet and torrent indexers consistent across Sonarr and Radarr.
• SABnzbd is the download worker. It should use local incomplete storage when possible and leave final organization to Sonarr and Radarr.
• Tdarr is the post-processing engine. It should process final imported media, not incomplete downloads, and it should notify Plex and the Arr apps after replacements.

A Clean Data Flow

1. A movie, episode, or list item is added to Radarr or Sonarr.
2. Radarr or Sonarr searches indexers that Prowlarr manages.
3. A selected release is sent to SABnzbd using the correct category.
4. SABnzbd downloads, repairs, and unpacks into a download staging folder.
5. Radarr or Sonarr imports the completed file into the final media root.
6. Plex scans the final media library and exposes the title for playback.
7. Tdarr waits for the file to settle, then transcodes or skips it according to policy.
8. Tdarr validates the output before replacement.
9. Tdarr refreshes Plex and triggers a Radarr or Sonarr rescan so metadata, codec, size, and MediaInfo stay current.

The Folder Model

The cleanest setup uses one shared top-level data path that every media app understands. That does not mean every file lives on one physical disk. It means the applications see the same logical layout. This prevents the classic problem where SAB reports one path, Radarr sees another path, and imports fail because both applications are technically correct but not speaking the same filesystem language.

/data
  /downloads
    /usenet
      /movies
      /tv
    /torrents
      /movies
      /tv
  /media
    /movies
    /movies-animated
    /movies-comedy
    /tv
  /transcode
    /plex
    /tdarr

For a beginner, the rule is: downloads are temporary, media folders are final. For a technical user, the rule is: avoid cross-filesystem moves when you want hardlinks or atomic imports, avoid network storage for high-churn temporary writes, and make sure every application sees paths consistently.

Local Disk vs NAS Storage

NAS storage is excellent for the final library because it centralizes capacity, snapshots, and resilience. Local SSD or NVMe storage is better for incomplete downloads, repairs, unpacking, Plex transcode cache, and Tdarr cache. These are write-heavy workloads. Running them across CIFS or NFS can work, but it adds latency and creates more chances for stale locks, permission mismatches, and slow repair or unpack stages.

• Best on NAS: final movies, final TV, completed library backups, exported configs, and long-term logs.
• Best on local disk: incomplete downloads, SAB repair/unpack work, Plex transcode cache, Tdarr transcode cache, temporary scripts, and test outputs.
• Depends: completed downloads. If Radarr/Sonarr import across the same filesystem, completed downloads can live near the library. If your NAS is slower, keep incomplete local and completed/imported final on NAS.

GPU Strategy at the Architecture Level

Plex and Tdarr can both use the GPU, but they should not be allowed to fight for it blindly. Plex is interactive. A user feels it immediately when a stream buffers. Tdarr is batch work. A transcode job can wait. The architecture should therefore reserve GPU capacity for Plex during peak viewing and let Tdarr run harder during off-peak windows.

Plex documentation notes that hardware-accelerated streaming depends on platform, hardware, driver support, and sometimes subscription features. NVIDIA systems also have hardware and driver-related encoding limits. That is why the operational design matters: verify the NVIDIA driver after kernel updates, verify nvidia-patch if you use it, and keep Tdarr worker counts lower during household viewing hours.

Library Design

A Plex library should represent how people actually browse. Do not create ten libraries just because folders exist. Also do not cram every category into one folder if you know the collection has different rules. Movies, TV, animated movies, stand-up comedy, and family content can be separate if that improves browsing, permissions, or automation. They should be separate because the user experience is better, not because the filesystem got messy.

• Movies: general films managed by Radarr.
• Animated Movies: a separate Radarr root if you want a dedicated Plex library or family-friendly destination.
• Comedy: a separate Radarr root when stand-up specials are browsed differently from normal movies.
• TV: series managed by Sonarr.
• Test Library: optional, useful for testing Tdarr flows before production.

Configuration Ownership

Every app should own its own configuration and database, and those folders should be backed up. The final media library is usually too large to back up in full for many homelabs, but the application configs are small and critical. If you lose a server but keep configs, compose files, service definitions, and media paths, rebuilding is realistic. If you lose configs, you may spend days re-creating indexers, tags, quality profiles, list settings, API integrations, and watched metadata.

Security Boundaries

Plex remote access is different from exposing every admin app. Plex is designed for remote playback. Sonarr, Radarr, Prowlarr, SABnzbd, Tdarr, and Nginx Proxy Manager are administrative tools. Treat them as private management surfaces. If you reverse proxy them, use HTTPS, strong authentication, access lists, VPN, or identity-aware controls. Do not put every media admin interface directly on the public internet just because it has a login page.

Beginner Build Checklist

• Choose one host or a clear two-host role split.
• Decide which folders live on NAS and which live on local SSD/NVMe.
• Create one consistent media path layout.
• Use a shared media group and cooperative permissions.
• Install Plex, Sonarr, Radarr, Prowlarr, SABnzbd, and Tdarr with persistent config directories.
• Connect Prowlarr to Sonarr and Radarr.
• Connect Sonarr/Radarr to SABnzbd categories.
• Connect Plex libraries to final media folders.
• Point Tdarr at final media folders only.
• Back up every application config before enabling heavy automation.

Technical Validation Checklist

• A completed TV download imports without remote path mapping confusion.
• A completed movie download imports into the intended Radarr root folder.
• Plex can read imported files without permission fixes.
• Tdarr can read, transcode, validate, and replace files without permission fixes.
• Radarr and Sonarr update MediaInfo after Tdarr replaces a file.
• Plex hardware transcoding works and shows GPU use during a real transcode.
• Tdarr worker limits protect Plex during peak hours.
• All config folders are included in a NAS-hosted backup set.
• Reverse proxy exposure is limited to apps that truly need remote access.

Beginner Walk-Through: What Happens When You Add a Movie

Imagine you add a movie to Radarr. Radarr does not download the movie itself. It checks indexers that came from Prowlarr, chooses a release based on your quality profile and custom formats, and sends the job to SABnzbd. SABnzbd downloads into a temporary area. When the job is complete, Radarr imports the file into the final movie folder. Plex sees the final file and adds it to the library. Later, Tdarr checks whether the file matches your codec, audio, subtitle, and size policy. If it does not, Tdarr creates a new optimized file, validates it, replaces the original, refreshes Plex, and tells Radarr to rescan.

That chain is why the architecture matters. If SAB writes directly into the movie library, Radarr loses control. If Tdarr processes incomplete files, it can transcode something still being unpacked. If Plex scans before the file is stable, users may see broken items. If Radarr never rescans after Tdarr replaces the file, Radarr makes future upgrade decisions using stale file details.

Technical Design Decisions to Document

• Which host runs Plex and whether it has the primary GPU.
• Which host runs Tdarr Server and which hosts run Tdarr Nodes.
• Which storage paths are local and which are NAS mounted.
• Which app owns each root folder.
• Which ports are LAN-only and which are behind a proxy.
• Which files are included in backups and where those backups live.
• Which GPU worker limits apply during peak and off-peak hours.

A simple diagram or README file in your backup folder is enough. The important part is that future-you can rebuild the stack without reverse-engineering every decision from memory.

Series Navigation

This article is part of the Plex, Arr, and Tdarr homelab media automation series. Links to later articles become live as each scheduled post publishes. The final wrap-up ties the complete build together.

• Plex Homelab Architecture: Storage, GPU Transcoding, and Library Design
• Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache
• Prowlarr Setup Guide: Clean Indexer Management for Sonarr and Radarr
• Sonarr Homelab Setup Guide: Install, Update, Optimize, and Connect to Tdarr
• Radarr Homelab Setup Guide: Install, Update, Optimize, Lists, and Tdarr Integration
• SABnzbd Performance Tuning for a Homelab Media Server
• Custom Formats and Quality Profiles Explained for Radarr and Sonarr
• Radarr Import Lists That Do Not Fill Your Library With Junk
• Plex + Tdarr GPU Strategy: Sharing NVIDIA GPUs Without Hurting Playback
• Reverse Proxy for Media Apps: Nginx Proxy Manager, SSL, Access Lists, and Security
• Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd
• Monitoring and Health Checks for a Plex and Arr Homelab
• The Complete Plex, Arr, and Tdarr Homelab Media Automation Series

Related foundation: Building a Production-Grade Tdarr GPU Transcoding Stack for a Homelab.

References

• Plex hardware-accelerated streaming
• Plex library settings
• Servarr Docker Guide
• Production-grade Tdarr GPU transcoding stack