A Media Server VPS for Jellyfin, Plex, Icecast and AzuraCast: Streams, Sizing and Setup

A media server VPS can run Jellyfin, Plex, an Icecast radio station or an Owncast live stream, and the network is rarely what stops you: a 1 Gb/s port divided by a 10 Mbps film is 100 people watching at once. Two other things get in the way. There is no GPU, so you build the library for direct play instead of transcoding, and Plex counts every stream from a data centre as remote, which puts a paid pass in front of every video.

The gist:

• Jellyfin suits a rented server best: no outside accounts, and a per-user switch that blocks video transcoding.
• On a VPS, Plex's remote rule covers every video in every app (Infuse too, since September 2026), so budget for Plex Pass or a Remote Watch Pass.
• On paper, 1 Gb/s carries about 100 streams at 10 Mbps or 7,800 radio listeners at 128 kbps; 10 Gb/s, ten times that.
• Disk fills first: a two-hour 1080p film at 10 Mbps is about 9 GB.

Why not stream from home, or from a platform?

A home server streams over your upload, and Jellyfin's hardware selection guide asks for at least 20 Mbps of it for remote access. In a data centre the server gets the big pipe, and your home IP stays private. Cloudflare's free tunnel is no shortcut: its terms reserve video and large files on the CDN for paid services or Enterprise plans. Platforms have rules too; Twitch has capped Highlights and Uploads at 100 hours per channel since April 2025. In the selfh.st 2025 survey, 2,487 of 4,081 self-hosters ran Jellyfin and 1,219 ran Plex.

Jellyfin, Plex, Icecast, AzuraCast, Owncast: who does what

A media server streams files on demand; a streaming server copies one live signal to everyone at once.

Between the first two, pick Jellyfin unless your viewers already pay for Plex, because of a rule Plex brought in during 2025 and has widened since.

Plex on a VPS: every stream counts as remote

Since 29 April 2025, remote playback of personal video in Plex needs a pass: the server owner's Plex Pass, which covers everyone they share with, or a Plex Pass or the streaming-only Remote Watch Pass on the viewer's account. Music in Plexamp and photos are exempt. Plex enforces it app by app: its support page lists the phone apps, the web app, Roku (from late November 2025), smart TVs, consoles and the desktop apps, and Plex says every app will follow. Third-party players were one of the last ways round it until September 2026: on the 21st, Infuse's developer Firecore passed on a note from Plex saying that from later that week, remote playback in apps like Infuse needs a Remote Watch Pass or Plex Pass as well.

The definition is what bites. Plex's remote playback requirements count playback as remote whenever the app can't reach the server on the same subnet of the same local network. Your server is in Amsterdam and your TV is in the living room, so every film is remote. Hardware transcoding needs Plex Pass and, per Plex, doesn't work in virtual machines anyway; Plex Relay caps streams at 2 Mbps, so open port 32400 instead. Plex's own requirements page adds that the server is licensed for personal use, is expected to run from home and may not work with every hosting company, so test it on your VPS before you move a library over. The apps are still the slickest; just budget for the pass from day one.

How many streams can a 1 Gb/s port handle?

Bitrate is the data a stream uses per second. Streams = port speed ÷ bitrate, so 1,000 Mbps fits a 10 Mbps film 100 times, and disk per hour in GB = Mbps × 0.45. Video bitrates come from the reference files in Plex's CPU guide and Netflix's recommended connection speeds (15 Mbps for 4K, 5 Mbps for 1080p).

Those are ceilings. TCP adds overhead (Icecast's load test allowed 10% for it) and audiences arrive in bursts, so we plan on about 80% of the table, a rule of thumb rather than a published figure. Flat out, 1 Gb/s moves about 10.8 TB a day, roughly 324 TB in 30 days, and traffic on our plans is unmetered. The usual bottleneck is the viewer's own connection or a long, jittery path, so host near your audience.

Transcoding without a GPU: build the library for direct play

Transcoding means re-encoding video on the fly for a player that can't handle the original. Jellyfin ranks playback from cheap to expensive: Direct Play (file sent untouched, almost no load), Remux (container changes), Direct Stream (audio converted) and Transcode (video re-encoded, worst of all with burned-in subtitles).

Plex's CPU sizing guide puts one software transcode of 1080p H.264 at about 2,000 PassMark points and 4K HDR squeezed to 1080p at about 17,000, per viewer; it dates from 2019, so read it as orders of magnitude. Jellyfin's guide says software tone-mapping of 4K60 Dolby Vision needs a Ryzen 9 5950X just to keep up. We wouldn't transcode 4K HDR on any VPS, ours included.

So encode once at home and direct play forever. Per Jellyfin's codec support table, H.264 8-bit video with AAC audio in MP4 is what nearly every client plays as it is. This FFmpeg command converts one film that way (CRF 17 to 28 is FFmpeg's sane range; adding 6 roughly halves the bitrate).

