unsubbed.co

Readarr

Readarr is a self-hosted media management & *arr tool with support for *arr, Automation, Books.

Ebook and audiobook automation, honestly reviewed. The headline fact you need to know before reading any further: this project is dead.

TL;DR

  • What it is: A book collection manager and download automator — part of the *arr family (Sonarr, Radarr, Lidarr). It monitored RSS feeds and indexers, grabbed ebooks and audiobooks, sorted them, renamed them, and pushed them to Calibre [GitHub README][3].
  • Current status: Officially retired. The Readarr team announced the project’s end because the metadata provider became unusable and no one stepped up to fix it [readarr.com][GitHub README].
  • Who it was for: Self-hosters who wanted automated ebook/audiobook acquisition the same way Sonarr automates TV shows. Niche but genuinely useful for the right person.
  • Cost: Free, GPL-3.0, self-hosted only. No commercial SaaS tier exists. ElfHosted offers managed hosting at roughly $9–39/month depending on the bundle [1].
  • Key strength (past tense): Clean UI, deep integration with the *arr stack, full Calibre integration, and support for every major download client.
  • Key weakness: It’s retired. The metadata backend is broken. The team has walked away. Third-party workarounds exist but aren’t officially supported.

What is Readarr

Readarr was an ebook and audiobook collection manager built in the same mold as Sonarr (for TV) and Radarr (for movies). You pointed it at your Usenet or BitTorrent indexers, set up quality profiles, and it would automatically find, download, sort, and rename books from your favorite authors. It integrated with Calibre for library management and format conversion, supported import lists from Goodreads and LazyLibrarian, and had a REST API for programmatic access [GitHub README].

The project was part of the Servarr team’s suite — the same people who maintain Sonarr, Radarr, and Lidarr. It ran on Windows, Linux, macOS, Raspberry Pi, and Docker. The UI matched the *arr family’s aesthetic: calendar view, manual search, quality profiles, renaming rules [readarr.com].

Then, at some point in late 2024 or early 2025, the team posted an announcement that now appears on the front page of readarr.com and in the GitHub README:

“We would like to announce that the Readarr project has been retired. This difficult decision was made due to a combination of factors: the project’s metadata has become unusable, we no longer have the time to remake or repair it, and the community effort to transition to using Open Library as the source has stalled without much progress.” [readarr.com]

That announcement is now the homepage. The project sits at 3,447 GitHub stars with no active development. For anything new you’re evaluating in 2026, the retirement is the only fact that really matters. Everything below is historical context and exit guidance.


Why people chose it

For the several years it was actively maintained, Readarr solved a specific problem neatly: the *arr stack was great for video media but there was no equivalent for books. Sonarr won’t manage your ebooks. Radarr doesn’t know what an EPUB is. Readarr filled that gap.

*The arr family integration was the strongest argument. If you already had Sonarr, Radarr, and Lidarr running with Prowlarr as an indexer aggregator, adding Readarr required almost no extra infrastructure knowledge — same Docker patterns, same config paradigm, same download client integrations (SABnzbd, NZBGet, qBittorrent, Deluge, rTorrent, Transmission, uTorrent) [GitHub README][3]. The geek-cookbook Docker recipe [3] treats it as just another line in the AutoPirate stack YAML.

Calibre integration was the other killer feature. Readarr could not only download books but push them directly into Calibre’s library with automatic format conversion. For anyone already using Calibre as their library manager, this was a significant automation win — books went from indexer to Calibre shelf without manual intervention [GitHub README].

Quality profiles worked the same way as other *arr apps: you defined preferred formats (AZW3 over PDF, for instance) and Readarr would upgrade automatically when a better copy became available [GitHub README][readarr.com].

The ElfHosted community [1] also shows that there was enough interest in managed Readarr hosting that a third-party service built it into their platform alongside Audiobookshelf and Calibre-Web — evidence it had real users who didn’t want to manage the infrastructure themselves.


Features

What Readarr shipped before retirement:

Library management:

  • Monitors authors and series for new releases; auto-downloads when they appear [GitHub README]
  • Scans existing library and identifies missing books [GitHub README]
  • Fully configurable renaming rules for files and folders [GitHub README]
  • Calendar view showing upcoming releases [readarr.com]

