System Requirements

What you need to run Sovereign depends far more on how often it has to re-encode a title than on how many people are watching. The specs on this page size a server for five users.

What Drives the Requirements

A few things about the way Sovereign works decide what you should buy, and most of them aren’t what you’d expect from a media server.

Direct Play costs almost nothing in CPU. When a client can already decode what’s on disk, Sovereign repackages the file instead of re-encoding it, which is a few percent of one core. Transcoding is where the money goes, so the question to ask is how many of your users are on a client that can’t play your files as they are. The Transcoding page covers what forces a re-encode.

A playing title doesn’t trickle onto disk at the speed you’re watching it. Sovereign packages the whole title ahead of you, as fast as your storage allows, and reclaims segments only once you’ve watched past them. Start a 60 GB 4K remux and most of that 60 GB lands in your data volume within a few minutes. Five people watching large remuxes at once can occupy several hundred gigabytes. It’s an easy component to under-size. The space is transient and comes back when the session ends, but it has to be there.

Some of a transcode can still land on the CPU when you have a GPU. Converting an HDR source to SDR runs on the GPU on every path whose driver passes Sovereign’s startup check: VAAPI converts on its own surfaces (on an Intel host that path is chosen for HDR ahead of Quick Sync), and NVIDIA converts over Vulkan. Where the check fails, the CPU converts. NVIDIA and Quick Sync still encode on the GPU, but on VAAPI the whole transcode moves to software. Interlaced sources and titles that need their frame size repaired for a strict client decoder are filtered on the CPU on NVIDIA and Quick Sync. VAAPI can’t repair a frame’s size at all, and deinterlaces on the GPU only alongside an HDR conversion, so those titles move to another encoder or to software. Don’t pair a fast GPU with a slow CPU.

Quick Sync needs 11th-generation Intel graphics or newer. The Quick Sync runtime inside the Sovereign image covers Gen12 graphics and later, which means 11th-gen Rocket Lake, 12th-gen Alder Lake, and everything since, plus discrete Arc cards. Older Intel integrated graphics still accelerate transcodes, but through VAAPI rather than Quick Sync.

Sovereign reads a source file as fast as your storage will serve it, not at playback speed. If your library lives on a NAS, a handful of sessions will saturate a gigabit link long before they trouble the CPU. See NFS Media Storage for mount options.

Playing a title for the first time costs more than playing it again, because Sovereign builds its scrub thumbnails alongside the stream. That cost is mostly paid in reads rather than in processor time, which is the next section.

Asset Generation on First Play

The first time anyone plays a title, Sovereign starts the stream and builds its scrub-preview thumbnails alongside it. Both read the same source file at once. A rewatch costs none of it, since the results are kept.

Thumbnail generation seeks to roughly one frame per preview rather than decoding the file through, so it’s bounded by how quickly your storage answers a seek rather than by the length of the title or the codec it’s in. A feature is typically done in seconds. Where it drags is a library on a slow or busy network mount, which is a storage problem rather than a processor one: the same title with its data already in cache finishes in about a second.

Text subtitles cost nothing extra. They’re produced by the pass that’s already building the video, so there’s no second reader of the file and no wait before captions appear.

Image-based subtitles can take much longer, though the job only runs when a viewer picks one of those tracks. On a file carrying an index to seek by, which covers most Matroska rips, a feature-length track takes well under a minute. On one without, the whole file has to be read through and it can run to tens of minutes. It’s cached per track, so the cost is paid once.

The tier tables below assume a library that’s mostly been watched before. If your users routinely open brand-new titles, raise the ceiling and accept the extra load:

Setting	Default	Raise it when
`Sovereign__AssetWork__MaxConcurrentJobs`	`0`	Several users start unwatched titles in the same evening and you have cores to spare
`Sovereign__Images__MaxConcurrentDownloads`	`2`	Artwork fills in slowly while you browse a freshly imported library

MaxConcurrentJobs is the only control over how much heavy background work runs at once. Thumbnail generation and image-based subtitle extraction each run a single worker and compete for it, so one number bounds both. Left at 0 it sizes itself to half your processor count, between one and four.

Artwork downloads and subtitle detection sit outside that ceiling. Neither is heavy enough to be worth queueing: artwork is network work rather than processor work, and detection is a sub-second probe that fills the track menu, so making a stream wait behind a long job to run it would relieve nothing.

Baseline

These apply whichever acceleration path you end up on.

Component	Minimum	Recommended	Enthusiast
RAM	8 GB	16 GB	32 GB
Data volume	256 GB SATA SSD	1 TB NVMe with DRAM cache	2 TB PCIe 4.0 NVMe
Network, library on the same host	1 GbE	1 GbE	2.5 GbE
Network, library on a NAS	2.5 GbE	2.5 GbE	10 GbE
Host	x86-64 Linux with Docker 24+

Your media library itself isn’t sized here. It’s mounted read-only and Sovereign never writes to it.

The memory figures cover roughly a gigabyte for the server itself (closer to two during a full library sync), a few hundred megabytes for each active session, and burst headroom for the artwork, thumbnail, and subtitle work that runs alongside playback.

Software Transcoding

Pick from this table if no GPU is exposed to the container, which includes virtual machines and Kubernetes nodes without device passthrough. That’s why the table lists F-suffix Intel parts and non-G Ryzen parts, which have no integrated graphics to fall back on.