# as the normal user, on your own computer
ffmpeg -i INPUT.mkv -map 0:v:0 -map 0:a:0 -c:v libx264 -preset slow -crf 20 -pix_fmt yuv420p -c:a aac -b:a 192k -ac 2 -movflags +faststart OUTPUT.mp4

FFmpeg shows a progress line with a speed= value; when the prompt returns, OUTPUT.mp4 is ready. Upload and play it: Jellyfin's dashboard should say Direct Play. If it says Transcode, suspect image subtitles (PGS, VobSub), which force a burn-in; use .srt files beside the video. Will an occasional 1080p transcode keep up on your plan? Run the command on the server (after apt install ffmpeg); a speed= below 1x is slower than real time.

A 1 or 10 Gb/s port, but no GPU

RS Computers runs KVM servers in Amsterdam, Prishtina and Dublin, so you can put a media server VPS near your audience. The plans page has the same plans and prices in all three cities. Every plan has NVMe storage, its own IPv4 and IPv6 addresses and unmetered traffic, on a 1 Gb/s port for VPS plans and 10 Gb/s for VDS plans. A free weekly backup restores from the client area, where you also upgrade the plan as the library grows. You get the usual Linux distributions; Windows Server is offered on VPS Mini and all VDS plans, though nothing here needs it. Two limits shape the rest of this guide: the vCPUs are shared and there is no GPU, which is why it keeps coming back to direct play.

Sizing a media server VPS: disk first, then memory

Jellyfin's guide recommends 8 GB of RAM (4 GB may do on a headless Linux server) and about 100 GB of SSD for the system, its files and the transcode cache; Plex calls 4 GB typically more than sufficient. For scale: on our 8 vCPU test server, which has 16 GB of RAM, an idle Jellyfin 12.2 with a one-film library used about 350 MB. With transcoding off, we keep about 40 GB back and count the rest as library. A two-hour 1080p film is 9 GB at 10 Mbps, a 4K HDR one 45 GB.

The VPS plans sit below Jellyfin's 100 GB guideline, so treat them as audio and live-video machines.

Set up Jellyfin with HTTPS on Debian 13

Order VDS Small or larger with Debian 13 and log in as root over SSH; new servers accept the root password, and from a normal user sudo -i works too, since our Debian 13 template ships with sudo. Ubuntu 24.04 takes the same commands. Point DNS A and AAAA records for media.YOUR_DOMAIN at the server now.

Step 1: update, firewall, two checks

This block updates the system, installs tools, opens SSH and web ports, enables the firewall and prints two numbers.

# as root
apt update && apt full-upgrade -y
apt install -y curl gnupg ca-certificates ufw rsync
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 443/udp
ufw --force enable
df -h /tmp
grep -c sse4_1 /proc/cpuinfo

ufw replies Firewall is active and enabled on system startup, and df shows the size of /tmp, which Debian 13 often keeps in RAM. The last line must print a number above 0; 0 means the virtual CPU hides SSE4.1, which Jellyfin 10.11 and later require. On our plans it prints your vCPU count, since the vCPUs support x86-64-v3. Port 8096 stays closed on purpose.

Step 2: install Jellyfin

Jellyfin publishes an official install script with a checksum file; the last line runs the script only if the two match.

# as root
cd /root
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 && bash install-debuntu.sh

