.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Jellyfin on a VPS is the version of the home media server idea that survives contact with reality: your library streams to any device from a machine with a real internet connection, nothing at home has to stay powered on and there's no Plex-style account layer between you and your own files. The install takes fifteen minutes. This guide does it both ways, native Ubuntu packages and Docker Compose, then covers first-run setup and updates.
Version note before we start: Jellyfin's current stable branch is 10.11, the release that brought the redesigned web UI and moved the internals to a new database framework. Everything below assumes 10.11 on Ubuntu 24.04. If you're upgrading an older server instead of installing fresh, back up first; the 10.11 database migration is one-way (more on that in our Jellyfin backup and restore guide).
What the server needs
Jellyfin itself is light: 2 vCPU and 4 GB of RAM run a small library comfortably when clients direct-play. The real questions are storage and transcoding. Media libraries eat disk fast, so count your collection before picking a plan; a storage VPS makes sense once the library outgrows what NVMe plans offer per dollar. Transcoding is the CPU-hungry part: converting a 4K HEVC file on the fly will pin several cores without a GPU. The cheap workaround is avoiding transcodes entirely, keeping media in H.264/AAC formats that phones and TVs play natively. It works better than people expect.
Route 1: Install from the official repository
Jellyfin ships an official install script for Debian and Ubuntu that sets up the repo and installs the packages. Download it, verify the checksum and run it:
curl -s https://repo.jellyfin.org/install-debuntu.sh -O
curl -s https://repo.jellyfin.org/install-debuntu.sh.sha256sum -O
sha256sum -c install-debuntu.sh.sha256sum
sudo bash install-debuntu.shThe checksum step matters; you're about to run a script as root, so spend the ten seconds confirming it's the script Jellyfin published (the official Linux install docs even suggest reading it first with less). The script adds the apt repository, installs jellyfin, jellyfin-web and the project's own ffmpeg build, then starts the service.
Check it's alive:
systemctl status jellyfinActive and running means the web UI is waiting at http://YOUR_SERVER_IP:8096.
Updates from here on ride the normal package flow, which is the main argument for this route:
sudo apt update && sudo apt upgradeRoute 2: Docker Compose
The container route keeps Jellyfin's files in two folders you choose and makes major-version rollbacks as easy as changing a tag. Create a docker-compose.yml:
services:
jellyfin:
image: jellyfin/jellyfin
container_name: jellyfin
volumes:
- ./config:/config
- ./cache:/cache
- /srv/media:/media:ro
ports:
- "8096:8096"
restart: unless-stoppedThen bring it up:
docker compose up -dTwo deliberate choices in that file. The media mount is read-only (:ro) because Jellyfin never needs to write into your library, and a media server with write access to its own media is one bad plugin away from a bad day. And I publish port 8096 explicitly rather than using host networking; host mode gets recommended for DLNA discovery, but on a VPS there's no living room to discover, so the tighter option wins. Our take on the trade-offs is in the Jellyfin ports guide.
Updating the container version:
docker compose pull && docker compose up -dFirst-run setup
Open http://YOUR_SERVER_IP:8096 and the wizard walks you through language, the first user and libraries. Three decisions worth getting right on day one:
- The first account is your admin. There's no default login in Jellyfin; this wizard account is it, so give it a real password and store it somewhere. Recovering a lost admin password on a headless VPS is possible but annoying (we wrote up the password recovery methods separately).
- Point libraries at folders, not at the disk root. One library per type (Movies, Shows, Music) keeps metadata scanners sane. On the Docker route these paths are the container-side ones, /media/movies and so on.
- Skip remote access hardening for now but come back to it. The wizard's "allow remote connections" toggle just binds the server to public interfaces; it is not authentication hardening. Before you share the address with anyone, read through the remote access setup options, since a bare HTTP media server on a public IP collects login attempts within hours.
After the wizard, feed the library and let the first metadata scan finish before judging performance; the initial image and metadata fetch is the heaviest thing a fresh Jellyfin does.
Verify the install
Three quick checks. The dashboard (top-right gear icon » Dashboard) shows your version and active devices. Playing any file from the web UI confirms the media mount and permissions. And journalctl -u jellyfin --since "10 min ago" (or docker logs jellyfin) should be free of permission-denied lines; if it isn't, the jellyfin user can't read your media folder, which is the single most common fresh-install failure. chmod -R a+rX /srv/media is the blunt fix, tightening group ownership is the elegant one.
Ubuntu package or Docker, which one?
I run Jellyfin in Docker and I'd pick it again: version pinning, clean uninstalls and the config folder sits wherever I want it for backups. The native package route earns its place when the VPS does nothing else and you want systemd, apt and logs behaving like every other service you administer. Both are first-class citizens upstream. What I'd avoid is the third option nobody asks about, the distro's own repo, where Jellyfin versions go stale enough to miss security fixes.
On our side this whole page is optional: LumaDock ships Jellyfin as a 1-click template on the Jellyfin VPS plans, deployed with the OS so the wizard at port 8096 is literally the first thing you see. Bring the media, skip the apt keys :)
