Recyclarr syncs TRaSH Guides settings into Sonarr and Radarr instances

What gets synced into an instance, and which versions it accepts

Recyclarr is a C# command-line application with one job: copying recommended settings out of the TRaSH Guides and into Sonarr and Radarr instances you already run. Support stops at v4 and higher, so an installation still on v3 gets nothing from it. Five groups are in scope: Quality Profiles with their qualities and quality groups, Custom Formats with scores taken from the guide or set manually, Quality Definitions carrying file sizes, Media Naming Formats, and Media Management covering Propers and Repacks. The flow runs one way, from the published guide into the instance, and nothing described here reads your local values back out. Beyond those five groups the README defers to the Features page on recyclarr.dev rather than enumerating, which leaves the edge of the tool blurrier than a five-item feature list makes it look.

The compose file at the repository root is a test harness

The repository root holds a file called docker-compose.yml whose name field is `recyclarr`, and it reads like a deployment recipe until you look at the services. It is a test harness. Four arr containers come up, two Radarr and two Sonarr, from rolling images with `pull_policy: always`, each with its API key set to the literal `testkey` and authentication turned off for local addresses. Running two of each is the point: a sync that can target more than one instance needs more than one instance to target.

The environment block for the Radarr template shows how little ceremony the harness needs.

x-radarr: &radarr
  image: ghcr.io/home-operations/radarr:rolling
  pull_policy: always
  environment:
    TZ: America/Chicago
    RADARR__AUTH__APIKEY: testkey
    RADARR__AUTH__METHOD: Forms
    RADARR__AUTH__REQUIRED: DisabledForLocalAddresses

Four instance services follow, each bound to a different host port and its own named volume.

  radarr_develop1:
    <<: *radarr
    ports: [7890:7878]
    volumes: [radarr_develop1:/config]

  radarr_develop2:
    <<: *radarr
    ports: [7891:7878]
    volumes: [radarr_develop2:/config]

  sonarr_develop1:
    <<: *sonarr
    ports: [8990:8989]
    volumes: [sonarr_develop1:/config]

The same file raises ntfy and apprise for notification checks.

  ntfy:
    image: binwiederhier/ntfy
    pull_policy: always
    ports: [8090:80]
    command: serve --base-url=http://localhost:8090

What is absent from all of it matters more than what is present. No service in that compose file runs Recyclarr, so copying it onto a real server would hand you four empty instances, two notification tools and no sync tool at all.

Why the latest Docker tag will not start anything

A warning sits high in the README: the `latest` Docker tag is not available on Docker Hub or GHCR, and you are told to use a major version tag such as 8 instead. That advice carries a cost worth naming. A major tag resolves to whatever the newest build in that series happens to be, so an ordinary image refresh months from now pulls code you have not read into a container whose purpose is rewriting settings on your instances. Pinning an exact patch build keeps the running code fixed and puts the upgrade decision back on you, which is the opposite of what the README asks for. The same README also narrows where you can ask for help: GitHub Issues is reserved for bug reports and feature requests, and configuration questions go to the TRaSH-Guides Discord server in the `#recyclarr` channel. Budget for that when you are stuck on a profile that will not apply.

RECYCLARR_CREATE_CONFIG=false means the container starts empty

The published image is not shaped for an interactive session. It comes up with `CRON_SCHEDULE` set to `@daily`, and the image installs supercronic, a cron implementation, so the normal mode of the container is to wake, sync, and exit. `RECYCLARR_CONFIG_DIR` points at `/config`, the same path declared as a volume, and `RECYCLARR_CREATE_CONFIG` is set to false, so the shipped default is not to write a starting config for you.

ENV PATH="${PATH}:/app/recyclarr" \
    RECYCLARR_CONFIG_DIR=/config \
    CRON_SCHEDULE="@daily" \
    RECYCLARR_CREATE_CONFIG=false \
    COMPlus_EnableDiagnostics=0

First use therefore begins on your side of the wire: mount a config at `/config` carrying the API keys of the instances you want touched. That ordering catches people out, because a container that refuses to scaffold a config and then has nothing to say is indistinguishable from a broken one until you read the environment block above. Nothing in the repository documents what the true value of that variable does beyond its name, so treat the scaffold as undocumented rather than as a supported first-run mode.

Two-stage Alpine build and the tini entrypoint