Expect install-debuntu.sh: OK, a summary showing Repository Release: trixie (noble on Ubuntu), an Enter prompt, then the service status. curl -s http://127.0.0.1:8096/health answers Healthy. You now run the latest Jellyfin 12 release (12.2 when we tested; 12.0 came out in early September 2026). If you see Insufficient free space for /tmp, your RAM-backed /tmp is smaller than the 2 GiB the script wants: run systemctl mask tmp.mount, reboot and repeat the block.

Step 3: folders, then your files

Next, three library folders the jellyfin service user can read:

# as root
mkdir -p /srv/media/movies /srv/media/shows /srv/media/music
chmod -R u=rwX,go=rX /srv/media

ls -l /srv/media lists three drwxr-xr-x folders. Upload only what you own or are licensed to share; from Linux or macOS, this copies a folder of films and resumes after a dropped connection:

# as the normal user, on your own computer
rsync -avP YOUR_FILMS_FOLDER/ root@SERVER_IP:/srv/media/movies/

It ends with a total size is line; on Windows, WinSCP or FileZilla do the same over SFTP. Rerun the chmod after uploads; an error adding the media path in Jellyfin means permissions.

Step 4: the setup wizard, through an SSH tunnel

Port 8096 stays off the internet, so this forwards it to your own computer over SSH.

# as the normal user, on your own computer
ssh -L 8096:127.0.0.1:8096 root@SERVER_IP

You get an ordinary SSH session (Windows PowerShell works too); leave it open and browse to http://127.0.0.1:8096 for the welcome screen. Create the admin account with a long password, add the folders under /srv/media as libraries and leave "Allow remote connections to this server" ticked, because viewers who come in through Caddy count as remote. Current Jellyfin has no automatic port mapping, so there is nothing else to switch off.

Step 5: HTTPS with Caddy

A reverse proxy answers on ports 80 and 443 and passes each request to an app on a local port. Jellyfin's docs recommend Caddy, which handles Let's Encrypt certificates by itself (our reverse proxy guide compares the alternatives). This block adds Caddy's official repository, installs it and writes a one-site config; replace media.YOUR_DOMAIN first.

# as root
apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
chmod o+r /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy
cat > /etc/caddy/Caddyfile <<'EOF'
media.YOUR_DOMAIN {
    reverse_proxy 127.0.0.1:8096
}
EOF
systemctl reload caddy

After a minute, curl -I https://media.YOUR_DOMAIN on the server should print a first line starting with HTTP/2 (HTTP/2 302 is fine: Jellyfin redirects to its web app). If you see a certificate error, journalctl -u caddy --no-pager | less +G nearly always shows DNS not yet pointing here or port 80 blocked.

Step 6: Known Proxies and one account per viewer

In Jellyfin, open Dashboard, then Networking, enter 127.0.0.1 under Known Proxies, save, and run systemctl restart jellyfin. Without it, Jellyfin sees every visitor as the proxy, which breaks its outside-access limits. Then create one non-admin account per viewer and untick video playback that requires transcoding (leave cheap audio transcoding on). If a viewer reports This client isn't compatible with the media and the server isn't sending a compatible media format, the switch is doing its job: re-encode that file with the FFmpeg line above.

Prefer Plex?

Plex signs its official repository with its own key; the block below adds both and installs Plex Media Server, which runs as its own plex user.

# as root
install -d -m 0755 /etc/apt/keyrings
curl -L https://downloads.plex.tv/plex-keys/PlexSign.v2.key | gpg --yes --dearmor -o /etc/apt/keyrings/plexmediaserver.v2.gpg
echo "deb [signed-by=/etc/apt/keyrings/plexmediaserver.v2.gpg] https://repo.plex.tv/deb/ public main" | tee /etc/apt/sources.list.d/plex.list
apt update
apt install -y plexmediaserver

systemctl status plexmediaserver --no-pager should say active (running). Plex lets you claim a server only from its own network, so tunnel in with ssh -L 8888:127.0.0.1:32400 root@SERVER_IP, open http://127.0.0.1:8888/web and sign in. Then run ufw allow 32400/tcp and enable Remote Access. Plex encrypts its own connections, so Caddy is optional; keep its DLNA and discovery ports closed, as Plex advises.

Hands-on: launch your own internet radio station

