Homelab Series #3 — Jellyfin or Plex: Picking Your First Service

Hypervisor picked, network segmented, remote access working from a hotel room in Kyoto — the question that had been sitting there since day one was next: what do you actually host first? The classic answer, almost a homelab cliché, is a media server. Except you have to pick between Jellyfin and Plex, and the two camps argue about it like Vim versus Emacs.

I ran both side by side on the same LXC for three weeks before deciding. Here's why I ended up uninstalling one of them.

The problem: two opposing philosophies

Plex and Jellyfin technically do the same thing — scan a library, pull metadata, transcode on the fly, stream to any device. But their architecture answers two different questions.

Plex routes every connection, even local ones, through its central servers for authentication. An account is mandatory, telemetry is on by default, and some advanced features (unlimited hardware transcoding, mobile sync) sit behind Plex Pass, a subscription around $5/month or a lifetime purchase around $120.

Jellyfin is a fork of the now-defunct Emby, fully open source, no central account, no telemetry, no paid tier. Whatever the software can do, it does for free — the tradeoff is you configure yourself what Plex guesses on your behalf.

What Plex genuinely does better

Let's be honest, because that's the rule around here: Plex has real strengths, and pretending otherwise would be dishonest.

• Client apps — Apple TV, tvOS, Android TV, Roku, Chromecast — are more polished and stable than their Jellyfin counterparts, which are improving fast but can still lag a step behind on cheaper TV boxes.
• Hardware transcoding is a three-click setup with Plex Pass. On Jellyfin, you pass `/dev/dri` into the container yourself, pick the right VAAPI or Quick Sync driver, and debug a stream that silently falls back to software if the config is incomplete.
• Remote access is built in natively, no network setup required — Plex handles the relay if NAT traversal fails.
• Metadata scraping is more accurate on obscure titles, thanks to a proprietary database that's more complete than the open sources Jellyfin relies on.

What tipped it toward Jellyfin

Plex's biggest selling point — zero-config remote access — stopped mattering to me. The previous post in this series set up Tailscale on the Services VLAN: anything running there, Jellyfin included, is already reachable from anywhere with no open port and no dependency on a third-party relay. Plex's number-one advantage disappears the moment you've already solved remote access upstream.

That left the account question. A homelab, to me, is the opposite of a service someone else manages: if Plex changes its terms tomorrow, shuts down an auth server, or moves a feature behind a paywall, my local library depends on a decision made somewhere else entirely. With Jellyfin, the worst case is the project dies — the software keeps running exactly as before, asking nothing of anyone.

Telemetry mattered too. Plex knows what I'm watching and when, even locally, because authentication routes through its servers. Not dramatic on its own, but it contradicts the entire point of self-hosting.

Full config — Jellyfin in an LXC with Quick Sync

Deployed as a Debian LXC on Proxmox, with the integrated Intel GPU passed through for hardware transcoding (Quick Sync). Video storage stays on the Unifi NAS, mounted over NFS.

On the Proxmox host, pass the render devices into the container config (/etc/pve/lxc/<ID>.conf):

lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir

Inside the container, mount the NAS and deploy with Docker Compose:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    network_mode: host
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/jellyfin/cache:/cache
      - /mnt/nas/films:/media/films:ro
      - /mnt/nas/series:/media/series:ro
    devices:
      - /dev/dri:/dev/dri
    restart: unless-stopped

Once the container is up, enable hardware transcoding under Dashboard → Playback: check Hardware acceleration: Intel QuickSync (QSV) and select /dev/dri/renderD128 as the device. That's the one manual step that replaces what Plex Pass does automatically.

On the library side, Jellyfin scans /media/films and /media/series in the background and pulls metadata from TheMovieDB — free, no paid API key, but a bit less thorough than Plex's database on rarer titles.

Result

Three weeks of running Plex and Jellyfin side by side later, the Jellyfin LXC's CPU stays under 15% during a 4K-to-1080p transcode thanks to Quick Sync — without it, pure software transcoding pushed it to 90%. Memory sits around 400MB idle, well within budget on the busiest node of my cluster.

In actual use, the Jellyfin Apple TV app took longer to settle than I'd have liked — two updates were needed before playback stopped stuttering on some HEVC files. It's not perfect, and if your top priority is zero fuss across every TV box in the living room, Plex is objectively the more comfortable choice.

The rest of this series

1. Which hypervisor to choose?
2. Network and remote access without opening a port
3. Jellyfin or Plex: picking your first service — you are here
4. Monitoring with Netdata & Uptime Kuma — coming up

What you can do this weekend

If your network and remote access are already sorted, install Jellyfin in a container and give it two weeks before judging — the first impression on hardware transcoding is usually a missing config, not a disappointing piece of software. If you're sharing the library with people who aren't technical, try the free tier of Plex first — the polish of the apps can be worth the small loss of control. Either way, mount your library read-only (:ro) — a scan bug should never be able to touch the source files.