Bindery is a Go rewrite of Readarr that survives its metadata sources dying

Why the predecessor went away

The README opens with the reason, and it is not a feature list: you probably got here because Readarr died. The official project was archived in June 2025 when its metadata backend, api.bookinfo.club, went permanently offline, and one dead endpoint took the whole app down.

That is the failure mode this project is designed around, and the design response is stated as a property rather than a feature: no single point of failure for metadata.

OpenLibrary leads, with Google Books, Hardcover, DNB, Audnex and Audible behind it, and Nasjonalbiblioteket and the BnF available as opt-in primaries for Norwegian and French libraries. The README is emphatic that these are all documented public APIs with zero scraping, and that if one source degrades the others carry the library.

The scraping point is the second lesson. The community forks that followed Readarr lean on Goodreads scrapers that break whenever the site changes its HTML, so their failure mode is not a provider going offline but a provider changing its markup. Both problems produce a broken app, and the second one is arguably worse because it recurs.

So the design bet is that a book manager should treat its metadata sources as replaceable and use published APIs rather than scraped pages. That is a narrower promise than Readarr made, since a scraped site can carry fields no public API exposes, but it is one that holds when the source changes.

The project is Go, MIT licensed, described as a clean-room Go rewrite with a modern React UI, and the tagline is that it is built to outlive its metadata sources. The releases are v1.44.0 from 2026-10-19, v1.43.1 from 2026-10-18 and v1.43.0 from 2026-10-16, with the last push on 2026-10-20.

What the interface actually shows

The screenshots in the README describe the shape of the application, and it is the familiar one from the Readarr and Sonarr family.

There is a tour through authors, books, the release calendar and the download queue. The author detail page has monitored books, the authors overview has monitoring badges, the books library has a grid view, the release calendar shows upcoming books, and the download queue has live status.

So the workflow is the standard acquisition loop. You monitor an author, new books appear as they are announced, you decide which to grab, the indexer search runs, the download client fetches it, and the file is organised into your library when it completes.

The library side is worth separating out, because it is where the app differs from a downloader. The comparison table records that Bindery handles ebooks and audiobooks with separate roots and narrator metadata, which means the same application manages two different content shapes rather than treating an audiobook as an ebook with a different extension. Audiobooks have narrators, and the metadata for them comes from a different place.

The interface is described as mobile-friendly, with separate light and dark screenshots for the books, authors and author detail pages, and the repository topics include i18n and multilingual, so the application is not English-only.

Other topics in the repository give the deployment picture: docker, helm, homelab, self-hosted, sqlite, calibre and opds. The OPDS mention matters because that is the catalogue protocol the library can serve downstream, which is how the Calibre-Web and Audiobookshelf pairing in the comparison table works, with those tools serving the already-curated library while Bindery curates it.

Bringing a dead Readarr install with you

This is the migration path, and it is the most concrete thing the project offers.

The README asks you to keep your library and point Bindery at the old database:

> bindery migrate readarr /path/to/readarr.db

Authors are resolved again against your primary metadata provider and its fallbacks, because Readarr's bookinfo.club backend is gone, while indexers, download clients and the blocklist port across. There is a preference for the user interface, Settings then Import, and a full guide at `docs/Migrating-From-Readarr-Wiki.md`.

Two things are happening under the hood. The authors are not copied as stale records, they are looked up again against the new provider set, so you get current metadata rather than a frozen record of what Readarr knew in 2025. And the configuration objects, the indexers, the download clients and the blocklist, are carried over as they were, so you do not have to re-enter a list of news server credentials and indexer URLs by hand.

The blocklist is worth a sentence of its own, because it is the part of the configuration most people forget about. It holds the releases you do not want, usually ones you already have in another format, so without it a migration would re-download books you own.

The comparison table records this as a differentiator: the Readarr .db import is a yes for Bindery and a no for LazyLibrarian and Livrarr.

One binary, SQLite, and no sidecars

The README calls the operational model boring by design, and the list is specific: a single Go binary with the UI embedded, SQLite, no external database, no sidecars, no nginx.

That is a deliberate departure from the Readarr generation, which was a .NET application with a separate database server and typically a reverse proxy in front. Here the binary contains the web server and the built React assets, and the only state is a SQLite file.

The Go module tells you how the pieces are built. The router is `github.com/go-chi/chi/v5`, the database driver is `modernc.org/sqlite` at v1.60.1, which is the pure Go SQLite implementation rather than a cgo binding, and that is what makes a static binary possible. Scheduling uses `github.com/robfig/cron/v3`, metrics come from the Prometheus client library, and there is `golang.org/x/text` for the internationalisation and `github.com/dhowden/tag` for tag handling. Authentication brings in `golang.org/x/oauth2` and `github.com/coreos/go-oidc/v3`.

The deployment options are extensive for a small application. There is a distroless container image published to both the GitHub Container Registry and Docker Hub, a Helm chart in the `charts/` directory, ArgoCD configuration in `argocd/`, a `deploy/` directory, and ARM builds down to a Pi Zero on armv6, which is a rare and deliberate target.

