plexinc/pms-docker: the official Plex Media Server image and how to run it

What plexinc/pms-docker actually is, and who it is for

This is Plex's own packaging of Plex Media Server as a Docker image, published under the plexinc/pms-docker name. The README describes it as the official Docker container for Plex Media Server. That distinction matters more than it sounds: the image is built from this repository rather than by a third party tracking Plex releases, and the repository also carries a Helm chart under charts/ for Kubernetes users.

The intended audience is someone who already runs Docker and wants Plex Media Server managed the same way as the rest of their stack. It is not aimed at people who want a one-click media appliance. You have to decide on a networking mode before you start, supply a claim token, and map at least two volumes. The README is explicit that host and macvlan networking are the easier setups and that bridge works but is more complicated.

If you are evaluating this against a community image, the practical question is not features but packaging: this repository's Dockerfile is short and readable, and it tells you exactly what is inside.

Inside the image: Ubuntu 24.04, S6 overlay and a build-time installer

The Dockerfile starts from ubuntu:24.04 and sets ENTRYPOINT to /init, which is the S6 overlay init rather than the Plex binary. The S6 overlay version is pinned as a build argument, S6_OVERLAY_VERSION=v2.2.0.3, and the build downloads the matching architecture tarball (armhf, amd64 or aarch64) from the just-containers/s6-overlay releases. Process supervision is therefore handled by S6, not by a shell script looping in the background.

A plex user is created with its home directory set to /config, and the directories /config, /transcode and /data are created at build time. The image installs tzdata, curl, xmlstarlet, uuid-runtime and unrar from apt. The Plex binary itself is fetched during the build by /installBinary.sh, driven by build arguments PLEX_DISTRO (default debian), TAG (default beta) and URL. That default TAG=beta is worth noticing: the image as built from this Dockerfile tracks the beta channel unless the build overrides it.

The runtime contract is declared in the Dockerfile: EXPOSE lists 32400/tcp, 8324/tcp, 32469/tcp, 1900/udp and the four 32410 to 32414/udp ports, VOLUME declares /config and /transcode, and a HEALTHCHECK runs /healthcheck.sh every 5 seconds with a 2 second timeout and 20 retries. ENV sets CHANGE_CONFIG_DIR_OWNERSHIP to true and HOME to /config.

Installing plexinc/pms-docker and running it with host networking

The README's recommended path is host networking, which it calls one of the two easier setups. The command below is the host networking example from the README with the placeholders left in place. Replace the timezone, the claim token and the three volume paths with your own.

docker run \
-d \
--name plex \
--network=host \
-e TZ="<timezone>" \
-e PLEX_CLAIM="<claimToken>" \
-v <path/to/plex/database>:/config \
-v <path/to/transcode/temp>:/transcode \
-v <path/to/media>:/data \
plexinc/pms-docker

After the container starts, the HEALTHCHECK defined in the Dockerfile polls /healthcheck.sh, so `docker ps` will show a health status rather than just running. The README notes one prerequisite for host networking: if /etc/hosts is missing an entry for localhost, add one before using this mode.

PLEX_CLAIM is the token that lets the server obtain a real server token. The README states that if it is not provided, the server will not be claimed. It also states that the recommended parameters, including HOSTNAME, TZ and PLEX_CLAIM, are treated as first-run parameters only, and that all other parameters are ignored on subsequent runs. Getting the claim token right the first time is therefore cheaper than fixing it later.

If you prefer bridge networking, the README's example forwards 32400/tcp, 8324/tcp, 32469/tcp, 1900/udp and the four UDP ports 32410 through 32414, and adds ADVERTISE_IP="http://<hostIPAddress>:32400/". The README warns that in bridge mode Plex sits behind two routers and cannot set up port forwarding on its own, so you must forward port 32400 manually on your router. For docker-compose users, the repository ships docker-compose-bridge.yml.template, docker-compose-host.yml.template and docker-compose-macvlan.yml.template to adapt.

