Unpackerr for Radarr and Sonarr Archive Extraction

Unpackerr's place in a Radarr download pipeline

Unpackerr solves a narrow but disruptive gap between a completed download and the media application's import stage. Radarr, Sonarr, Lidarr, and Readarr may receive a torrent whose payload is still inside a RAR, ZIP, 7z, disc image, or another supported container. The linked application can see the download but cannot import the desired file until the archive has been expanded. Unpackerr runs as a daemon on the download host or seedbox, checks completed downloads, extracts their contents, and then lets the relevant application import them.

The target user is therefore an operator of a download and media automation stack, not someone looking for a replacement torrent client. Unpackerr is also suitable for users who do not run any of the listed applications. In standalone mode, it can watch a download folder and extract files found there. The README specifically frames the daemon as a solution for RAR files that remain stuck in an application's activity queue.

This separation has an operational consequence. Unpackerr needs access to the same completed files as the download host and must be configured to work with the appropriate application or watch folder. A successful download does not by itself prove that Unpackerr can see its files or that the resulting directory layout will match the application's expectations.

Recursive archive handling and extraction pipeline

Unpackerr's central mechanism is archive extraction after a download reaches a completed state. The README says that extraction is recursive, including archives located inside folders and archives nested inside other archives. The documented formats include TAR, RAR, ZIP, 7-Zip, Gzip, tarred Gzip, Bzip2, ISO, and UDF disc images. Encrypted RAR and 7z files are also listed as supported, which is relevant for private tracker and seedbox workflows where password-protected downloads are common.

The repository reinforces that this is extraction rather than a general media-management service. Its Go module depends on `github.com/golift/xtractr`, along with libraries for ISO parsing, 7-Zip handling, compression, FLAC, APE, Brotli, CPIO, RPM, XZ, and related formats. The repository also includes frontend, configuration, initialization, and example files, indicating a packaged daemon with a user interface and configuration model rather than a one-off script.

Unpackerr can split FLAC or APE files associated with a cue sheet and can optionally convert APE files to FLAC. These are specialized audio operations, but they show that its intended scope includes payloads that need more than a single directory-level unzip operation. The README links to a longer format list maintained in an issue, so the short list should not be treated as a complete compatibility guarantee.

Installing Unpackerr through the documented project paths

The README directs users to `https://unpackerr.zip` for installation instructions. The repository also exposes a development build through the `Makefile` and a container build through the `Dockerfile`. The commands below are repository commands, not a claim that they constitute every production deployment method.

For a local development build, `make dev` runs the Go program with the Makefile's development defaults. It uses `UN_WEBSERVER_LISTEN_ADDR="127.0.0.1:5656"` and `UN_WEBSERVER_UI_PASSWORD="admin:supersecret123"` when those variables are not overridden. Change the development password before exposing that interface outside the local machine.

make dev

The command starts Unpackerr from the repository. The daemon listens on the configured address and port, and the project exposes port `5656` in its Dockerfile. The README does not document a separate first-run command for adding Radarr, Sonarr, or a watch folder, so application connections and watched paths must be configured using the installation documentation or configuration files rather than guessed from the examples.

A container image can be built from the repository's `Dockerfile` with the Makefile target. The target passes build metadata and tags the result as `unpackerr:dev` by default.

make docker

The resulting local image contains the compiled `/unpackerr` binary and starts through the Dockerfile's `ENTRYPOINT`. The repository includes `examples/docker-compose.yml`, `examples/unpackerr.conf.example`, and `examples/nginx.conf.example`, but the README does not explain their contents, so they should not be treated as a complete, copy-and-run deployment recipe.

Standalone watch-folder operation for non-starr users

Unpackerr can operate without Radarr, Sonarr, Lidarr, or Readarr. In that arrangement, the operator configures the daemon to watch a folder containing downloads. The README describes the behavior plainly: it watches the download folder and extracts files downloaded there. This is the most direct deployment for a user who needs extraction but does not want to connect the daemon to a media automation application.

The watch-folder model introduces responsibility for filesystem permissions and folder placement. The daemon must be able to observe files in the selected directory, create the extracted output, and handle any credentials or formats required by the archive. If the download client writes into a directory that is mounted differently inside a container, Unpackerr will not automatically reconcile that mismatch. The README does not document the exact configuration keys or retry behavior, so those details must be checked in the project's installation documentation before deployment.

The description also states that Unpackerr deletes extracted files after import. That behavior is useful for avoiding duplicate imports and reclaiming intermediate archive contents, but it deserves deliberate review. Operators should confirm that the daemon can distinguish source archives from extracted media and that a failed or unwanted extraction will not remove data that the download client still expects.

What Unpackerr does not solve

Unpackerr is not a replacement for a download client. The repository description lists integrations and topics associated with Deluge, qBittorrent, Transmission, Radarr, Sonarr, Lidarr, and Readarr, but the documented function is extraction after downloads are completed. It does not provide a documented torrent-search interface, tracker management layer, or replacement for the media application's decision about what to import.

It is also not a general-purpose archive conversion utility with an independently documented command-line interface. The README emphasizes daemon operation, automatic watching, and integration with media applications. Users who only need a one-time local extraction command may find that a conventional archive tool is a better fit, particularly if they do not want to operate a long-running service or configure filesystem monitoring.

Archive support also has boundaries. The README lists supported formats and links to an external issue for more details, but it does not provide a promise that every password, damaged archive, codec, or nested layout will succeed. Encrypted RAR and 7z support does not mean that credentials are inferred automatically. The daemon's permissions, operating-system support, and download-host access must be aligned with the specific archive being processed.

Build, release, and maintenance considerations

The repository is not archived, and its last push was on 2026-10-15. That status supports treating the project as receiving recent repository activity, but it does not by itself guarantee compatibility with every download client or archive workflow. The release history includes `v0.16.1` on 2026-08-31, `v0.16.0` on 2026-08-30, and `v0.15.2` on 2026-03-08. Upgrade planning should therefore account for both release changes and changes in the bundled extraction dependency, `github.com/golift/xtractr`.

The Dockerfile describes a multi-stage source build. It downloads Go modules, installs frontend dependencies with `npm ci --prefix frontend`, runs `go generate ./...`, builds the Go binary with `CGO_ENABLED=0`, and copies the result into an Alpine image containing `ca-certificates`, `openssl`, `tzdata`, `curl`, and `jq`. This is useful context for image size and operational dependencies, but the README does not state resource requirements or hardware limits.

The project uses the MIT license. That identifier permits use and modification under the license's conditions, including preservation of its notices where required. This is a license summary, not legal advice. Review the repository `LICENSE` file and linked license documentation before redistributing a modified image or embedding Unpackerr in a commercial deployment.

Editorial conclusion

Adopt Unpackerr when completed downloads must be unpacked before Radarr, Sonarr, Lidarr, or Readarr can import them, including deployments built around a watch folder. Do not choose it as a general download client or assume that every archive failure can be resolved automatically. Verify first that the required extraction tools, download-host paths, application credentials, and deletion behavior fit your deployment.

Frequently asked questions

Official sources

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