managarr: a terminal client for Radarr, Sonarr, Lidarr and Readarr

One terminal client for the *arr services on a home theatre PC

Managarr is a TUI and a CLI for managing what the README calls your Servarrs, aimed at the home theatre PC crowd. The stated purpose is helping you manage an HTPC, and the services it targets are Radarr, Sonarr, Lidarr and Readarr. The interface is a terminal user interface built on ratatui, with a matching command line built on clap, and the two are treated as first class rather than a TUI with a thin command wrapper.

The scope visible in the README's feature tables is a read and inspection surface. For Radarr, both the TUI and CLI columns are marked as supporting views of your library, downloads, collections and blocklist, plus details of a specific movie including description, history, downloaded file information and credits, and details of any collection. The screenshots directory includes a Lidarr library view, which shows the kind of screen this is.

That framing matters for expectations. This is a dashboard for looking at what your services are doing, not a replacement for the web interfaces those services already expose. Anyone expecting to configure queues, or to drive every endpoint a Servarr API offers, will find the documented surface much narrower than the underlying API.

Readarr works through forks, and the README says so

One entry in the supported list carries an explicit warning. The official Readarr repository has been archived, and the note states that Managarr's Readarr support is compatible with any Readarr forks that maintain compatibility with the official Readarr v1 API.

That is a real constraint rather than a footnote, because it changes what you have to check before configuring the client. The API version is the contract. A fork that has moved past v1, or that has changed endpoints in other ways while keeping the name, will not behave as documented here. The README points to a Tested Readarr Forks section that lists forks explicitly tested with Managarr and notes oddities in configuring them.

Prowlarr, Whisparr, Bazarr and Tautulli appear in the same list with empty checkboxes, which the README's own key marks as not yet done. So the coverage picture is four services working and four outstanding. A user whose setup depends on Prowlarr as the indexer front end will find Managarr useful for the other services and blind to the one that finds the releases.

Five install paths, and the config file has to exist first

The installation section is thorough, which is a good sign for a tool people install on several machines. If you have Cargo, the crate is on Crates.io:

cargo install managarr

# If you encounter issues installing, try installing with '--locked'
cargo install --locked managarr

On macOS and Linux, Homebrew works through a tap:

brew tap Dark-Alex-17/managarr
brew install managarr

Nix users are covered by an externally maintained package, and Windows users by a Chocolatey package, which the README warns can lag a new release because package validation takes time. That warning is worth taking seriously, since it is the kind of detail that turns into a support question later. Prebuilt binaries are also published on the releases page for macOS on x86_64 and arm64, for Linux on x86_64, armv6, armv7 and aarch64, and for Windows on x86_64 and aarch64.

Docker is the fifth route, and it has the sharpest requirement. You mount your config.yml to /root/.config/managarr/config.yml inside the container:

docker run --rm -it -v /home/aclarke/.config/managarr/config.yml:/root/.config/managarr/config.yml darkalex17/managarr:latest

The README states plainly that you must create and populate the configuration file first, otherwise the container fails to start. It also warns that relative paths in the volume mount can produce errors, in which case an absolute path fixes it.

The Dockerfile ships a static binary on a slim Debian base

The container image is built in two stages. The builder uses rust:1.95, creates a throwaway binary project to cache the dependency compilation as its own layer, copies Cargo.* and the proc_macros directory in, builds once, then removes the temporary source and the previously built managarr artifacts before copying the real src directory across. A second build with cargo build --release --bin managarr and cache mounts for the target directory and the cargo registry produces the binary, which is then moved to the top of the tree.

The runtime stage is debian:stable-slim with ca-certificates installed, and the compiled binary is copied in as an unprivileged nonroot user with ENTRYPOINT pointing at /usr/local/bin/managarr. The effect is a small image with no shell tooling beyond the base system, and a container whose only job is to run the client.

Two details tell you what to expect locally. The builder pins rust:1.95, which lines up with the rust-version of 1.95.0 declared in Cargo.toml, and the crate uses the 2024 edition. The README also mentions a just build-docker recipe for building the image from a clone, and the justfile in the repository root defines the build, test and style recipes that back that workflow.

