How to Self-Host a Media Server with Plex or Jellyfin

Why this matters

Streaming services keep raising prices and removing content. A self-hosted media server gives you one library, on your hardware, accessible from your TV, phone, and laptop — and it works when the internet is down.

The choice between Plex and Jellyfin is the first decision, and it’s not obvious.

What I tested on

• OS: Debian 13 (trixie)
• Plex: 1.41.x
• Jellyfin: 10.9.x
• Hardware: Intel N100 mini PC with QuickSync
• Media: ~3 TB, mixed 1080p and 4K
• Duration: Plex for 3 years, Jellyfin for 6 months in parallel

⚠️ Sharing copyrighted material is illegal in most jurisdictions. This guide is for media you own or have the right to access.

Plex vs Jellyfin in one paragraph

Plex is polished, has a paid remote streaming tier, and Just Works for non-technical family members. Jellyfin is fully open source, completely free, and requires more tinkering but respects your privacy completely.

Step 1: Install Jellyfin with Docker

services:
  jellyfin:
    image: jellyfin/jellyfin:10.9
    container_name: jellyfin
    restart: unless-stopped
    volumes:
      - ./jellyfin/config:/config
      - ./jellyfin/cache:/cache
      - /media:/media:ro
    devices:
      - /dev/dri:/dev/dri
    environment:
      TZ: Europe/London

/dev/dri is the hardware transcoding device. Without it, 4K transcoding will melt your CPU.

Step 2: Add your library

1. Open the web UI (port 8096)
2. Add a media library, point it at /media
3. Set the metadata language
4. Wait for the scan — this is the slow part

Plex is similar, but it asks for a login and offers to download metadata from the internet during setup.

Step 3: Hardware transcoding

If you have an Intel GPU, pass /dev/dri and enable VAAPI in settings. Test with a 4K file played on a device that can’t direct-play it — if the CPU spikes to 100%, transcoding isn’t using the GPU.

For NVIDIA, use the nvidia-container-runtime and pass the GPU explicitly.

Step 4: Remote access

Plex: set up port forwarding (32400) and sign in. It’s largely automatic.

Jellyfin: put it behind a reverse proxy with a domain, or use a VPN. There’s no built-in relay.

Storage layout that survives a disk dying

Media libraries grow until they meet a disk limit, and the decision you make then is the one that hurts later.

Keep three things separate: media, metadata, and config. Media is replaceable-ish, metadata is years of watched history and artwork, config is the compose file plus database. Only the last two need to be in your backup — a 3 TB library in restic is a bad use of an offsite bucket, and this is the split I use in the backup guide.

For the library itself, RAID is not backup. A mirror protects you from one disk dying, not from deleting the wrong folder or from a filesystem going bad. If you want both, put the library on a mirror and keep the metadata and config on a nightly snapshot.

Practical shape: one SSD for the OS and containers, one large disk or mirror for media, and a cheap external disk that gets a copy of the metadata and the irreplaceable files — home videos, photos, documents. Everything else can be re-acquired, painfully, which is a different risk from losing it forever.

If you already run Nextcloud for documents, this is the same split; the Nextcloud and NAS walkthrough covers the ZFS side of it.

Transcoding settings that actually matter

Most home labs never transcode, and the ones that do usually have it configured badly. Three settings decide the outcome.

Direct play first. If the client can play the file as-is, no CPU or GPU is involved. The reason a 4K remux stutters on a TV is usually an audio track or subtitle format the client cannot handle, not the video codec. Fixing that is cheaper than buying hardware.

Hardware path, not software. With Intel QuickSync, pass /dev/dri and confirm in the dashboard that the GPU is being used — a CPU pinned at 100% during playback means it is not. Software transcoding a 4K stream on an N100 will work and will also make every other service on that box slow.

One transcode per stream, not per user. Set a concurrent limit. Two 4K transcodes on a mini PC is the difference between “fine” and “why is Vaultwarden timing out”, which is exactly the failure mode described in the monitoring guide.

The honest recommendation: buy for direct play, treat transcoding as a fallback, and test with the worst file you own rather than the demo clip.

Pros and cons

Plex — Pros:

• Easiest setup and best client apps (including smart TVs)
• Transcoding and remote access largely automatic
• Friends and family can use it without you explaining anything

Plex — Cons:

• Requires an account; they’ve locked features behind a paid tier
• Closed source, and the company can change the rules

Jellyfin — Pros:

• Fully open source and free
• No account, no telemetry, no paid tier
• Complete control over your data

Jellyfin — Cons:

• Client apps are rougher, especially on TV
• Remote access is DIY
• Setup takes more effort

Best for / Skip if

Plex is best for: sharing with non-technical family, or if you want it to work without you touching it.

Jellyfin is best for: privacy-focused self-hosters who don’t mind the extra work and don’t share with non-tech users.

Skip both if: you only watch on one device and don’t have a large library. Kodi pointing at a network share is simpler.

Alternatives

• Emby — Plex-like but paid, sits between the two
• Kodi — plays files, no server, no transcoding
• Just files — a network share is sometimes all you need

Verdict

For a self-hoster who values control, Jellyfin wins — it’s free, open, and respects your privacy. But if sharing with non-technical family is the goal, Plex’s polish and automatic remote access make it the easier choice. I run Jellyfin for myself and keep a Plex server for relatives.

References

• Jellyfin documentation — installation, hardware acceleration, and remote access
• Plex support articles — server setup and library management