# docker-prowlarr: a LinuxServer container for the Prowlarr indexer manager > This repository is not Prowlarr itself but the LinuxServer.io container that packages it, with s6 overlay as the init system, PGID and PUID user mapping, multi-arch tags for x86-64 and arm64, and separate stable, develop and nightly image tags. It suits a homelab operator who wants Prowlarr updated and supervised by a container runtime, and it suits nobody who wants to read or modify Prowlarr's own source. **linuxserver/docker-prowlarr** — Docker image for Prowlarr/Prowlarr - Repository: https://github.com/linuxserver/docker-prowlarr - Stars: 555 · Forks: 30 - Language: Dockerfile - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/linuxserver-docker-prowlarr ## A container recipe, not the application itself The first thing to understand about this repository is what it is not. Prowlarr is an indexer manager and proxy built on the arr .NET and React base stack, and it lives in the Prowlarr/Prowlarr repository. This repository, linuxserver/docker-prowlarr, is the LinuxServer.io packaging of it. That distinction shapes the whole article. The features here are container features: regular and timely application updates, easy user mappings through PGID and PUID, a custom base image with s6 overlay, weekly base OS updates with common layers across the LinuxServer ecosystem to minimise space usage, downtime and bandwidth, and regular security updates. The s6 part is the substantive engineering choice. A container image has to start, supervise and stop processes, and s6 overlay is a supervision system designed for that job, used here as the base image layer rather than as something the container adds on top. For a service like an indexer manager that runs a database, a web server and a background worker, the supervision and the graceful shutdown behaviour are what keep restarts from corrupting state. The user mapping is the other thing worth understanding. PUID and PUID-adjacent conventions exist because a container runs as a fixed numeric user, and files it writes in a mounted volume will otherwise be owned by a UID that your host user cannot manage. Mapping the container user to the host user means the configuration directory stays editable from the host. The repository layout confirms the scope: a `Dockerfile`, a `Dockerfile.aarch64` for the arm64 build, a `Jenkinsfile` and `jenkins-vars.yml` for the CI pipeline, `readme-vars.yml` and `package_versions.txt` for the documentation generation, a `root/` directory holding the container's own files, and an `AGENTS.md`. There is no application source here to read. ## What the image does at build time The Dockerfile is short, and each step is worth reading because it shows what the image actually contains. The base is `ghcr.io/linuxserver/baseimage-alpine:3.24`, and the first thing installed is a set of Alpine packages: `icu-libs`, `sqlite-libs` and `xmlstarlet`. The SQLite libraries are there because Prowlarr keeps its database in SQLite, and the base image is Alpine, so musl rather than glibc is what everything is linked against. The application itself is downloaded rather than compiled. The build declares `ARG PROWLARR_BRANCH="master"` as an environment variable, and if `PROWLARR_RELEASE` is not already set, the build queries the Prowlarr update API for the current version on that branch, pulling the first entry's version field out of the JSON. Then it downloads the update file for that version, targeting `os=linuxmusl` and `runtime=netcore` with `arch=x64`, and untars it into `/app/prowlarr/bin` with the top level directory stripped. So the version that ends up in the image is decided at build time from the branch argument. That single argument is what separates a stable image from a development one, and it is the mechanism behind the tag table. Two files are written for the application to read about itself. The `package_info` file records the update method as `docker`, the branch, the package version and the package author, and `/build_version` records the LinuxServer version and the build date. The updater inside Prowlarr reads these to decide whether it is in a container or a native install and which branch it belongs to. The cleanup step removes the updater binary and the temporary directories, then the local `root/` files are copied into the image. The two declarations that end the Dockerfile are the whole host-side contract. ```dockerfile # ports and volumes EXPOSE 9696 VOLUME /config ``` ## The two things the host has to get right: the port and the config volume The Dockerfile ends with two declarations that determine how the container has to be run. `EXPOSE 9696` is the web interface. The README confirms it, telling you to access the web UI at `:9696` and pointing at the Prowlarr project for more information, with setup notes in the Servarr wiki's Prowlarr quick start guide. Since Prowlarr integrates with Sonarr, Radarr, Lidarr and Readarr, and it does the indexer setup for all of them rather than per app, that web interface is where you do the configuring. `VOLUME /config` is where the state lives. The environment section sets `XDG_CONFIG_HOME="/config/xdg"` and `TMPDIR=/run/prowlarr-temp`, and the Prowlarr configuration and database end up under the config volume. That single mount is what makes the container disposable: rebuild the image, replace the container, keep the volume, and nothing is lost. The other environment variable is `COMPlus_EnableDiagnostics=0`, which disables the .NET diagnostics. That is a small thing but a sensible one in a container, since the runtime telemetry has no use in that setting. The README also opens a section on read-only operation, stating that the image can be run with a read-only container filesystem. The section is truncated in the text available here, so the exact requirements for that mode are not visible, but the claim is there and it matters for anyone running Prowlarr on a hardened host where the root filesystem is mounted read-only and only the config volume is writable. The port and the volume are therefore the whole host-side configuration surface. Everything else is how you deploy the container. ## Version tags, multi-arch, and the choice you have to make at pull time The image is published under several tags, and the README asks you to read the descriptions carefully and exercise caution with unstable or development tags. `latest` gives Prowlarr stable releases. `develop` gives Prowlarr releases from their develop branch. `nightly` gives Prowlarr releases from their nightly branch. That mapping is direct: the tag selects the branch, and the branch selects the application version the build fetches through the `PROWLARR_BRANCH` argument. In other words, the tag is not a label applied to an identical binary, it changes what is downloaded. Architecture is handled through the docker manifest, which the README says gives multi-platform awareness. Pulling `lscr.io/linuxserver/prowlarr:latest` should retrieve the correct image for your architecture, and the table lists x86-64 and arm64 as available, with architecture specific tags of the form `amd64-` and `arm64v8-` if you want to pin one explicitly. The `Dockerfile.aarch64` in the repository root is the arm64 build definition, and `jenkins-vars.yml` and `package_versions.txt` are the pipeline's record of what each build contains. The release list on the repository shows three tags moving in a single day, which makes the cadence visible: a nightly build, a develop build and a versioned release, all dated 2026-10-19 in the snapshot data, with the versioned one at 2.6.5.5623-ls164 dated 2026-10-18. For a production deployment the practical rule is simple and worth stating plainly. Use `latest` and let the pipeline give you stable builds. Use `develop` or `nightly` only on a host where a broken Prowlarr release does not matter, because the README's own caution is the warning. ## What this container is for, and what it does not include Prowlarr itself is the product, and its purpose is worth restating precisely because the container inherits it entirely. It is an indexer manager and proxy, built on the arr .NET and React stack, that integrates with your various PVR applications. It supports both torrent trackers and Usenet indexers. It integrates with Sonarr, Radarr, Lidarr and Readarr, and the claim in the README is complete indexer management with no per app indexer setup required, because Prowlarr does that centrally. That is a genuinely different arrangement from configuring each download client separately in each application. The indexer credentials, the search rules and the proxy settings live in one place, and the other applications point at Prowlarr. If you run several arr applications, that centralisation is the reason to run Prowlarr at all. What the container does not include is equally clear. It does not include any indexers, accounts, or credentials, which you configure through the web interface after the first start. It does not include the Prowlarr source, which lives upstream and is only downloaded as a build artefact here. And it does not include any of the arr applications themselves, each of which has its own container in the same ecosystem. The community and support channels are worth listing because they are part of what you are adopting. There is a blog, a Discord with realtime support and chat, GitHub Discussions for the community forum, the GitHub organisation, and an Open Collective page for supporting the team. The licence is GPL-3.0, and the repository is not archived, with the last push on 2026-10-19. ## Where this approach stops, and what to use instead There are two situations where this container is the wrong choice, and one where it is the wrong level of abstraction. The first is if you need to change how Prowlarr behaves. The application is a .NET and React application with its own repository, its own issue tracker and its own release process. The container takes the released binary and packages it. Anything that requires a code change to Prowlarr has to go upstream, and if you need that change today, the container cannot give it to you. The `root/` directory and `AGENTS.md` in this repository concern the container's own files and the process for contributing to them, not the application. The second is if you cannot run containers in the first place, or if your hosting model forbids them. Then the native Linux install of Prowlarr, which the LinuxServer release notes explicitly differentiate from by writing `UpdateMethod=docker` into `package_info`, is the path. The upstream project publishes its own install instructions, and the Servarr wiki has the quick start guide that the README links to. The third is a distinction of level rather than capability. A container image is not the only way to deploy this, and it is not the best one for everyone. A single container that runs Prowlarr alongside your other arr applications through Docker Compose is one approach; running each application directly under a service manager on a bare host is another; running them on a NAS with the platform's own application system is a third. The container's advantages are the update cadence, the s6 supervision, and the fact that the configuration is a directory you can back up and restore. Its cost is that you now own a container runtime, the image tags, and the volume permissions. One operational detail deserves attention because it is a real failure mode. Because `latest`, `develop` and `nightly` are separate tags and the pipeline builds continuously, an automatic image pull on a schedule can move you between application versions without you deciding to. Pinning a versioned tag instead of `latest` is what turns the update cadence into something you control. ## Conclusion Adopt docker-prowlarr if you already run containers and want Prowlarr updated on a schedule with the configuration in a single volume, since the image carries the LinuxServer s6 base and the update pipeline that the upstream release does not. Do not adopt it to read or change Prowlarr's behaviour, because the application source lives in the Prowlarr/Prowlarr repository and this one only holds a Dockerfile plus container glue. Before pulling, pick the tag deliberately, `latest` for stable releases and `develop` or `nightly` only if you accept unstable builds, then check that the `EXPOSE 9696` port and the `/config` volume match your reverse proxy and your backup routine. ## FAQ ### What is the difference between docker-prowlarr and Prowlarr itself? Prowlarr is the indexer manager and proxy application, built on the arr .NET and React stack and developed in the Prowlarr/Prowlarr repository. docker-prowlarr is the LinuxServer.io container packaging that application, holding the Dockerfile, the s6 base image setup and the CI pipeline. ### Which image tags are available for docker-prowlarr? Three are listed: `latest` for Prowlarr stable releases, `develop` for releases from the develop branch and `nightly` for releases from the nightly branch. The README asks you to read the descriptions carefully and to exercise caution with the unstable or development tags. ### What port does the Prowlarr container expose and where does it store its configuration? The Dockerfile declares `EXPOSE 9696` and `VOLUME /config`, and the README tells you to reach the web interface at `:9696`. The config volume holds the application configuration and its SQLite database. ### Does docker-prowlarr support arm64 and Apple Silicon? The README lists x86-64 and arm64 as available, with the docker manifest used for multi-platform awareness, and architecture specific tags of the form `amd64-` and `arm64v8-`. A separate `Dockerfile.aarch64` exists in the repository for the arm64 build. ### How does the container decide which Prowlarr version to install? At build time it queries the Prowlarr update API for the current version on the branch given by the `PROWLARR_BRANCH` argument, which defaults to `master`, then downloads that release for musl and netcore. The image also writes a `package_info` file recording the update method as `docker` and the branch used. ## Sources - [Issues](https://github.com/linuxserver/docker-prowlarr/issues) - [License: GPL-3.0](https://github.com/linuxserver/docker-prowlarr/blob/main/LICENSE) - [linuxserver/docker-prowlarr on GitHub](https://github.com/linuxserver/docker-prowlarr) - [README](https://github.com/linuxserver/docker-prowlarr/blob/main/README.md) - [Releases](https://github.com/linuxserver/docker-prowlarr/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/linuxserver-docker-prowlarr