Download automation:

  • Integrates with every major Usenet and BitTorrent client [GitHub README]
  • Automatic failed-download handling — tries the next release if one fails [GitHub README]
  • Manual search to pick specific releases or diagnose why a release wasn’t grabbed automatically [GitHub README]
  • Prowlarr/Jackett compatible for indexer aggregation [3]

Calibre integration:

  • Pushes downloaded books directly into Calibre library [GitHub README]
  • Triggers format conversion via Calibre Content Server [GitHub README]

Import and discovery:

  • Import lists from Goodreads and LazyLibrarian [readarr.com]
  • RSS monitoring for new author releases [GitHub README]

Technical:

  • REST API [GitHub README, merged profile]
  • Docker-first deployment, also native Windows/Linux/macOS/Raspberry Pi [readarr.com]
  • Cross-platform .NET-based, same runtime as the rest of the *arr family [GitHub README]

The thing it couldn’t do: handle ebooks and audiobooks in the same instance. If you wanted both formats of a title, you needed two separate Readarr instances — one for ebooks, one for audiobooks. ElfHosted explicitly offers separate ebook and audiobook versions for this reason [1].


Pricing: SaaS vs self-hosted math

There is no SaaS version of Readarr. The software is GPL-3.0, self-hosted only.

Self-hosting (community edition):

  • Software: $0 [GitHub README]
  • VPS to run it on: $5–10/month (a $6 Hetzner VPS is enough for a single-user *arr stack)
  • Existing infrastructure: if you already run Sonarr/Radarr, Readarr adds negligible overhead — it uses the same download clients and indexers

Managed hosting via ElfHosted: ElfHosted [1] offers Readarr as part of their self-hosted app platform. They offer a 7-day trial. Their pricing model bundles apps into plans ($9–$39/month range for full *arr stacks). This is a third-party service with no affiliation to the Readarr team — worth noting since the Readarr team can’t vouch for it or provide support for ElfHosted-specific configurations [1].

The honest math in 2026: Since Readarr is retired, the self-hosting cost calculation is moot for new deployments. The relevant question is whether you want to maintain a dead project on your server, possibly relying on the rreading-glasses metadata mirror that the Readarr team explicitly says they cannot support [readarr.com]. There is no SaaS equivalent to compare against because the ebook automation niche is thin — Calibre-Web and Audiobookshelf handle library access, but neither does the download automation Readarr did.


Deployment reality check

When Readarr was active, deployment was straightforward for anyone in the *arr ecosystem. The Geek Cookbook [3] documented it as a standard Docker Compose addition to the AutoPirate stack:

readarr:
  image: lscr.io/linuxserver/readarr:latest
  env_file: /var/data/config/autopirate/readarr.env
  volumes:
    - /var/data/autopirate/readarr:/config
    - /var/data/media/books:/books

Port 8787, same reverse proxy setup as the rest of the family [3].