Radio is the friendliest job on this page. Icecast's own load test (2005, one 3 GHz Xeon, 2 GB of RAM) served about 14,000 listeners of a 12 kbps mono test stream (about 184 Mbps in total) at roughly 20% CPU and concluded the network card runs out first. A source client such as BUTT or Mixxx sends audio from a DJ's computer, Icecast copies it to every listener, and a mount point such as /stream is the stream's address.

Radio step 1: install Icecast

This opens port 8000 only to the computer you broadcast from and installs Debian's Icecast package, which Icecast's site calls the preferred route. Skipped Jellyfin? Run step 1's block first, because this one needs ufw.

# as root
ufw allow from YOUR_HOME_IP to any port 8000 proto tcp
apt install -y icecast2

Answer Yes to "Configure Icecast2?", then enter radio.YOUR_DOMAIN as hostname and three different long passwords (source, relay, admin). A line saying update-rc.d: error: no runlevel symlinks to modify appears on every fresh install and is harmless. Then curl -si http://127.0.0.1:8000/ | head -n 3 should show HTTP/1.0 200 OK and Server: Icecast 2.4.4; don't test with curl -I, because Icecast 2.4.4 answers those HEAD requests with 400 Bad Request. If you pressed Enter at the first question, the default No leaves the service off and every password set to hackme: run dpkg-reconfigure icecast2, answer Yes, then systemctl enable icecast2 and systemctl start icecast2, since reconfiguring sets the passwords but leaves the service off. Ubuntu 24.04 has the same package in universe. If your home IP changes often, or several DJs broadcast from different places, run WireGuard on the same server (our WireGuard guide for Debian 13 hands out addresses in 10.8.0.0/24), allow that range to port 8000 instead of one IP, and have the DJs connect to 10.8.0.1.

Radio step 2: raise the limits

Icecast allows 100 connections and 2 sources by default. In /etc/icecast2/icecast.xml (open it with nano), set <clients> to what your port carries (5000 suits 128 kbps on 1 Gb/s) and rename <admin-user>. There is a second limit: systemd caps the service at 1,024 open files, and on our test server Icecast turned listeners away at about 1,000 whatever <clients> said. A systemd override lifts the cap, and the restart applies it.

# as root
mkdir -p /etc/systemd/system/icecast2.service.d
printf '[Service]\nLimitNOFILE=16384\n' > /etc/systemd/system/icecast2.service.d/limits.conf
systemctl daemon-reload
systemctl restart icecast2

grep 'open files' /proc/$(pgrep -o icecast2)/limits should now show 16384 twice. With that in place, on our 8 vCPU test server, Icecast fed 2,000 simulated listeners of a 128 kbps MP3 stream (about 270 Mbps) with under a fifth of one vCPU and about 18 MB of RAM. If the log in /var/log/icecast2/ says server client limit reached, raise <clients>; accept() failed with error 24: Too many open files means the block above is missing.

Radio step 3: HTTPS for listeners

Browsers block http:// audio on https:// pages, so point radio.YOUR_DOMAIN at the server in DNS (skipped the Jellyfin part? run step 5's block with this name and port 8000 instead). Then add a radio site to the Caddyfile and reload Caddy:

# as root
cat >> /etc/caddy/Caddyfile <<'EOF'

radio.YOUR_DOMAIN {
    reverse_proxy 127.0.0.1:8000
}
EOF
systemctl reload caddy

curl -si https://radio.YOUR_DOMAIN/ | head -n 1 should answer HTTP/2 200 (again, not curl -I, which gets a 400 from Icecast). Debian's Icecast 2.4.4 logs every proxied listener as 127.0.0.1; version 2.5.0, released on 31 December 2025, reads X-Forwarded-For and fixes that. Xiph builds it for Debian 13, and the Icecast team ends support for 2.4.4 on 31 December 2026, so plan the move before then; 2.5 reads 2.4 configuration files.

Radio step 4: go on air

In BUTT or Mixxx, add an Icecast server: SERVER_IP, port 8000 (direct, not through Caddy), mount /stream, user source and your source password. Ogg Vorbis and Opus are officially supported; MP3 generally works too. Start broadcasting, and curl -s http://127.0.0.1:8000/status-json.xsl lists your mount under icestats, with the song title when your DJ app sends one; a small bot can turn that into now-playing posts in a Telegram channel or Discord server (our bot hosting guide covers keeping one running). Listeners tune in at https://radio.YOUR_DOMAIN/stream. If the log says attempted to login with invalid or missing password, fix the source password; Mountpoint /stream in use means another source got there first.

