Can Plex Share a GPU With Another Docker Container?

Yes, Plex can often share a GPU with another Docker container, but exposing the same device to both containers does not reserve or guarantee performance for either workload.

The decision depends on the GPU, Linux driver, container runtime, workload type, and how each application uses video engines, compute, and memory. Intel integrated graphics are commonly exposed through Linux device nodes such as /dev/dri, while NVIDIA containers use the NVIDIA container runtime or Docker GPU reservations. Configure access first, then run Plex and the second workload together and verify that Plex still hardware-transcodes under the load you actually care about.

Confirm that Plex can use the GPU by itself first

Before testing sharing, run one forced Plex transcode with the other GPU workload stopped. Plex should report hardware acceleration for the stream and the host should show the expected video engine or GPU activity. If Plex cannot use the device alone, adding another container only makes the diagnosis noisier.

The Plex hardware-accelerated streaming guide explains that Docker deployments must expose the relevant kernel device to the container for hardware acceleration. Use the current device method for your platform rather than assuming a GPU detected by the host is automatically visible in Plex.

Record the baseline transcode start time, CPU use, GPU/video-engine use, and playback stability. That gives you a control result for the sharing test. Without a clean baseline, you cannot tell whether later failures come from contention or from the original Plex GPU setup.

Expose the same device deliberately to the second container

For NVIDIA, Docker Compose can reserve GPUs by count or device ID for a service. If two services are configured to see the same GPU, the runtime can expose that device to both; this is access control, not an exclusive-performance contract. For Intel or other Linux devices, both containers may be granted access to the same relevant device node when the driver permits concurrent use.

Docker’s Compose GPU support documentation shows how services request GPU access and target specific device IDs. Use a specific device when you have multiple GPUs so Plex does not silently move between devices while you test sharing.

Check permissions after every container recreation or app-template change. A second container working does not prove Plex still has device access, and a Plex setting showing hardware acceleration enabled does not prove the active stream is using it.

Test both workloads together and watch the first resource that saturates

Start the second workload at a representative level, then force the same Plex transcode used for the baseline. Compare playback stability, transcode speed, GPU memory, video-engine utilization, and CPU fallback. If Plex changes from hardware to software or begins buffering only when the other workload is active, you have a contention result rather than a compatibility mystery.

The ZimaSpace GPU preflight guide recommends verifying not only device detection but also container access and whether storage, backups, and media tasks remain responsive under the combined workload. That whole-system test is especially important on a NAS where Plex is not the only service that matters.

If the workloads use different GPU engines, sharing may work well; if both compete for the same video encode/decode engines, memory, or power/thermal headroom, performance can degrade sharply. Do not assume low overall “GPU percent” means the specific video engine Plex needs is free.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Set the boundary for when sharing is no longer a good fit

Keep the shared configuration if Plex remains in hardware mode, the second container meets its target, and the NAS stays responsive under the combined load. Repeat the test after a Plex restart and after the second container restarts so device mappings and permissions survive normal lifecycle events.

If contention is occasional, schedule the heavy second workload away from peak streaming time or add application-level limits. If both workloads must run at full demand simultaneously and one consistently starves the other, dedicate a second accelerator or move one workload to another host instead of chasing fragile priority tweaks.

Escalate to driver or runtime troubleshooting when either container loses the GPU even with the other stopped. A sharing problem should only be diagnosed after both applications can independently access the device and the failure appears specifically under concurrent use.