My Media

Posted on Jan 25, 2026

At some point every homelab reaches the same inevitable conclusion:

“I have terabytes of storage and a GPU. I should absolutely host my own media.”

This is how it starts and oh so innocently. Next thing you know you’re arguing with subtitles and learning what “transcode” really means (spoiler: it means “your CPU is now a space heater”).

So, here’s how I’m approaching a self-hosted media solution for music, TV shows, and movies, running on the Proxmox box.

Goals (so I don’t build a monster)

I want:

  • A single place to keep media organised
  • Streaming to phones, tablets, and the living room without ceremony
  • Hardware-assisted transcoding where possible (because I like my fans quiet)
  • Remote access that doesn’t involve opening half my network to the public internet
  • Something I can maintain without it becoming my full-time job

Step one: storage layout that won’t punish future-me

Before you install anything, decide where media lives and stick to it.

My basic structure is:

  • /media/music
  • /media/tv
  • /media/movies

If you’re on ZFS, this is even nicer as separate datasets, so you can tweak settings and permissions cleanly. Media is mostly large sequential reads, so you don’t need to optimise for tiny random IO.

The most important rule: don’t scatter media across three different mounts “just for now”. “Just for now” is how you end up with a folder called NEW_NEW_FINAL_MEDIA in 18 months.

Step two: pick the “watch stuff” brain

There are three usual suspects:

  • Jellyfin: open source, self-hosted, no “please sign in to our cloud” vibes
  • Plex: polished, very good clients, but carries more platform energy than I want
  • Emby: similar territory, different flavour

For my purposes, Jellyfin is the default choice. It does what I want, it’s local-first, and it feels like it was made for people who enjoy running their own services rather than being monetised as a lifestyle.

Step three: music deserves its own treatment

Jellyfin can do music, but dedicated music servers can be nicer depending on your collection and habits.

Two common routes:

  • Jellyfin for everything (simple, one library system)
  • Navidrome for music (lightweight, great for large music libraries, works with a bunch of clients)

I like the idea of keeping it simple unless I have a reason not to. If Jellyfin handles my music library well, that’s one less moving part. If it doesn’t, Navidrome is a tidy add-on.

Step four: where to run it in Proxmox

You’ve got a few options, and each has a different “how much do I enjoy pain” slider.

Option A: A dedicated VM (my usual preference)

  • Debian/Ubuntu VM called something like media01
  • Install Docker + Compose
  • Run Jellyfin (and anything else) as containers

Pros:

  • Clean separation from Proxmox
  • Easy to rebuild/restore
  • Docker makes upgrades predictable

Cons:

  • Slightly more overhead than an LXC

Option B: LXC container

  • Lightweight, fast, tidy

Pros:

  • Efficient
  • Feels very “homelabby”

Cons:

  • GPU passthrough can be fiddlier depending on hardware/drivers
  • You have to be a bit more careful with privileges and mounts

I prefer VMs because it just feels like it works better, since it actually is a fully virtualised machine. I’m not against containers I just don’t particularly get long with them.

Step five: transcoding, aka “please don’t melt my CPU”

Transcoding is what happens when a client can’t play the file you gave it, so the server converts it on the fly.

This is where my GTX 1080 becomes useful.

If I can get hardware transcoding working reliably (NVENC/NVDEC), I get:

  • smoother playback to low-power devices
  • less CPU load
  • less fan noise
  • fewer moments where I wonder why my server sounds like it’s trying to achieve lift-off

The real trick is to avoid unnecessary transcoding in the first place. If your main clients can direct-play (the file format is supported), life is calmer.

So:

  • prefer sensible codecs
  • keep originals where it makes sense
  • let the server transcode only when it has to

My earlier post mentioned possibly adding a Blu-ray drive for ripping. That’s still the most straightforward “I own this media and I want it on my server” path.

Once files exist, the job becomes:

  • name things consistently
  • keep them in the right folders
  • let Jellyfin scan and build the library metadata

I’m intentionally not building a complicated “acquisition pipeline” here. If your media is already yours and already on disk, you can get a long way with just good folder structure and a server that scans it.

Step seven: access, without turning it into a public service

I don’t want my media UI open to the entire internet. I want access when I’m away, but I want it to be boring and safe.

So the approach is:

  • Keep Jellyfin internal (LAN-only)
  • Use Teleport when I want to access it remotely
  • Use Site Magic if I’m linking multiple sites together

That way:

  • no port forwards
  • no “exposed admin panel” accidents
  • no waking up to logs full of random scanners trying their luck

If you do want external access later, the minimum bar is:

  • HTTPS
  • strong auth
  • ideally an additional layer like SSO or a reverse proxy with access controls

But honestly? Teleport is the cleanest solution for “it’s my server and I want in”.

Step eight: backups, because losing a library is a special kind of grief

Media itself is big, so you have to be realistic.

My rough priority order:

  1. Back up the metadata/config (Jellyfin config, library database, watched status)
  2. Back up irreplaceable media (home videos, personal archives, ripped stuff you can’t easily recreate)
  3. If you’ve got the storage and patience, back up everything

Even just backing up configuration means if the VM explodes, you can rebuild it and your libraries don’t come back as an empty void.

What this looks like when it’s done

The “finished” version of this stack is:

  • Storage organised on the server in a predictable layout
  • A media VM with Jellyfin running and scanning libraries
  • Optional music service if I feel like it
  • Hardware transcoding enabled where possible
  • Remote access via Teleport, not public exposure
  • Backups for the parts that matter

And then, finally, the true endgame:

Sitting on the couch, selecting a film, and experiencing the rarest homelab sensation of all: everything just working.

In Part V I’ll probably cover the actual deployment details: VM sizing, mounts, the container setup, and how I’m handling permissions without turning /media into a free-for-all.