Music around the clock: AzuraCast

One DJ means silence at bedtime. AzuraCast adds AutoDJ, crossfades, DJ schedules and a web panel, with Icecast and Liquidsoap inside Docker. It needs at least 2 GB of RAM and 20 GB of disk (recommended: 4 CPUs, 4 GB and 40 GB for 5 to 10 hobby stations) on a full virtual machine such as KVM. It grabs ports 80, 443 and a station range including 8096, so give it its own server. On that server, AzuraCast's official installer does the work.

# as root
mkdir -p /var/azuracast
cd /var/azuracast
curl -fsSL https://raw.githubusercontent.com/AzuraCast/AzuraCast/main/docker.sh > docker.sh
chmod a+x docker.sh
./docker.sh install

The script installs Docker if needed and asks a few questions (defaults are fine); docker ps then lists a running azuracast container. Open http://SERVER_IP at once to create the super administrator, then enable Let's Encrypt in the settings. Docker-published ports bypass ufw, the trap our Docker on a VPS guide explains. Keep it updated: AzuraCast 0.23.8, released on 9 August 2026, fixed several security issues found by community researchers and added a system-wide switch that turns web hooks off for every station, worth using if you don't need them.

The licence question

A commercial recording usually carries two rights. The composition is licensed through authors' societies (Buma/Stemra in the Netherlands, IMRO in Ireland, ASCAP, BMI or SESAC in the US), the recording through Sena, PPI or, for US non-interactive webcasting, SoundExchange. EU Directive 2014/26/EU governs those societies, and licences follow your listeners, not only your server. AzuraCast's docs say it won't handle royalties for you. That's the general shape, not legal advice; ask the societies where your audience lives.

Live video with Owncast: viewers cost bandwidth, not CPU