The Dockerfile is a two-stage Alpine build, and reading it tells you exactly what ships. The build stage starts from the .NET 10 SDK image, copies the props and project files ahead of the source so restore can reuse a cached layer, then publishes a single project, `src/Recyclarr.Cli`, for the target architecture.

COPY --link --parents *.props src/*/*.csproj ./
RUN dotnet restore src/Recyclarr.Cli -a $TARGETARCH
COPY --link . .
RUN dotnet publish src/Recyclarr.Cli -a $TARGETARCH --no-restore -o /app

The runtime stage is the matching .NET runtime image with bash, tzdata, supercronic, git and tini added from Alpine packages, and it carries the standard open container labels. Control reaches tini, which runs an `entrypoint.sh` copied out of `docker/scripts` with mode 555; that script is not among the entries listed at the repository root, where only a `docker` directory appears, so the wrapper logic stays out of view.

USER 1000:1000
VOLUME /config
ENTRYPOINT ["/sbin/tini", "--", "/entrypoint.sh"]

Running as UID 1000 after `/config` and `/data` are chowned to it means a bind-mounted config directory with root-owned files will fail in ways the entrypoint script chooses to handle, and .NET diagnostics are off through `COMPlus_EnableDiagnostics=0`, which removes the usual way of looking inside a running container.

Where installation happens when the README has no command

There is no install command to copy anywhere in the README. Getting the software is delegated to the project's own documentation, which links Installation, a Command Line Reference, a Configuration Reference, a Settings Reference, Troubleshooting and Upgrade Guides, all under recyclarr.dev. The repository's Dockerfile is the only build recipe on display and it targets image builders rather than end users, since nothing in it pushes to a registry. Two root directories hint at where the rest of the documentation and the config format live: `docs` for prose and `schemas` for a machine-readable description of the settings file. Neither is expanded in what the root listing shows, so the shape of a real config file is something you fetch rather than infer. The one practical thing you can plan around is the upgrade path: with the README pointing at dedicated upgrade guides, assume that some versions change how a key is read.

Doing the same edits by hand inside each instance

Each of those five groups has a matching settings page inside Sonarr and Radarr itself, and editing them there is the real alternative to this tool. The gap is not coverage but direction and repetition. Opening every instance and typing values by hand starts from the instance's own state and keeps whatever you have already tuned, whereas Recyclarr starts from the published guide and pushes. One hybrid is spelled out in the feature list, Custom Format scores that come either from the guide or from manual input, which shows the tool can mix both sources in a single run. What neither route offers is a look at pending changes before they land, because the README does not document a dry run and no repository file named at the root introduces one. With two instances and six categories to maintain, that blind spot is the real thing you are weighing, and the guide link is the only reference the README gives you.

Repository tooling and what an upgrade actually costs you

The root of the repository shows how much machinery sits behind a tool whose user-facing surface is a single configuration file. The solution file is `Recyclarr.slnx`, the newer solution format, with build behaviour split across `Directory.Build.props` and `Directory.Build.targets` and package versions centralised in `Directory.Packages.props`. Version numbers come from `GitVersion.yml`, dependency bumps from `renovate.json5`, and commit shape from `commitlint.config.mjs` next to `.pre-commit-config.yaml`. Formatting carries its own ignore files, `.csharpierignore` and `.prettierignore`, plus an `.editorconfig` and a `.yamllint.yml`. Editor and agent directories are committed too, including `.idea`, AGENTS.md and `.opencode`, which fits the README's credit of JetBrains Rider. Alongside those sits `CHANGELOG.md`, and the last push landed on 2026-09-28 with the repository not archived and the code under the MIT licence. Tagged builds in the 8 series moved from v8.7.0 on 2026-07-15 to v8.7.1 on 2026-08-07 and v8.7.2 on 2026-09-03, so patches arrive on their own schedule, and the upgrade surface you actually own is your config file rather than the source tree.

Editorial conclusion

Recyclarr earns its place for anyone already copying TRaSH Guides profiles into several Sonarr and Radarr instances by hand and willing to give a container write access to them. It does not earn one in a single-instance setup you are content to edit yourself, and it cannot help at all below v4. Check three things first: whether every instance you point it at exposes an API key, whether you accept a major version tag that tracks each new 8.x build, and what your existing profiles and custom format scores will be replaced with, because no dry run is documented.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. recyclarr/recyclarr on GitHub
5. Releases