Bindery on a Seedbox: The Readarr Replacement, and the One Path You Have to Set

Readarr is dead, Bindery is what replaced it

The Readarr repository went to public archive on 27 June 2025. The maintainers were blunt about why: the project's metadata had become unusable, and the community effort to move to Open Library stalled. An old Readarr install still runs and still grabs whatever your indexers hand back, but author search is the whole point of the app and author search is what broke.

Bindery is a clean-room rewrite in Go with a React interface, MIT licensed, and it fixed the thing that killed Readarr by not depending on one metadata service. It reads from six: Open Library as the primary, then Google Books, Hardcover, the German National Library, Audnex and Audible. Six sources that can each fail without taking the app with them is the entire design argument, and it is a good one.

It does what you remember Readarr doing. You add an author or a book, it watches your indexers, it hands a grab to your download client, and when the download finishes it renames and files the result into your library. Both ebooks and audiobooks, and here is the part worth knowing before you start: a title in Bindery holds an ebook slot and an audiobook slot independently, with separate searching, grabbing and importing for each. One author, two formats, two pipelines.

Set your root folders before you monitor anything

This is the one thing that will bite you, so it goes first.

Bindery takes its library root from an environment variable at first start. Upstream the default is /books. On an appbox we point it somewhere else:

Inside Bindery	On your box	Access
/media	~/media	Read-write
/downloads	~/downloads	Read-write
/flexdisk	Your FlexDisk, if you have one	Read-write
/config	~/.config/bindery	Read-write

The library root is /media, which is your whole media folder, not a books subfolder inside it. That is deliberate, because it means you can put books anywhere under ~/media without asking support for another mount. It also means that if you monitor an author and never touch the settings, Bindery will file that author's folder straight into ~/media, next to Movies and TV Shows and whatever else Sonarr and Radarr have built there.

The second half is the audiobook root. Upstream, BINDERY_AUDIOBOOK_DIR defaults to inheriting the library root, and our install does not set it. So out of the box your ebooks and your audiobooks both land in the same place, which for a library with any volume in it is not what you want. Audiobookshelf wants a folder of its own to scan.

So the first thing to do after you sign in:

1. Open Settings, then Root Folders.
2. Add /media/books as the ebook root.
3. Add /media/audiobooks as the audiobook root, or whatever you already point Audiobookshelf at.
4. If you have a FlexDisk, add /flexdisk as a root too. It is mounted read-write for exactly this.

Two minutes, and it is the difference between a tidy library and 400 author folders in the root of your media tree.

Signing in

Your login is already made. When the panel installs Bindery it calls Bindery's own first-run setup endpoint and creates the admin for you, using your slice username and a generated password. The password is on the app's page in the panel.

So the username is your slice login, not an email address. That trips people coming from Komga, which does use an email. Bindery stores the password with argon2id and hands you a signed session cookie, and the app is at https://bindery.USERNAME.SERVER.bysh.me.

You can switch the authentication mode later if you have a reason to. Bindery supports four: normal accounts, local-only with private IPs bypassed, off entirely, and trusting an upstream proxy header. It also speaks OIDC and has its own API keys. On a shared box, leave it on normal accounts. The app is on a public hostname and local-only or disabled means anyone who finds the URL owns your library.

Wiring it to a download client

Bindery handles both halves of the usual argument. Usenet first, since that is where the project started, but torrents work the same way.

It supports SABnzbd, NZBGet, qBittorrent, Transmission, Deluge and rTorrent or ruTorrent over XML-RPC. Five of those six are one-click apps here, so in most cases the client you want is already running:

• SABnzbd or NZBGet for Usenet. See the Usenet guide for which to pick, and the SABnzbd setup if you are starting from nothing.
• qBittorrent, Deluge or rTorrent for torrents. The client comparison covers the trade-offs.

Indexers go in the same way they do everywhere else in this stack: point Bindery at Prowlarr and let Prowlarr own the indexer list. If you have not set that up, the Prowlarr guide is the short version, and it saves you re-entering credentials in every app that wants them.

The download folder needs no thought. Bindery watches /downloads, which is ~/downloads, which is where every download client on the box already drops finished jobs. That part is wired for you.