Owncast takes RTMP from OBS on port 1935 and serves HLS video with chat; version 0.3.0 arrived on 3 September 2026. Per its requirements page, CPU depends on how many qualities you encode, bandwidth on how many people watch. A 1 Gb/s port supports roughly 200 viewers at 5,000 kbps (about 2,000 on 10 Gb/s), and a two-hour stream sends each viewer 4.5 GB. Passthrough relays your OBS stream unchanged at almost no CPU cost; one transcoded 30 fps quality takes roughly one CPU. Your upload should be 1.5 times the bitrate. Run it as its own user with --webserverip 127.0.0.1 behind Caddy (it serves on port 8080 and needs FFmpeg: since 0.3.0 the official quick installer fetches its own build, while a bare binary won't start until apt install ffmpeg has run), allow 1935/tcp in ufw for OBS, and change the admin password and stream key (both start as abc123).

Back up first, then upgrade

apt update && apt upgrade updates Jellyfin, Plex, Caddy and Icecast; AzuraCast uses ./docker.sh update-self, then ./docker.sh update. Read release notes before a Jellyfin major: 12.0 upgrades only from 10.10.7 or 10.11.x, can't be rolled back without a full restore, and wants third-party plugins removed first. It also switched off the legacy sign-in methods by default: on our 12.2 test server, the X-Emby-Token header and the api_key URL parameter got 401 Unauthorized, while the current Authorization header worked. If an old third-party app suddenly can't sign in, update it; setting EnableLegacyAuthorization to true in /etc/jellyfin/system.xml and restarting Jellyfin brings the old methods back until Jellyfin removes them for good. Whatever the version, back up first. In Jellyfin, Dashboard, Backups, Create Backup writes a zip to /var/lib/jellyfin/data/backups and needs 5 GB free. Plex has no button, so this block stops it, archives its data without the cache and starts it again.

# as root
mkdir -p /srv/backups
systemctl stop plexmediaserver
tar -czf /srv/backups/plex-$(date +%F).tar.gz --exclude='Cache' -C '/var/lib/plexmediaserver/Library/Application Support' 'Plex Media Server'
systemctl start plexmediaserver

ls -lh /srv/backups shows the new archive. Never run apt purge plexmediaserver: it deletes the library data. Our free weekly backup restores the whole server from the client area; treat it as a safety net and copy app backups off the server too (see our restic backup guide). For monitoring, point an HTTP check at https://media.YOUR_DOMAIN/health, which answers Healthy, as in our Uptime Kuma guide.

Security, accounts and the legal bits

Old software on an open port is the usual way in. On 1 September 2026 Plex asked every owner of Plex Media Server 1.43.2 or older to move to 1.43.3 or later for security fixes it had not yet described, and days later the Shadowserver Foundation still counted more than 36,000 unpatched servers online, BleepingComputer reported. A year earlier, after Plex fixed CVE-2025-34158 (CVSS 8.5) in version 1.42.1, Censys still counted more than 300,000 vulnerable internet-facing Plex servers in late August 2025, Help Net Security reported. Patch regularly, then:

• Keep 8096 closed and take Jellyfin plugins only from its stable repository.
• Jellyfin apps can put an access token in URLs (the ApiKey parameter). Caddy logs no requests unless you add a log directive, so protect any log you enable.
• Turn on two-factor login for your Plex account, as Plex urged after its September 2025 breach.
• Switch SSH to keys and turn off password logins: new servers accept the root password, and on a fresh test server we booted, the first password guess arrived less than six minutes after boot. Our Linux lab guide shows how.

Stream only what you own or are licensed to share; under the EU Digital Services Act, hosting providers must act on notices of illegal content. A family-only server falls under the GDPR's household exemption, but once you run one for a wider audience, such as a club's film library, a public radio station or an Owncast chat, its accounts and IP logs are personal data you answer for: the GDPR's security duty (Article 32) and 72-hour breach notice (Article 33) apply, and Kosovo's Law No. 06/L-082 sets the same 72 hours.

Frequently asked questions

Can you run Plex on a VPS?

Yes, from Plex's official repository, though Plex says it expects servers to run from home and may not work with every hosting company. Playback outside the server's local network counts as remote, so every video needs the owner's Plex Pass, or a Plex Pass or Remote Watch Pass on the viewer's account; since September 2026 that applies in third-party players such as Infuse too. Plan for direct play, since hardware transcoding isn't available in virtual machines.

Does Jellyfin need a GPU?

Not for direct play, which sends files untouched. Jellyfin advises a GPU if you rely on transcoding, because software transcoding of HEVC, 4K or HDR is very demanding. On a VPS, encode files as H.264 and AAC in MP4.

How many streams can a 1 Gbps connection handle?

Divide 1,000 Mbps by the bitrate: about 100 streams at 10 Mbps, 25 at 40 Mbps 4K, or roughly 7,800 at 128 kbps audio. Plan on about 80% of that. A 10 Gb/s port carries ten times as many.

How many listeners can Icecast handle?

Far more than its default limit of 100 connections, which you raise in icecast.xml, together with systemd's cap of 1,024 open files. On our 8 vCPU test server, 2,000 listeners of a 128 kbps stream used under a fifth of one vCPU, and Icecast's 2005 load test served about 14,000 listeners of a 12 kbps stream from one 3 GHz Xeon at roughly 20% CPU. At 128 kbps the port runs out long before the CPU does.

Do I need a licence to stream music on an internet radio station?

Almost always, unless you play your own music or music licensed for streaming. Commercial tracks usually need one licence for the composition and one for the recording, from collecting societies where your listeners are.

Should I put Jellyfin or Plex behind Cloudflare Tunnel?

Not for video. Cloudflare's terms allow video and large files through its CDN only via paid media services or Enterprise plans. A VPS with its own IP lets Caddy handle HTTPS directly.

Can RS Computers set up Jellyfin or the radio station for me?

Message us on Telegram or email info@rscomputers-ks.com with what you want to stream and to roughly how many people, and we'll suggest a plan and quote the setup.

Start with one film

Encode a single film with the FFmpeg line above before you order anything. Then pick your media server VPS on the VPS and VDS plans page (VDS Small for a family film library, VPS Micro for a radio station, VPS Mini for AzuraCast or Owncast), work through Jellyfin steps 1 to 6 and play that film on your TV. Direct Play on the dashboard means the rest of the library can follow. The radio can wait until tomorrow.

← All articles