Jellyfin is a media server with no account requirement, no licence and nothing to upsell you. It indexes the video and music you already have, fetches artwork and metadata, and streams to a browser, a phone or a television.

Getting it running takes minutes. The decisions that are awkward to undo are all made in that first ten minutes, which is a good reason to spend them deliberately.

Mount the media read-only

The server needs to read your files, but it does not need to write to them. An accidental delete in a media library is unlikely to be recoverable from the backup you never made.

Mount the media directories read-only. It costs nothing and rules out an entire category of accident, and the only function you lose is letting the server reorganise your files, which most people do not want anyway.

The server's own configuration and cache directories are a separate mount and do need to be writable. Keep them apart from the media, on storage you are willing to have written to constantly.

Decide the paths before you start, because they stick

The paths you mount become the library paths inside the application. Changing them later is not a simple edit to a compose file. The libraries have to be removed and re-added, which loses watch state and forces the metadata scan to run again from scratch.

Think for a few minutes about where media will live in a year, not just where it happens to be today. If a bigger disk is coming, mount the path it will eventually have and move the files, rather than mounting where they are now.

A structure the scanner understands saves a great deal of manual correction later. Films in one directory with the year in the folder name, television separated by series and season. Jellyfin's matching is good and it is not telepathic.

Hardware transcoding fails quietly

Transcoding is what happens when the client cannot play the file as it is and the server has to convert it on the fly. Done on the processor, it is slow and can chew an entire machine for one stream. Done on a GPU or an integrated video engine, it is close to free.

The problem is how it fails. If the render device is not visible inside the container, the server does not warn you; it silently falls back to the processor. You discover this when a single stream makes the machine unusable.

The check is to look for the device from inside the container rather than from the host. If the directory is not there or is empty, the device or group configuration in the compose file is wrong. Seeing it on the host proves nothing about what the container can reach.

Direct play beats transcoding every time

The best transcoding setup is the one that never runs. If the client can play the file as it stands, the server is doing nothing but moving bytes, and a very modest machine can serve several streams at once.

Most transcoding is triggered by specific, avoidable problems: a container format a browser will not accept, an audio track the television cannot decode, or subtitles that have to be burned into the picture. Subtitles are the one that surprises people — an image-based subtitle track forces a full video transcode where a text-based one does not.

Before buying hardware for transcoding, find out what is actually triggering it. A single library in an awkward format is a common cause, and re-encoding it once is cheaper than a graphics card.

Remote access is a separate decision

Watching at home needs nothing beyond the local network. Watching elsewhere means exposing a media server to the internet. Treat that as the separate security problem it is.

A reverse proxy with a real certificate is the minimum. Strong passwords on every account, not just yours, and consider whether a private network between your devices is a better answer than a public address for something only your household uses.

Where this comes from

Composed from the project's own Docker documentation and hardware-acceleration guides together with several independent published setups, cross-checked against each other on 31 August 2026. Hardware transcoding details are specific to the graphics hardware involved and date quickly; check the current documentation for the chip you actually have.

Nothing here is about acquiring media. This is how to serve files you already have the right to, and that is the only use it is written for.

The metadata scan is heavy the first time. A large library on a slow disk will take hours and make the machine feel unwell while it does. That is expected, it happens once, and interrupting it only means starting again.