Bindery's quality profiles cover the formats you would expect, EPUB, MOBI, AZW3, PDF, AZW, DJVU, CBR, CBZ, FB2, LIT, RTF and TXT, plus M4B, M4A, FLAC, MP3 and OGG for audio. It also has language filters, regex custom formats, delay profiles and a blocklist. If you spent time on Readarr profiles, this will feel familiar.

Coming from Readarr

Bindery has an import command, bindery migrate readarr /path/to/readarr.db, which carries over your indexers, your download clients and your blocklist. Authors get re-resolved against Open Library rather than copied, which is the point of moving.

On a managed box that command is not practical. Our Bindery image is distroless, which means there is no shell inside it. That is why the panel provisions your admin account over HTTP instead of running a command in the container, and it is why there is no console for you to type a migrate command into either.

What you do instead takes about ten minutes and is honestly cleaner:

• Add your download client. One form.
• Point it at Prowlarr, or add indexers by hand if you do not run Prowlarr.
• Set your two root folders as above.
• Add the authors you actually still follow.

That last one is worth doing deliberately. A Readarr database that has been running since 2023 is carrying a lot of authors you added once and forgot. Starting the list again is not a loss.

Leave your old Readarr installed while you do it if you like. The two apps run on separate ports and separate config directories and will not fight. Just do not have both monitoring the same author with the same download client, or you will grab everything twice.

Where Bindery sits next to the other book apps

We ship more book apps than anybody needs, which is useful if you know what each one is for and confusing if you do not. The split is simple: one app gets the files, another app lets you read them.

App	What it does	Writes to your library?
Bindery	Finds and files ebooks and audiobooks	Yes
Audiobookshelf	Plays audiobooks and podcasts, syncs progress	Yes
Komga	Reads comics and ebooks in a browser	No, mounted read-only
Ubooquity	Serves comics and ebooks over OPDS	No
Calibre	Manages and converts an ebook collection	Yes

Bindery is the grabber. It is the only one in that list whose job is to go out and get things, which is also why it is the only one that needs write access to a root folder you have chosen on purpose.

That read-write access is worth a sentence, because it is the opposite of how we run the readers. Komga is mounted read-only and cannot touch a byte of your library, which is right for an app whose job is reading. Bindery is mounted read-write and runs as your own user inside the container, because an app whose job is organising books into folders has to be able to make folders. Same box, opposite decisions, and both are correct.

For audiobooks the pairing is Bindery plus Audiobookshelf: Bindery files the M4Bs into your audiobook root, Audiobookshelf scans that root and handles playback and progress sync across your phone and your browser. Give them the same folder and they need no further introduction.

And if you are still reading the Readarr guide and wondering whether to install it: don't. That guide now opens with the retirement notice for a reason.

What it costs to run

Bindery is a static Go binary with a SQLite database. It is one of the cheapest apps in the catalogue to leave running, and the storage question is about the books, not the app.

Ebooks barely register. A few thousand EPUBs is a couple of gigabytes. Audiobooks are the ones that eat disk: a single unabridged M4B runs 200 MB to 1 GB depending on the bitrate, so a serious audiobook library is measured in hundreds of gigabytes the same way a film library is.

Appbox Lite is EUR 5 for 500 GB, which is plenty for ebooks and a starter audiobook shelf. 1 TB is EUR 11 and 3 TB is EUR 14, all with unmetered traffic on a 10 Gbit port. If books are a second library sitting alongside your films, you are probably sizing for the films anyway and Bindery comes along for free.

The short version

• Readarr was archived in June 2025 because its metadata source died. Bindery reads from six sources instead of one.
• Set your root folders first. The library root starts as your whole ~/media, and audiobooks inherit it, so make /media/books and /media/audiobooks before you monitor an author.
• Sign in with your slice username, not an email. The password is in the panel.
• Five of the six download clients it supports are already one-click here. Let Prowlarr own your indexers.
• The Readarr database import needs a shell the image does not have. Re-adding your clients and authors by hand takes ten minutes and gives you a shorter list.
• Pair it with Audiobookshelf for listening and Komga for reading. Bindery is the one that fetches.