The repository also carries the security tooling that a project handling search terms and download client credentials should have: a `.gitleaks.toml` and `.gitleaksignore` for secret scanning, a `.semgrep.yml` for static analysis, an `osv-scanner.toml` for dependency vulnerabilities, a `SECURITY.md`, a `PRIVACY.md` and a `THIRD_PARTY_LICENSES.md`. There is also a `DCO`, so contributions are signed off rather than copyrighted, and a `changelog.d/` directory, which is the keep-a-changelog pattern for pending release notes.

The container build, pinned by digest

The Dockerfile is a good example of a supply-chain-conscious build, and the comments explain the choices.

The base images are digest-pinned rather than tag-pinned, and the comment at the top says this is for supply-chain integrity, with Dependabot keeping tags and digests in sync on a weekly cadence.

There are three stages. The first builds the frontend on the builder's native architecture, with a comment explaining that the output is architecture-agnostic JavaScript. The second builds the Go binary, again on the builder's platform and then cross-compiling to the target:

FROM --platform=$BUILDPLATFORM golang:1.26.9-alpine@sha256:cdfd4fe2da6b225d8b40c6b7a105736e548e83ff56d5d8f9394446eeb5eb84e0 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
COPY --from=frontend /app/web/dist ./internal/webui/dist
ARG TARGETOS
ARG TARGETARCH
ARG VERSION=dev
ARG COMMIT=unknown
ARG BUILD_DATE=unknown
RUN CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build \
    -ldflags="-w -s -X main.version=${VERSION} -X main.commit=${COMMIT} -X main.date=${BUILD_DATE}" \
    -o /bindery ./cmd/bindery

CGO is disabled, which is what allows the pure Go SQLite driver to work and the runtime image to be distroless. The version, commit and build date are stamped into the binary with linker flags, so a running container can report exactly which build it is.

The frontend stage has a detail that is worth reading twice. The web test suite asserts its Unicode fold against the same fixture the Go test uses, with the comment explaining that one corpus means the key written into the database and the fold applied to the query cannot drift apart, and that `npm run build` type-checks the tests too, so the fixture has to exist even though nothing at runtime reads it.

That is about search normalisation. A search index that folds case and accents has to fold the same way when writing the key and when querying, or results go missing for exactly the users with accented names, which is why a shared fixture is copied into the frontend build stage from `internal/textutil/testdata/`.

The runtime stage is `gcr.io/distroless/static-debian13:nonroot`, with OCI image metadata added so that registries and `docker inspect` surface the MIT licence and the source, matching the repository's LICENSE file.

How it compares, and where it fits

The README includes a comparison table with other tools, and the differences are about architecture rather than features.

Bindery is Go, a single binary, with six independent metadata sources and no scraping, Readarr .db import, ebooks and audiobooks with separate roots and narrator metadata, ARM support down to a Pi Zero on armv6, and a Helm chart and distroless image for Kubernetes. LazyLibrarian is Python with a community fork status, Goodreads plus fallbacks for metadata, no Readarr import, and magazine and comic support. Livrarr is Rust at an alpha stage of 0.1.x with four metadata sources, no Readarr import, and arm64 only. Readarr is C# on .NET, archived in June 2025, with a dead backend and limited audiobook support.

The README's own guidance is to pick Bindery for a modern, low-maintenance manager that survives metadata outages and swallows the old Readarr database whole, LazyLibrarian for a long-established tool with magazine and comic support if a dated UI is acceptable, and Livrarr for the same single-binary spirit without the maturity, the import, the Pi-class ARM or the Helm chart yet.

And it draws a line between acquisition and serving: Calibre-Web and Audiobookshelf solve a different problem, serving an already-curated library rather than automating acquisition, and pair well downstream of Bindery.

The limitation worth stating plainly is that this is an acquisition tool. It searches indexers and hands jobs to a download client, so what ends up in your library is determined by the indexers and the download clients you configure and by the search terms you set. The project provides the blocklist, the metadata fallbacks and the import path; deciding what to fetch remains the user's responsibility, and running it against sources you are not entitled to use is on the user rather than on the software.

There is a second, milder limitation. The whole premise is that metadata comes from public APIs, and public APIs for books are thinner than the web pages they replace. Fields that only appeared in a scraped page are simply not there, so a library that relied on the scraped enrichment will come across the migration less rich than it was.

Editorial conclusion

Adopt Bindery if you already run the Readarr stack and want the same workflow without depending on a metadata backend that can vanish, and if your hardware includes something modest, since ARM builds go down to a Pi Zero. Do not adopt it without configuring indexers and a download client, because the acquisition half of the workflow is the point and it is your responsibility what you point it at. Verify first that the metadata providers you want are configured, since OpenLibrary leads and the rest are fallbacks, that the import from `readarr.db` carries your indexers and download clients across, and that the version you take matches the release you read, with v1.44.0 published on 2026-10-19.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vavallee/bindery on GitHub