The /config volume is where this image can hurt you

The single most consequential parameter is the /config bind mount. The README says the database can grow to a few GB, and for large libraries or libraries where index files are generated it can easily reach the hundreds of GB. It also states plainly that the underlying filesystem needs to support file locking, that this is known not to be default-enabled on remote filesystems like NFS and SMB, and that most such filesystems will result in database corruption. The 9PFS filesystem used by FreeNAS Corral is called out as known to work.

That is an unusually direct warning, and it should be read as a hard constraint rather than a suggestion. Putting /config on a NAS share is the classic way to lose a Plex library database. If your storage plan is "media on the NAS, config on the NAS too", this image is the wrong tool until the config directory moves to local disk.

The /transcode volume is less dangerous but not free. The README says that if it is not provided, storage space inside the container is used, and that you should expect sizes in the tens of GB. Omitting the mount means transcode temp files land in the container's writable layer.

plexinc/pms-docker versus linuxserver/plex: the real difference

The comparison people search for is against linuxserver/plex, and the honest difference is not the Plex version, since both run Plex Media Server. It is the packaging and the operational contract around it.

This repository is Plex's own. Its Dockerfile is in the repository, its base image is ubuntu:24.04, its init is S6 overlay, and the Plex binary is installed at build time by /installBinary.sh with a TAG argument that defaults to beta. The README's parameter list is short and focused on the container: ports, three volume paths, and environment variables. The repository also carries a Helm chart in charts/ with its own release cadence, plus lint targets in the Makefile for chart testing, yamllint and kubeconform.

A community image typically layers its own conventions on top: different user and group handling, a different internal layout, its own set of environment variables, and its own documentation. Those conventions are the reason people pick one over the other, and they are also the reason switching later is not a drop-in operation. Nothing in this repository documents a migration path from another image's directory layout into /config. If you already have a library built on a different image, plan that move yourself before you switch, because the README does not cover it.

The fair summary: choose this image if you want Plex's own build and are comfortable with the networking choices the README lays out. Choose a community image if you depend on its specific conventions or on documentation this repository does not provide.

Kubernetes, the Helm chart and what the Makefile does not tell you

For Kubernetes, the repository carries a Helm chart under charts/plex-media-server, and recent releases are tagged helm-chart-1.9.0, helm-chart-1.8.0 and helm-chart-1.7.1. The Makefile shows the intended workflow: ct lint with a config at .github/linters/ct.yaml, helm-docs for chart READMEs, yamllint with .yamllint, and a kubeconform target that renders the chart with helm template and validates against Kubernetes 1.33.0 schemas in strict mode.

What the Makefile does not show is a release process for the image itself, and the README does not document rollback, pinning to a specific Plex version, or how to move an existing /config directory between hosts. Those are the gaps to plan around. The build arguments TAG and URL exist in the Dockerfile, but the README does not explain how a user would consume a pinned tag rather than the default.

There is also no licence file at the top level of the repository as listed. The README does not state a licence for the image or the chart, and the repository entries include a CODE_OF_CONDUCT.md but no LICENSE. If you need to redistribute the image or the chart, that is a question to resolve with Plex directly rather than assume.

Editorial conclusion

Adopt plexinc/pms-docker if you want the image Plex itself publishes, you are comfortable choosing between host, macvlan and bridge networking, and your /config volume sits on a filesystem with working file locking. Skip it if you need a documented migration path off the linuxserver/plex layout, or if you cannot move your config directory onto local storage, because the README warns that NFS, SMB and most network shares lead to database corruption. Before you commit, verify two things: that the container comes up healthy under the HEALTHCHECK defined in the Dockerfile, and that the PLEX_CLAIM token you pass is still valid, since it is a first-run parameter only.

Frequently asked questions

Official sources

1. Issues
2. plexinc/pms-docker on GitHub
3. README
4. Releases