A software transcode always produces 8-bit H.264. The FFmpeg build inside the image carries no software HEVC encoder, so H.265 and AV1 output, and HDR kept as HDR, all need a GPU.

Tier	CPU	Handles
Minimum	Intel Core i5-12400F or AMD Ryzen 5 5600	Two 1080p transcodes plus three Direct Play sessions on a watched library. No 4K transcoding.
Recommended	Intel Core i5-14500 or AMD Ryzen 7 7700	Three to four 1080p transcodes plus Direct Play, or one 4K downscale.
Enthusiast	Intel Core i9-14900K or AMD Ryzen 9 9950X	Five 1080p transcodes at once, or a single 4K HDR title with its conversion.

Intel Quick Sync

Requires 11th-generation Intel graphics or newer, with the render device exposed to the container. Setup is on the Intel QSV page.

Tier	CPU	GPU	Handles
Minimum	Intel N150 or Core i3-12100	Integrated UHD or Xe, 24 EU	Three to four 1080p transcodes plus Direct Play. HDR titles convert on the GPU via VAAPI.
Recommended	Intel Core i5-13500	Integrated UHD Graphics 770	Five 1080p transcodes, plus one 4K HDR title with its conversion.
Enthusiast	Intel Core Ultra 5 245K	Intel Arc B580 12 GB, or Arc A380 6 GB for a low-profile case	Five 4K transcodes with room to spare, and AV1 encoding.

VAAPI

The path for AMD graphics and for Intel integrated graphics older than 11th generation. Setup is on the VAAPI page.

Size the CPU here more generously than on the other GPU paths. VAAPI can’t repair a title’s frame size, or deinterlace one that isn’t also being converted from HDR, so those transcodes land on the processor, and so does any HDR title on a host whose driver fails the startup check for the GPU conversion.

Tier	CPU	GPU	Handles
Minimum	AMD Ryzen 5 5600G or Intel Core i5-10500	Integrated Radeon Vega 7 or Intel UHD 630	Three 1080p transcodes plus Direct Play. HDR titles will struggle.
Recommended	AMD Ryzen 7 8700G	Integrated Radeon 780M	Five 1080p transcodes. A 4K HDR title converts on the GPU, a little faster than real time.
Enthusiast	AMD Ryzen 9 7900X	AMD Radeon RX 7600 8 GB	Five 4K transcodes, with enough CPU left over to absorb an HDR title falling back to software.

The Ryzen 8700G is the value pick on this path. Its integrated graphics handle the hardware transcodes and its eight cores cover everything VAAPI won’t touch.

NVIDIA

Requires the NVIDIA Container Toolkit and the video capability, so the encode and decode libraries load inside the container. Add the graphics capability as well, or HDR titles are converted on the CPU. Setup is on the NVIDIA page.

Tier	CPU	GPU	Handles
Minimum	Intel Core i5-12400 or AMD Ryzen 5 5600	NVIDIA GTX 1650 SUPER 4 GB or Quadro P1000	Four to five 1080p transcodes plus Direct Play.
Recommended	Intel Core i5-14500 or AMD Ryzen 7 7700	NVIDIA RTX 3050 8 GB or RTX A2000 12 GB	Five 1080p or three 4K transcodes, plus one HDR title without stalling the rest.
Enthusiast	Intel Core i9-14900K or AMD Ryzen 9 9950X	NVIDIA RTX 4060 8 GB, or RTX 2000 Ada 16 GB at 70 W for a low-profile case	Five 4K transcodes including HDR, and AV1 encoding.

NVIDIA limits how many encode sessions run at once on consumer GeForce cards, and the limit depends on your driver. It’s eight on Linux driver 550.54.14 and newer, five on 530.41.03 and newer, and as low as two or three on older releases. Five users fit comfortably on a current driver, but a pinned old one will cut you off. Professional cards (Quadro, RTX A-series, and RTX Ada) have no such limit.

Video memory isn’t a constraint. A 1080p session uses a few hundred megabytes and a 4K session stays under a gigabyte, so 4 GB is enough and 8 GB is comfortable.

Sizing for Heavier Use

If you expect all five users to transcode at once, move up one tier on the software and VAAPI tables. The Quick Sync and NVIDIA tables already carry the encoder headroom at the Recommended row, though you should still move up a tier on RAM and on the data volume.

A 4K HDR library changes the picture more than user count does. Every one of those titles that can’t Direct Play needs its colour converted, and on the software path, or wherever your GPU fails the startup check for that conversion, the CPU does it. On those hosts treat the Enthusiast CPU as the starting point rather than the ceiling.

How new your content is matters nearly as much. A server whose users mostly rewatch is doing pure playback, while one that tracks new releases is generating thumbnails and extracting subtitles on almost every session. If that’s you, size for the software tier one step up even on a GPU host, since none of that background work touches the GPU.

Before you spend anything on hardware, check the Active Streams page to see how often your clients actually fall back to transcoding, and the Queue Status panel on the admin overview to see whether background work is keeping up.

Next Steps

Hardware Acceleration - expose your GPU to the container
Transcoding - what forces a re-encode, and why
Video Quality - the bitrate ceiling and quality target
NFS Media Storage - mount options for a NAS-hosted library

Titles, artwork, people and descriptions shown in screenshots are fictional and were created for illustration. Sovereign doesn't include or supply any media: it plays the library you bring.