Streaming Server VPS Plans (2026): Jellyfin/Plex Deployment, Bandwidth &.

Running streaming on a VPS comes down to two kinds of people:

Your home upload is too weak, so you can't watch your own collection from outside
You want a private media library that's "always available" (watchable on phone/tablet/TV box)

Jellyfin / Plex aren't hard to install. What's hard is:

Whether playback stutters
Whether traffic and bandwidth will blow through your plan
The moment you start transcoding, CPU pins at 100%
Cache/logs/transcode temp files fill up the disk

This article is written for "usable without wasting money."

Note: only discuss content you own the copyright/license for; don't use it for piracy distribution.

1) First, make the choice: do you want "direct play" or "transcoded playback"?

This is the watershed for the entire VPS selection.

1.1 Direct play (the preferred goal)

Direct play means: the client can directly decode your video format (H.264/H.265, audio codec, subtitle packaging, etc.).

Pros:

Barely uses CPU
Saves money (1-2 cores can run it)

Cons:

When client compatibility is poor, it forces you to transcode

1.2 Transcoded playback (the easiest place to trip up)

Transcoding means the server re-encodes the video in real time.

1080p transcoding: already heavy CPU pressure
4K transcoding: many VPSs simply collapse

If you clearly need transcoding, I suggest setting a more realistic goal:

Transcode to 1080p as much as possible
Avoid multiple simultaneous transcodes as much as possible
Pre-transcode when you can (unify sources to more universal codecs/containers)

2) How do you actually estimate bandwidth/traffic? (If you don't, you will definitely exceed)

You don't need decimal precision, but you need a sense of magnitude.

A very handy conversion:

每小时流量(GB) ≈ 码率(Mbps) * 0.45

Examples:

Playback bitrate	Approx. traffic per hour	Roughly how much for 100 hours
6 Mbps (1080p, on the frugal side)	2.7 GB/h	270 GB
10 Mbps (common 1080p)	4.5 GB/h	450 GB
25 Mbps (4K, on the frugal side)	11.3 GB/h	1.1 TB
50 Mbps (high-bitrate 4K)	22.5 GB/h	2.2 TB

So you'll find:

Watching 1080p, a few hundred GB a month is normal
With 4K, as long as you love watching, it easily reaches TBs

If you want to quickly verify on a VPS "how much traffic watching one video actually uses right now," the simplest brute-force way:

# 看网卡实时吞吐（Debian/Ubuntu）
sudo apt-get update && sudo apt-get install -y iftop
sudo iftop

Or look at total traffic over a period (tools differ slightly across distros, but the idea is: get the data first, then decide on upgrades).

3) How to choose VPS specs: don't look at CPU first, look at bandwidth and traffic

3.1 Bandwidth (port) determines "peak experience"

The simplest mental math:

1080p bitrate is commonly 6-12 Mbps
4K bitrate is commonly 20-60 Mbps

If you buy a 200Mbps port, in theory 1080p is enough, but evening-peak jitter/packet loss will make the experience painful.

3.2 Monthly traffic determines "whether you suddenly run dry at month-end"

Don't just look at the word "unmetered." Your final experience is still affected by:

Port speed limits
Evening-peak congestion
Fair use

3.3 CPU: direct play barely uses it, transcoding uses a lot

Direct play: 1-2 vCPU is often enough
Transcoding: start at 2-4 vCPU; don't expect much from 4K transcoding

4) Jellyfin vs Plex: how to choose (one line and you'll get it)

Jellyfin

Open source and free
Quick to get started, Docker one-shot
Features are sufficient, good for "I just want to watch it myself"

Plex

Mature ecosystem, broader client coverage
Some features (such as hardware transcoding) may involve Plex Pass

But remember one thing:

On most VPSs, you basically can't count on GPU/iGPU hardware transcoding

So no matter which one you use, prioritize "direct play + reasonable bitrate" — that's the cheapest and most stable path.

5) Deployment: don't throw 8096 directly onto the public internet (a safer Docker approach)

Of course you can expose 8096:8096, but that usually means:

The whole internet can scan you
Sooner or later you'll be hit by credential stuffing/brute force/probing

A more solid approach:

Jellyfin listens only on localhost (127.0.0.1)
Use a reverse proxy (Caddy/Nginx) for HTTPS

5.1 Jellyfin compose (recommended)

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    ports:
      - "127.0.0.1:8096:8096"
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /data/media:/media:ro