What can go wrong in 2026:

  • The metadata problem. This is what killed Readarr. Without working metadata, the app can’t reliably identify books, match downloads to authors, or populate your library correctly. The official team says the metadata “has become unusable” [readarr.com]. The community mirror rreading-glasses (https://github.com/blampe/rreading-glasses) is the workaround, but the Readarr team explicitly says they can’t support it and you use it at your own risk.
  • No upstream bug fixes. Any bugs you hit are yours to solve. The GitHub issues will accumulate without resolution.
  • linuxserver.io image maintenance. Third-party Docker image maintainers like linuxserver.io may continue publishing images for some time, but with no upstream development, there’s no guarantee of security updates or compatibility fixes.

Realistic deployment time for an existing *arr user: under an hour for the container setup. Budget additional time for the metadata mirror configuration — that’s not documented in any official guide.


Pros and Cons

Pros

  • *Best arr-native ebook automation that existed. If you’re deep in the Servarr stack, the integration was seamless — same download clients, same indexers, same UI paradigm [3][GitHub README].
  • Full Calibre integration. Pushed directly to Calibre library with format conversion. Nothing else in the ecosystem did this automatically [GitHub README].
  • GPL-3.0 licensed. The code is fully open and forkable. If someone takes over, the codebase is available [GitHub README].
  • REST API. Programmatic control, consistent with the rest of the *arr family [merged profile].
  • Works for existing users who have the metadata situation resolved — the software itself functions fine if you’ve found a working metadata source.

Cons

  • Project is officially retired. Not “maintenance mode,” not “slow development” — retired. The team has left. [readarr.com]
  • Metadata is broken. The core function — identifying books — doesn’t work with the default setup anymore [readarr.com].
  • No official support. The Servarr team explicitly points you to alternatives [readarr.com].
  • Third-party metadata mirror risks. rreading-glasses works for some users but has no official backing. If it goes down, you’re stuck again.
  • Still in beta at time of retirement. The README explicitly labeled it “generally still in a work in progress” with features that “may be broken, incomplete, or cause spontaneous combustion” [GitHub README]. It never shipped a stable 1.0.
  • Single-format limitation. One instance handles either ebooks or audiobooks, not both. Two instances required for both formats [1].
  • Documentation is stale. The wiki still exists but won’t be updated. Guides online assume a working metadata backend.

Who should use this / who shouldn’t

Stick with Readarr if:

  • You’re already running it, have the metadata situation resolved, and it’s working.
  • You understand you’re running abandoned software and accept the maintenance burden.
  • You have the technical ability to work with rreading-glasses or another community metadata fork without official support.

Don’t deploy Readarr fresh if:

  • You’re setting up a new book management stack in 2026. Start with an actively maintained alternative.
  • You want something that will receive security updates and bug fixes.
  • You’re a non-technical founder looking for reliable infrastructure — abandoned projects are exactly the wrong foundation for anything you depend on.

The broader audience for Readarr-style automation no longer has a great answer. The *arr ecosystem has a real gap here that hasn’t been filled by an equivalent maintained project.


Alternatives worth considering

Given Readarr’s retirement, your real options depend on what specifically you needed it for:

For ebook library management (without automation):

  • Calibre — the definitive ebook library manager. Desktop-first but powerful. Calibre-Web wraps it in a browser UI accessible from any device. No download automation, but rock-solid library management [GitHub README].
  • Kavita — actively maintained, clean reader UI for ebooks and manga, good library management. No download automation.
  • Calibre-Web — web interface over Calibre’s database, multi-user, OPDS support. Popular and well-maintained.

For audiobook management:

  • Audiobookshelf — the current community favorite for audiobook servers. Active development, iOS/Android apps, per-user progress sync, multi-user support [2]. This is where the energy has moved.
  • Booksonic — older, Subsonic-compatible audiobook streaming server.

For ebook automation (Readarr-replacement attempts):

  • LazyLibrarian — older project, still technically active, overlapping scope. Less polished than Readarr was. Worth evaluating if you need automation and can’t live without it.
  • rreading-glasses (https://github.com/blampe/rreading-glasses) — not a Readarr replacement per se, but the metadata mirror that keeps existing Readarr installs semi-functional. The Readarr team flags it as the most popular workaround [readarr.com].

*If you’re already deep in the arr stack:

  • The Servarr team still actively maintains Sonarr, Radarr, Lidarr, and Prowlarr. Book automation is the gap. Watch the Servarr forums and Discord for any community fork that gains traction — the README leaves the door open for someone to take over [readarr.com].

Bottom line

Readarr was genuinely good at a specific thing: making ebook and audiobook acquisition as automated as Sonarr makes TV. For *arr-stack users, the integration was seamless and Calibre support was a real convenience win. But the project retired before it ever left beta, killed by a broken metadata backend and no one to fix it. In 2026, deploying Readarr fresh means betting your book management stack on abandoned software with a third-party metadata workaround that the original team explicitly can’t endorse. If you’re already running it and it’s working, carry on. If you’re starting fresh, build around Audiobookshelf for audio and Calibre-Web or Kavita for ebooks — both are actively maintained, and both avoid the metadata lottery that ended Readarr.


Sources

  1. ElfHosted — Hosted Readarr documentation. https://docs.elfhosted.com/app/readarr/
  2. BookRunch — audiobookshelf alternatives: Top 10 eBook Organizers. https://www.bookrunch.com/alternatives/audiobookshelf/
  3. Funky Penguin’s Geek Cookbook — Run Readarr in Docker. https://geek-cookbook.funkypenguin.co.nz/recipes/autopirate/readarr/

Primary sources:

Features

Integrations & APIs

  • REST API