Host your own Jellyfin media server: streaming the films and music you already own

There is a specific kind of annoyance that turns people into self-hosters. You go to watch something you watched last year, and it is gone — moved to a service you do not subscribe to, or simply removed. Meanwhile there is a shelf of discs, a folder of ripped files, and a music collection that predates streaming, all of it unwatchable on the television because it is on a laptop in another room.

Jellyfin solves that. It is a free, genuinely open-source media server — no paid tier, no account with a vendor, no phone-home — with apps for Android, iOS, Android TV, Fire TV, Roku, the web, Kodi and more. Point it at a folder of films, series and music and it produces the interface you expect: artwork, metadata, resume-where-you-left-off, per-user profiles.

Why people run it in the cloud rather than at home

The default advice is to run Jellyfin on a machine in your house. That is a good answer when your home connection has real upload bandwidth and you never need it from anywhere else. It is a worse answer than it sounds when:

• Your upload speed is the bottleneck. Home broadband is asymmetric. Playing a high-bitrate file to yourself in a hotel means pushing it up a link that was never sold to you as an upload link.
• You do not want to open ports on your home router, which is a sound instinct.
• The machine is a laptop, a NAS running twelve other things, or a Pi that stalls whenever indexing runs.
• You want it to keep working while you are away, which is exactly when the power cut happens.

A server in a data centre has symmetric bandwidth, a static address, and no relationship to whether the router got unplugged.

The part most guides skip

Streaming is not a normal web workload, and a normal reverse proxy configuration will make Jellyfin look broken in ways that are hard to diagnose. A default nginx buffers responses, caps request bodies at 1 MB, and times out after a minute — which produces stuttering playback, failed uploads of subtitle and artwork files, and a progress indicator that never updates because the WebSocket upgrade headers are missing.

So the checklist for a working deployment is longer than "run the container": a proxy configured for long-lived streaming connections, a certificate that keeps that configuration through every renewal, a library on storage that outlives the server, and a machine with enough memory that scanning ten thousand files does not take the service down.

How we deploy it

Jellyfin is in the Platforms catalogue, under Streaming. Pick it, pick a server with a block volume, name a domain, and:

• No database prerequisite. Jellyfin does not need one, so we do not create one. Platforms that do need a database — Immich, PhotoPrism, Nextcloud — bring their own; Jellyfin is simply deployed without.
• The proxy is configured for media, not for web pages: no body-size cap, buffering off, hour-long read and send timeouts, WebSocket upgrade headers, and no temporary file spooling.
• The library sits on block storage at a uniform path, so you can rebuild or replace the server without touching the films. Removing the platform keeps the library.
• A capacity check runs before anything is installed. The RAM floor is printed on the platform card before you click, and if the target machine cannot carry it the install is refused with the reason rather than deployed into a container that will be OOM-killed mid-episode.
• The certificate is issued and renewed automatically, preserving the streaming vhost rather than replacing it.

The honest limitation: transcoding

This is the one thing to understand before you order, and we would rather say it plainly.

When a client can play a file as it is — the right container, codec, resolution and bitrate — the server just sends bytes, which costs almost nothing. That is direct play, and it is what happens most of the time on modern apps. When a client cannot, Jellyfin re-encodes the file on the fly, and that is expensive. On a machine with a GPU it is offloaded to hardware. On a general-purpose cloud VM it falls to the CPU.

We do not currently pass a GPU through to the container — there is no /dev/dri passthrough — so heavy 4K transcoding is CPU-bound. In practice that means:

• Direct play of your library on a phone, tablet, TV app or browser: fine.
• One 1080p transcode on a machine with a few cores: usually fine.
• Several simultaneous 4K HDR transcodes: not what this is for.

The practical fix is the same one home users apply: store your library in formats your devices can play directly, and the transcoder is rarely asked to do anything.

Bandwidth, and one legal note

Streaming moves real volumes of data out of the server, and cloud providers meter egress. For a household it is nearly always inconsequential; if you are planning to serve a large group, check the transfer allowance on the server size you are ordering before you assume it is free.

And the obvious point, stated once: a media server is for media you are entitled to have. Ripping your own discs, files you bought, home video, and freely licensed material are what this is for.

The short version

A media server is one of the few pieces of self-hosted software that is straightforwardly better than the commercial alternative for the specific job of playing things you own. The reason more people do not run one is the hour of proxy, certificate and storage configuration between the container and something the family can use.

Create an account, order a media server, and deploy Jellyfin from the catalogue. Nothing in your library will ever leave the catalogue, because the catalogue is yours.