plex vps
Media servers and transcoding
Hardware encoding, terabytes of library, one bill.
What we would deploy
€86.80/mo
€124−30% annual
A media library is a storage problem with an occasional compute spike. Two machines solve it better than one: VAULT for the library on ZFS, and a FUSION instance with NVENC when you need to transcode a back catalogue in an afternoon. Connect them over a private VLAN and the traffic between them is free and unmetered.
Why this configuration
VAULT holds the library at a price per terabyte that makes sense, and its ZFS snapshots protect against a bad rename. Add the GPU only when you need it and destroy it when the job finishes.
What we would deploy
Sizing
Split the two resources. Library sizing is a VAULT question: pool size plus 20% headroom, ARC for metadata. Transcoding is a FUSION question. One RTX 4000 Ada handles a dozen or so simultaneous 1080p H.264 transcodes, but only three or four 4K HEVC streams with tone mapping, because tone mapping runs on CUDA cores rather than the encoder block. Choose L40S for AV1 output at scale. Keep 4 CPU cores per GPU for demuxing, subtitles and remuxing.
NVENC sessions, and what still runs on the CPU
Consumer cards historically capped concurrent NVENC sessions in the driver; professional cards including RTX 4000 Ada and L40S carry no such limit, so concurrency is bounded by encoder throughput instead. That matters less than what NVENC does not do. Decode uses NVDEC, a separate block. Tone mapping HDR to SDR runs on CUDA cores. Subtitle rendering, audio transcoding and container remuxing all run on the CPU. A 4K HEVC HDR stream downconverted to 1080p SDR therefore touches all four paths, which is why the per-card figure collapses from a dozen streams to a handful.
Two machines, one private VLAN
Storage and GPU want different hardware, so run them as different servers. VAULT holds the library on ZFS with NVMe cache; FUSION holds the card and stays otherwise small. Join them on a private VLAN and export the library over NFS with a large rsize and wsize. The transcoder reads sequentially at rates a single 10G link absorbs comfortably, and none of that traffic touches the public interface or the scrubbing path. It also lets each side scale on its own axis: add capacity to the pool without touching the GPU host, add a second card without moving 20 TB of media.
What goes wrong
- Assuming the GPU is being used. A container without the NVIDIA runtime silently falls back to libx264, and the only symptom is high CPU and stuttering playback. Check nvidia-smi during a transcode, not the logs.
- Burning in subtitles by accident. PGS and image-based subtitles force a full transcode of a stream that would otherwise direct play. Convert to SRT where possible and set client preferences accordingly.
- Writing transcode temp to the ZFS pool. Segment files are small synchronous writes on a pool tuned for large sequential media. Point the temp directory at local NVMe and the pool stops thrashing.
Tune the machine
- Storage and encryption — ZFS with hourly snapshots · €7
- Addressing and transit — Private VLAN between your servers · €6
- Addressing and transit — Uplink upgrade to 10 Gbps · €19
More
Built for specific jobs
Game server hosting
Tick rate is a single-thread problem. Everything else is noise.
Trading and low-latency VPS
Distance to the matching engine, and nothing between you and the wire.
Private VPN and proxy endpoints
Your own exit, in a jurisdiction you picked on purpose.
Seedboxes and bulk storage
Terabytes that stay cheap and a port that stays open.
Kubernetes worker nodes
Cheap per core, dense, and identical every time.
AI inference and fine-tuning
A whole GPU, passed through, on a commitment that makes the maths work.