Start it:

docker compose up -d

If you're not familiar with Docker basics, read this first (avoid a pile of permission/directory-mapping pitfalls):

Docker deployment in practice (VPS containerization)

5.2 Reverse proxy (Caddy example)

Assume your domain is media.example.com:

media.example.com {
  reverse_proxy 127.0.0.1:8096
}

Nginx works too; the core is: only 443 comes in from outside, and the app isn't left naked.

6) Shore up security basics before external access

At minimum do two things:

SSH allows key-only login
Firewall opens only necessary ports

For the full process, see:

VPS security hardening guide (SSH + firewall + Fail2Ban)

7) The two most common failures: stuttering + disk blowup

7.1 Stuttering: don't blame Jellyfin/Plex first, look at the network first

Stuttering is most likely: packet loss, jitter, detours, evening peak.

You can troubleshoot following this route:

How to troubleshoot slow VPS network: from speed tests to packet-loss localization

7.2 Disk blowup: cache/logs/transcode temp files

Streaming services very easily generate:

Cache
Logs
Transcode temp files

If you find the disk suddenly full, first put out the fire following this:

What to do when the VPS disk is full: cleanup + expansion

8) Conclusion: how to do it with the fewest regrets

I'll give a "worry-free route":

First set the goal as direct play (avoid transcoding as much as possible)
First buy a monthly plan to test-run (test network, test traffic, test disk growth)
Once it runs smoothly, then consider big-disk plans/larger bandwidth/more stable nodes

Self-hosting streaming isn't hard to install.

What's hard is: whether you can use it stably, long-term.

Playback bitrate

Approx. traffic per hour

Roughly how much for 100 hours

6 Mbps (1080p, on the frugal side)

2.7 GB/h

270 GB

10 Mbps (common 1080p)

4.5 GB/h

450 GB

25 Mbps (4K, on the frugal side)

11.3 GB/h

1.1 TB

50 Mbps (high-bitrate 4K)

22.5 GB/h

2.2 TB

services: jellyfin: image: jellyfin/jellyfin:latest container_name: jellyfin restart: unless-stopped ports: - "127.0.0.1:8096:8096" volumes: - ./config:/config - ./cache:/cache - /data/media:/media:ro

1) First, make the choice: do you want "direct play" or "transcoded playback"?

1.1 Direct play (the preferred goal)

1.2 Transcoded playback (the easiest place to trip up)

2) How do you actually estimate bandwidth/traffic? (If you don't, you will definitely exceed)

3) How to choose VPS specs: don't look at CPU first, look at bandwidth and traffic

3.1 Bandwidth (port) determines "peak experience"

3.2 Monthly traffic determines "whether you suddenly run dry at month-end"

3.3 CPU: direct play barely uses it, transcoding uses a lot

4) Jellyfin vs Plex: how to choose (one line and you'll get it)

Jellyfin

Plex

5) Deployment: don't throw 8096 directly onto the public internet (a safer Docker approach)

5.1 Jellyfin compose (recommended)

5.2 Reverse proxy (Caddy example)

6) Shore up security basics before external access

7) The two most common failures: stuttering + disk blowup

7.1 Stuttering: don't blame Jellyfin/Plex first, look at the network first

7.2 Disk blowup: cache/logs/transcode temp files

8) Conclusion: how to do it with the fewest regrets

Loading…

1) First, make the choice: do you want "direct play" or "transcoded playback"?

1.1 Direct play (the preferred goal)

1.2 Transcoded playback (the easiest place to trip up)

2) How do you actually estimate bandwidth/traffic? (If you don't, you will definitely exceed)

3) How to choose VPS specs: don't look at CPU first, look at bandwidth and traffic

3.1 Bandwidth (port) determines "peak experience"

3.2 Monthly traffic determines "whether you suddenly run dry at month-end"

3.3 CPU: direct play barely uses it, transcoding uses a lot

4) Jellyfin vs Plex: how to choose (one line and you'll get it)

Jellyfin

Plex

5) Deployment: don't throw 8096 directly onto the public internet (a safer Docker approach)

5.1 Jellyfin compose (recommended)

5.2 Reverse proxy (Caddy example)

6) Shore up security basics before external access

7) The two most common failures: stuttering + disk blowup

7.1 Stuttering: don't blame Jellyfin/Plex first, look at the network first

7.2 Disk blowup: cache/logs/transcode temp files

8) Conclusion: how to do it with the fewest regrets