ratatui, clap, tokio and reqwest behind the two interfaces

The dependency list describes the architecture fairly well. ratatui at version 0.30 with the all-widgets and unstable-widget-ref features provides the terminal rendering, and crossterm 0.28 handles the low-level terminal events. clap 4.5 with derive, cargo, env and wrap_help features drives the command line, and clap_complete is included, so shell completion generation is part of the build rather than an afterthought. The external widget crate managarr-tree-widget at version 0.25.0 supplies tree views, which fits a service whose library is naturally hierarchical.

Networking is reqwest 0.13.2 with the json feature, and the runtime is tokio with the full feature set, so the HTTP calls to the Servarr APIs are asynchronous underneath both interfaces. Configuration comes from confy with the yaml_conf feature, paired with serde_yaml, which is where the config.yml file comes from. Logging uses log with log4rs configured for rolling files, human-panic is included for readable crash output, and ctrlc handles interrupt handling.

The workspace also contains two procedural macro crates, enum_display_style_derive and validate_theme_derive, the latter pointing at the themes/ directory of theme definitions. The feature tables list the same capabilities under TUI and CLI columns for the supported services, and where a service has no CLI coverage the checkbox stays empty, so the two surfaces are genuinely kept in step.

The CLI and the TUI cover different amounts of ground

The most useful comparison available is inside the project itself, because Managarr ships two interfaces over the same backend. The TUI is the point of the project for interactive work: a browsable, keyboard-driven view of a library, with the library screenshot showing a table of titles that you page through and select. It suits the moment you sit down at the HTPC and want to see what arrived overnight.

The CLI is the alternative approach for everything else. It covers the same documented operations in the supported services, but exposes them as arguments and output that a script can consume, which is what you want when you are checking state from cron, from a shell history, or from a remote session over SSH rather than sitting at the machine. Nothing in the documented feature table shows a CLI entry that the TUI lacks, and the table marks gaps on the CLI side where they exist, so the two surfaces are maintained deliberately rather than one trailing the other.

That duality is the design decision that makes Managarr usable in more than one place. The cost is that both interfaces have to be kept current as the services change, and the README's own feature tables are where you would look to see whether a specific task is covered by the command line yet.

Rapid releases, a custom licence file and a wide test matrix

Maintenance activity is easy to read from the release list. Version 0.8.2 was published on 2026-10-14, v0.8.1 on 2026-10-12 and v0.8.0 on 2026-09-30, and the last push was on 2026-10-14. The crate version in Cargo.toml matches the newest release at 0.8.2, and the repository is not archived. That cadence means new versions arrive often, which is convenient for bug fixes and means your install should be pinned deliberately.

The licence is worth reading carefully. Cargo.toml declares license = "MIT", and the README badge says MIT, but the licence file at the root is a custom licence that GitHub cannot classify on its own. What that means for redistribution depends on the wording in that file, so anyone shipping Managarr inside another product should read it rather than rely on the MIT string in the manifest. This is a note about the licence text, not legal advice.

Quality tooling is unusually thorough for a project of this size. The justfile exposes cargo fmt --all, cargo clippy --all, cargo fix, and an unsafe-code analysis recipe that installs and runs cargo geiger. Tests come in several flavours: cargo test --all for the suite, a tarpaulin recipe for coverage, doc tests, a property test recipe, and snapshot tests driven by cargo insta with a review step for accepting changes and a recipe that deletes unreferenced snapshots. A codecov configuration and a proptest-regressions directory at the root support that story, and the README carries badges for the check and test workflows.

Editorial conclusion

Managarr fits someone running one or more Servarr services on a home theatre PC who wants them in a terminal and prefers a scripted CLI for routine checks. It does not fit a setup that needs Prowlarr, Whisparr, Bazarr or Tautulli, or a team that needs a stable documented API, because the version moves quickly and the licence file is custom rather than the MIT string in Cargo.toml. Before adopting, run the demo command with no configuration present, then check that your Readarr fork speaks the v1 API, since that compatibility is the assumption the project makes explicit.

Frequently asked questions

Official sources

1. Dark-Alex-17/managarr on GitHub
2. Issues
3. README
4. Releases