Reaparr pulls content off your Plex servers into a local library

A download manager for media you already have access to

Reaparr describes itself in one line as a Plex downloader that brings content from any server to yours. That is the whole product idea: you point it at a Plex server, and the files end up in a local library that you control, outside the server that currently holds them.

The project is written in C# and builds as a .NET solution, Reaparr.sln, with a Directory.Build.props file for shared build properties and a global.json that pins the SDK the repository expects. The runtime dependencies sit in src/, the tests in tests/ and the developer tooling in tools/.

It ships as a container image, with a DockerHub repository for the project linked from the README, and the project maintains its own site at www.reaparr.rocks with a separate screenshots page. The README also points at a Discord invite and a separate documentation repository, since the image referenced for the social preview lives in a Docs repository rather than here.

The description does the work that a feature list would normally do, and it is worth naming the scope honestly. This is a download client for media libraries you can already reach. It is a tool for taking possession of your own files, or files your account is entitled to, and for keeping them in a form you control.

The licence is GPL-3.0, with the terms in the LICENSE file at the root of the repository, which matters for a project published as a service as well as a program.

The README is a landing page, and the manual is somewhere else

Reading the README closely is instructive, because almost none of it is documentation. What it contains is an image that links to the project site, a link inviting readers to visit that site, a link to the screenshots page, a note asking for stars on GitHub and DockerHub that says this motivates the maintainers and helps pay the rent, and a set of badge images for stars, followers and Docker pulls.

There is no installation command here, no configuration reference, no description of the queue behaviour, and no explanation of what happens when a download fails or how a download is resumed. The project is GPL-3.0 and the site is the manual.

That is a legitimate choice for a project with a public website and a community Discord, and it has one real cost for an engineer evaluating it. The information needed to decide whether to run it is not in the repository, so the evaluation has to happen on the website and in the running container. The repository itself is where you read the code, the changelog and the issue tracker.

The one piece of the README worth reading literally is the request for stars, because it tells you something about the project's incentives. The maintainers are asking for visibility, and a project that is asking for visibility is still building the audience it needs.

Dev branch, dev suffixed tags, and a release script

The default branch of this repository is dev, and every release tag in the recent list carries a development marker: v0.41.0-dev.1 on 2026-10-02, v0.41.0-dev.2 on 2026-10-04 and v0.41.0-dev.3 on 2026-10-05. Three builds of the same target version inside four days is a snapshot of an active development line, not a set of stable releases.

The last push to the repository was on 2026-10-20, two days after the most recent tag, so the branch is ahead of what is tagged.

The machinery behind the tags is visible in the top level. There is a release.config.mjs file, which is the configuration pattern used by a JavaScript based release tool that derives version bumps and changelog entries from commit messages, and a CHANGELOG.md alongside it. A Conventional Commits style pipeline, which is what such a configuration implies, is also consistent with the commit-shaped version tags, where the dev suffix and the count follow the target version.

For a user this arrangement is workable as long as you treat the image as something you redeploy rather than something you pin and forget. A dev tagged build tells you the shape of the release, and the changelog tells you what changed, but neither promises that the next build will be compatible with your configuration. There is also no stable release stream visible in the tag list to fall back to.

The tree shows a service with a UI, a queue and a test suite

The topic list attached to the repository includes downloader, download-manager, plex, plex-media, hacktoberfest, and, unusually for a C# project, nuxt and vue. Those last two describe the frontend stack of the web interface that the service exposes, and the .NET backend talks to it.

That combination explains the shape of the top level. The src/ directory holds the service, tests/ holds the test suite, and tools/ holds developer tooling. The docker/ directory holds the container definition that produces the image published on DockerHub, which is what makes the whole thing a service you run rather than a program you execute.

Two directories are less obvious and worth a note, because the README explains neither. There is an export/ directory at the top level, and a plans/ directory. The name of the second suggests design work kept in the repository rather than in a tracker, and the presence of both means the project keeps some of its planning artefacts in the open. There is also a TODO.md, a CONTRIBUTING.md, an AGENTS.md file and a .agents/ directory, plus a .skillshare/ directory, which together suggest that a significant part of the project's working method is written down for tools as much as for people.

None of this tells you how the download queue behaves under load, and the repository does not answer that question.

Automation-first repository conventions

The repository carries the marks of a project run by tooling rather than by habit. There is a .coderabbit.yml configuration for automated code review, an .editorconfig for formatting rules, a .csharpierignore file, which points at the CSharpier formatter being used to keep C# style consistent, and a .run/ directory that holds IDE run configurations so that a developer can launch the service from an editor without reconstructing the command line.

There is a .dockerignore, so the container build has an explicit exclusion list, and a .gitignore. The .github/ directory holds the workflows, and the presence of a CI badge in the README is the visible evidence that those workflows run.

A solution file is checked in, along with Reaparr.sln.DotSettings, which carries shared IDE settings for the solution, so that a contributor's editor settings match the project's. The contributor guide, the code of conduct and the changelog are all present at the root, which is the minimum a project should have when it invites outside contributions, and the hacktoberfest topic indicates that it has done so on a schedule.

For an engineer joining the project, the practical summary is that onboarding runs through a .NET solution, a container build, a set of GitHub workflows and a documented local run configuration, and the interesting work is likely in src/ and the Vue and Nuxt frontend rather than in the scripts.

What this tool is, and where the line sits

It is worth being explicit about the category, because the category decides the ethics. Reaparr moves files that a Plex account is already entitled to see, from a server to a local library. Used that way it is the self-hosted equivalent of the download feature that media clients ship with, and the interesting engineering is in the queueing, the throughput control and the metadata handling that make a large library manageable.

The general purpose alternative is a conventional download manager fed with direct links, and the difference in approach is that a general purpose tool knows nothing about your media library: it does not know which item an episode belongs to, it does not know which quality profile you want, and it cannot keep a Plex library and a download folder in agreement. Reaparr is built around that agreement, and pays for it with a heavier service footprint, a container to run and a queue to operate.

The boundary is the same one that applies to any tool acting on behalf of an account: use it with servers and credentials you are entitled to use. The GPL-3.0 licence is what the project offers in return, and for a service that copies media on behalf of its users it is a licence worth reading properly, since copyleft obligations attach to modified versions offered over a network.

Editorial conclusion

Reaparr fits a self-hosted media user who wants the download step handled as a service with a queue rather than by hand, and it does not fit someone who expects a stable release train, since the default branch is dev and the published tags are development builds. Before adopting it, read the installation and configuration details on the project site, since the README in this repository contains almost no operational instructions, and check the GPL-3.0 terms, because a network service that copies media for its users is a case where copyleft obligations are worth understanding rather than assuming away.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Reaparr/Reaparr on GitHub
5. Releases