Kavita vs Calibre-Web

Install Calibre-Web against an empty directory and it will not finish setup. It is a web front end for a metadata.db that Calibre desktop or calibredb created, and it cannot create one for you. That single fact decides this comparison for most people before any feature gets compared.

Kavita has no such dependency. It indexes files, builds its own database, and never touches your books. In exchange it insists on something else: that your filenames are parseable.

So the real choice is between inheriting Calibre's data model and inheriting Kavita's naming rules.

What the spec table is telling you#

Both are single containers with SQLite and directory-copy backups, so the interesting rows are Identity and Idle memory. Kavita does native OIDC with role mapping. Calibre-Web does LDAP, GitHub and Google OAuth, or a trusted proxy header, and nothing else. Kavita idles at 250 MB against Calibre-Web's 120 MB, which is the .NET runtime against a small Flask process.

The row that is not in the table is the one that matters: Calibre-Web needs a Calibre library to exist first, and Kavita needs nothing. Hold that in mind while reading everything else.

Which one is better to read on#

Kavita, clearly, and it is the reason the project exists.

It ships a reader per format. The manga reader handles double-page spreads and right-to-left properly. The EPUB reader gained an annotation system in v0.8.8. The PDF reader renders in the browser instead of handing you a download. Reading progress is per user, and age restrictions let you share one library with children without curating a second copy.

Calibre-Web's reader is serviceable for EPUB and awkward for anything large or image-heavy. Its centre of gravity is elsewhere: browse, search, and get the file onto a device.

Which one gets a book onto a Kindle#

Calibre-Web, and this is its strongest remaining argument.

It does send-to-Kindle by email from a browser, exposes OPDS so KOReader, Moon+ Reader or Marvin can pull books over the network, and can convert formats on the fly. Per-user shelves and download permissions make a shared family library workable.

The catch is that conversion and send-to-Kindle call out to Calibre's ebook-convert and kepubify, which are not in the base image. The menu entries appear and then fail. You set the path under Admin, Basic Configuration, External Binaries, and in Docker that usually means a second container that ships Calibre with a shared volume, or an image bundling both. Note also that the original janeczku/calibre-web Docker Hub image is deprecated and stale; the multi-arch image people actually run is LinuxServer's.

Kavita has no send-to-device workflow at all. If you read on e-ink hardware and want books pushed to it, that is not a gap you can configure around.

Is Calibre-Web a risky pick today#

It deserves a straight answer: it is riskier than Kavita, and the risk is patch latency rather than abandonment.

Upstream shipped 0.6.26 in May 2026 as a security release fixing CVE-2025-7404, a remote code execution issue, alongside a ReDoS and a stored XSS. So it is maintained. But the pace is slow enough that two active forks exist for exactly that reason: Calibre-Web-Automated (3.1.2, adding an automatic ingest folder, KOReader sync and Calibre plugin support) and Calibre-Web-NextGen, started in May 2026 for faster iteration. They diverge in configuration and database handling, so migrating between them later is not an image swap. Choose one at install time and pin to it.

Then there is the default. Every fresh Calibre-Web install ships with admin / admin123, and this is an app people habitually publish on a public hostname so family can browse it. Default credentials plus a known RCE in recent history is not a theoretical combination.

Kavita is not exempt from this. v0.9.0.2 (12 May 2026) was a security hotfix affecting every prior version, and Kavita's release cadence assumes you update. The difference is cadence: Kavita ships often enough that a fix reaches you quickly, and it ships a built-in backup task so taking updates is cheap. Both belong behind the baseline in A security baseline for a home server, and both belong in the routine in An update strategy that does not lose data.

What breaks on scan day#

Kavita's whole front door is the filename. Series, volume and chapter are parsed out of names using rules that depend on the library type you pick at creation: Manga, Comic, Book or Light Novel. Those rules change parsing, reader defaults and reading direction, and switching the type later forces a full rescan that can reshuffle series grouping and take reading progress associations with it. Decide per folder before you point it at 40,000 files.

When the parser is wrong, the fix is not in the UI. It is a ComicInfo.xml inside the archive with Series, Volume and Number set, which Kavita reads and prefers. Scanning is also expensive the first time: every archive is opened to extract a cover and count pages, so a first pass over tens of thousands of CBZ files runs for hours.

Calibre-Web does not scan. Calibre already did that work, and Calibre-Web reads the result. That is genuinely less effort, and it is why people with a curated library find Calibre-Web pleasant and Kavita fussy. The cost is that all metadata correction happens in Calibre desktop, on a machine that must not be running against the library at the same time as Calibre-Web:

Which one you can get your data out of#

Calibre-Web has the better answer, by accident of architecture. All book metadata, tags, series and custom columns live in Calibre's metadata.db, which is a documented format that Calibre itself owns. If Calibre-Web disappears tomorrow, your library is intact and openable in the desktop app. Calibre-Web's own app.db holds users, shelves and read state, and that part is small and irreplaceable.

Kavita's kavita.db holds users, reading progress, bookmarks, collections, reading lists and the Kavita+ association, and it is the only copy of any of it. There is no second application that understands the format. Use the built-in backup task, which writes a dated archive of the database, appsettings.json and logs into config/backups/, because copying kavita.db live under WAL is not safe. config/covers/ and config/cache/ are regenerable and usually the bulk of the volume, so exclude them.

Both leave your actual book files untouched, which means the worst case in either direction is losing read state and rebuilding a library. Fold both config volumes into Backups that actually restore and move on.

The verdict, by situation#

What to do next#

Answer one question: does a metadata.db already exist on your disk? If yes, run Calibre-Web against it, change admin123 in the first minute, decide deliberately between upstream and Calibre-Web-Automated, and put authentication in front before you share the URL. If no, run Kavita and spend the setup time on naming instead: pick the right library type per folder, sample a few series to see how the parser handles them, and add ComicInfo.xml where it guesses wrong.

Neither is a big install. Kavita is one container on port 5000 with a config volume and a read-only books mount; Calibre-Web is one container on 8083 plus wherever Calibre's binaries come from. Check what they add to your host with Stack planner, front them properly with Reverse proxy and TLS, and if identity is on your roadmap, Pocket ID plus Kavita's native OIDC is the lightest path to it. See Single sign-on for self-hosters and the rest of Media.