Kavita is a self-hosted reading server that indexes comics, manga, ebooks and PDFs and serves them through in-browser readers tuned per format. It replaces Komga, Calibre-Web and paid manga apps, and it is aimed at reading in the browser rather than exporting to a device.
Our verdict on Kavita#
Kavita's advantage over Calibre-Web is that it does not need Calibre, and its advantage over a generic media server is readers built per format: a manga reader with proper double-page and right-to-left handling, an EPUB reader with an annotation system as of v0.8.8, and a PDF reader that is usable rather than a download link. The catch is that scanning is filename-driven. Kavita parses series, volume and chapter out of your file names, and the only reliable fix for a misparse is a ComicInfo.xml inside the archive, not a UI override. Budget an evening on naming before you blame the scanner. The money question: Kavita+ is an optional node-locked subscription around $4/month that adds external metadata matching and scrobbling to AniList, MAL, Mangabaka and Hardcover. Core features are never gated. Also treat updates as mandatory: v0.9.0.2 (May 2026) was a security hotfix affecting all prior versions.
Who Kavita is for#
Choose it if
- A large manga or Western comics collection in CBZ or CBR that you want to read on a tablet browser.
- You want per-user reading progress and age restrictions when sharing a library with kids or friends.
- You already run an OIDC provider and want library access driven by provider roles instead of another user table.
- You want an EPUB reader in the browser rather than a send-to-device workflow.
Look elsewhere if
- Your library is a Calibre library and you want Calibre's metadata editing and format conversion: that is Calibre-Web's job.
- You will not rename files or add ComicInfo.xml, because Kavita's parser is the front door and it works off names.
- You mainly read on a Kindle or Kobo and want automated send-to-device, which Kavita does not do.
What running it actually looks like#
One container, jvmilazz0/kavita, multi-arch for amd64 and arm64, listening on port 5000. Two mounts: a config volume for the SQLite database, covers and logs, and your comics or books directory, which can be read-only. First run is a browser wizard that creates the admin account and asks for library folders, and it will start scanning immediately: a first scan on tens of thousands of archives runs for hours because every file is opened to extract a cover and count pages. Library type matters at creation time (Manga, Comic, Book, Light Novel) because it changes how names are parsed, and changing it later forces a full rescan. Upgrades are a tag pull with automatic migration; the project ships frequently, so read release notes before jumping several minors.
Resource profile#
- Memory
- 250 MB idle, around 600 MB in ordinary use. The .NET runtime plus the database at rest; scans that unpack CBZ archives to extract covers and page counts are the spike, and large PDFs are read into memory to render.
- CPU and acceleration
- Serving pages is cheap. Library scans decompress every archive to count and extract pages, so a first scan of a big manga collection pegs a core for a long time; PDF rendering is the other CPU cost.
- Storage growth
- The cover and thumbnail cache under the config volume grows with series count rather than file size, and bookmarks plus reading progress stay small; your comic archives are the real footprint.
- Operational load
- 2 of 5, Light. Single container, single SQLite database, directory copy for backup, and it ships its own scheduled backup task. It is a 2 because release cadence is fast, minor versions have carried breaking metadata and scan behavior changes, and at least one 2026 release was a security hotfix you had to take promptly.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Back up the config volume. kavita.db holds users, reading progress, bookmarks, collections, reading lists and the Kavita+ association, and it is the only copy of any of that. Kavita has a built-in backup task that writes a dated archive of the database, appsettings.json and logs into config/backups/; that is the safe way to capture a consistent database, and copying kavita.db live under WAL is not. The config/covers/ and config/cache/ directories are regenerable from a rescan and are usually the bulk of the volume, so exclude them if you want a small backup. Your comic and book files are never modified.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
Scanning is filename parsing, not metadata reading
Kavita derives series, volume and chapter from the file and folder names using per-library-type rules. A file named oddly ends up as its own one-chapter series, and no amount of editing in the UI makes the parser change its mind on the next scan. The durable fix is a ComicInfo.xml inside the CBZ with Series, Volume and Number set, which Kavita reads and prefers. Fix naming before importing at scale.
Library type is set once and rescans if changed
Choosing Manga versus Comic versus Book at library creation changes the parsing rules, the reader defaults and the reading direction. Getting it wrong and switching later triggers a full rescan and can reshuffle how series are grouped, taking reading progress associations with it. Decide the type per folder before you point Kavita at 40,000 files.
Kavita+ is node-locked to one instance
The optional subscription that unlocks external metadata and scrobbling to AniList, MAL, Mangabaka and Hardcover is bound to a single instance rather than to a user. It benefits every user on that server, but moving to new hardware or rebuilding the container without restoring the database means re-associating the licence. Base Kavita features are never behind it, so nothing you already use stops working if it lapses.
v0.9.0.2 was a security hotfix for all prior versions
Released 12 May 2026, it addressed a vulnerability affecting every earlier release. If your Kavita is reachable from the internet and pinned to an older tag, that is an exposure rather than a stability choice. Kavita's release cadence assumes you update; the built-in backup task exists precisely so taking updates is cheap.
Specifications#
- Category
- Media servers and libraries
- Licence
- GPL-3.0 (Copyleft)
- Written in
- C# / .NET and Angular
- First release
- 2021
- Maturity
- Stable
- Datastore
- SQLite
- Default ports
5000- Ships as
- docker, native binary
- arm64 builds
- Yes
- Identity
- Native OIDC. Native OpenID Connect landed in v0.8.8 and can run alongside or fully replace local accounts, including mapping provider roles to library access and age restrictions.
- Replaces
- Komga, Calibre-Web, ComiXology, Plex Comics
- Project site
- www.kavitareader.com
- Source
- github.com/Kareadita/Kavita
- Documentation
- wiki.kavitareader.com
Alternatives to Kavita#
Everything else in media servers and libraries, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Audiobookshelf | 2, Light | 200 MB | GPL-3.0 |
| Calibre-Web | 2, Light | 120 MB | GPL-3.0 |
| Emby | 2, Light | 350 MB | Proprietary |
| Jellyfin | 2, Light | 280 MB | GPL-2.0-only |
| Jellyseerr | 2, Light | 220 MB | MIT |
| Plex Media Server | 2, Light | 400 MB | Proprietary |
Where Kavita comes up elsewhere#
Head to head
Migration guides
Calculators
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.