Kavita vs Komga: Self-Hosted Comics and Books

Every comparison post in this category eventually admits that both options are good, which is unsatisfying to read and usually true. So let me put the useful part first: if you own a Kobo, install Komga. If you read epubs as much as comics, install Kavita. Everything below is why, and what happens if neither of those describes you.

I have been running both against the same library — around 6,000 CBZ files and 900 epubs — since the summer. They are the two mature servers in a category that has been through a lot of abandonware, and the days of fighting a decade-old PHP thing are thankfully over.

What They Both Do Well

Start with the common ground, because it is most of the product.

Both scan a folder of .cbz and .cbr files and turn it into a library with series, volumes and chapters. Both read ComicInfo.xml — the metadata standard embedded inside the archive — and both let you edit metadata in the web UI afterwards. Both have web readers that are genuinely pleasant, with double-page spreads, fit modes and right-to-left support for manga. Both serve OPDS, so the third-party reader apps work. Both track read progress per user, and both handle multiple users with per-library permissions.

Both are one container plus SQLite. No Postgres, no Redis, no message queue.

If you only ever use the web reader and only ever read comics, you can flip a coin. The differences show up at the edges, and the edges are where the reading happens.

Komga

Kotlin on the JVM, which is a sentence that makes people flinch and should not. It idles at around 500 MB with the heap capped, which is more than Kavita and irrelevant on anything modern.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

services:
  komga:
    image: gotson/komga:latest
    restart: unless-stopped
    user: 1000:1000
    ports:
      - "25600:25600"
    environment:
      TZ: Europe/Copenhagen
      JAVA_TOOL_OPTIONS: -Xmx1g
      KOMGA_LIBRARIES_SCAN_CRON: "0 0 4 * * ?"
    volumes:
      - komga_config:/config
      - /srv/media/comics:/data:ro

volumes:
  komga_config:

That -Xmx1g line matters. Left alone, the JVM sizes its heap as a fraction of host memory, which on a 64 GB server means Komga cheerfully reserves several gigabytes it will never need. Cap it and it behaves.

The cron expression is Quartz syntax — six fields, with seconds first — which is a small tax and catches everyone once.

Komga’s differentiator is Kobo Sync. Point a Kobo e-reader at your Komga instance and it appears in the device’s own library UI, syncs books over, and pushes reading position back. No sideloading over USB, no Calibre, no fighting with the device. It works because Komga implements the same store API the Kobo already speaks, which is a genuinely clever piece of engineering and the single most-loved feature in the project.

If you own a Kobo, this ends the discussion. The alternative is a USB cable forever.

Its other strengths: duplicate detection that actually finds the four copies of a volume you have accumulated; a proper API with an OpenAPI spec; and metadata editing that is fast enough to fix a hundred series in an evening.

Its weakness is the epub reader, which arrived recently and is basic. Komga treats epubs as something it also supports.

Kavita

C# on .NET, one container, SQLite, and a smaller footprint — around 150 MB idle on my box.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

services:
  kavita:
    image: jvmilazz0/kavita:latest
    restart: unless-stopped
    ports:
      - "5000:5000"
    environment:
      TZ: Europe/Copenhagen
    volumes:
      - kavita_config:/kavita/config
      - /srv/media/comics:/comics:ro
      - /srv/media/books:/books:ro

volumes:
  kavita_config:

A naming note that trips people up: the image moved namespaces a while back. Old guides point at kizaing/kavita, which is stale. Use jvmilazz0/kavita.

Kavita’s differentiator is that it takes books seriously. It has three library types — Manga, Comic and Book — and the type changes the parsing rules and the reader. The epub reader has font selection, margins, line height, themes and a table of contents that works, and it remembers where you were to the paragraph. It is a real reading application.

Because of that, Kavita is the better answer if your library is mixed. Mine is roughly 85% comics and 15% epubs, and the epubs are the ones I read on a tablet in the evening, which weights the decision more than the ratio suggests.

Its other strengths: reading lists that cross series, a “want to read” shelf, and a nicer library-browsing UI overall.

Then there is Kavita+. This is a paid subscription tier from the maintainer that unlocks scrobbling to AniList and MyAnimeList plus external metadata matching. The core server stays open source and self-hostable, and the extra features route through a hosted service. I have no objection to a maintainer getting paid — the alternative is burnout and an archived repository — and it is worth knowing before you build a workflow around a feature that has a bill attached. Komga has no equivalent and no subscription.

The Clients, Which Matter More Than the Server

Almost nobody reads comics in a browser on a phone. The mobile app decides your experience, so here is the state of play.

On Android, Mihon — the community continuation of Tachiyomi, which shut down at the start of this year — has extensions for both servers. They are equally good. This is the best comic reading experience available on any platform and it costs nothing.

On iOS, the situation is more constrained. The OPDS clients handle both. Paperback has sources for both. Neither is as good as Mihon and that is a platform reality rather than a server one.

For epubs, Kavita’s own web reader on a tablet is better than most native apps, and Komga’s Kobo Sync puts the book on hardware designed for the job. This is the fork in the road, and it is a hardware question rather than a software one.

Both speak OPDS, so the generic clients work with either. If you already terminate identity at Authelia or Authentik, be aware that OPDS clients cannot do an interactive login and an SSO portal in front of either server will break every app you own. The /opds/ path needs to stay reachable with basic credentials, which means a proxy rule with an exception in it — the kind of thing that is fine when you write it down and a nasty surprise when you do not.

The Metadata Work Neither One Does For You

The pattern repeats across every media server I have written about, and it is worth stating plainly because it is the actual project.

The server is a view of your files. Kavita and Komga both read ComicInfo.xml from inside each archive, and if that file is absent or wrong, they fall back to parsing the filename, and filename parsing is a heuristic that fails in creative ways. A library assembled over a decade from a dozen sources has no consistent metadata at all, and no amount of choosing the right server fixes that.

So the sequence that works is: fix the files, then install the server. Reversing it means doing the work twice, once badly through a web UI.

The tool is ComicTagger, which reads a comic, matches it against Comic Vine, and writes a proper ComicInfo.xml back into the archive:

1

comictagger -s -t cr -o -f --overwrite --save-config   --search-alternate-series -m "series=Saga" /srv/media/comics/Saga/*.cbz

That -s is the online search, -t cr writes the ComicRack tag format both servers read, and the dry-run habit applies here as everywhere — run it without --overwrite first and read what it proposes. For manga, the Comic Vine database is thin and you will do more by hand.

The fields that actually change what you see are Series, Number, Volume and Year. Get those four right on every file and both servers produce a library that looks curated. The rest — writer, colourist, characters — is nice and nobody browses by it.

The reason this matters more than the Kavita-versus-Komga argument is portability. A library with correct embedded metadata can be pointed at either server, or at whatever replaces both of them in 2031, and it will just work. The metadata lives in the files, so the server becomes genuinely disposable, and that is the property you actually want from any of this. My comics sit on the same bulk array as everything else, tagged once, and I have now pointed three different pieces of software at them without touching a single archive.

Budget a weekend. It is dull, it is the highest-value thing in this post, and it is the part every comparison article skips because comparing containers is more fun than typing series names.

Troubleshooting

Nothing is found. Permissions, as ever. Both containers need read access to the mount; check from inside rather than from the host, because the UID mapping is what actually matters.

1
2

docker compose exec komga ls -la /data | head
docker compose exec kavita ls -la /comics | head

CBR files fail on some setups. RAR is a proprietary format with a licensing history. Both handle it; both handle CBZ better and faster. Converting your library to CBZ is a one-off script and removes a whole class of future problem:

1
2
3
4
5

find /srv/media/comics -name '*.cbr' -print0 | while IFS= read -r -d '' f; do
  d=$(mktemp -d)
  unrar x -inul "$f" "$d/" && (cd "$d" && zip -0 -r -q "${f%.cbr}.cbz" .) && rm -f "$f"
  rm -rf "$d"
done

Test it on ten files before you point it at six thousand, and take a snapshot first. The -0 is deliberate — the images inside are already compressed and recompressing them wastes CPU for nothing.

Komga eats memory. The heap. See -Xmx1g above.

Series are fragmented into singles. Both parse the filename and the folder. Consistent naming — Series Name/Series Name v01 (2019).cbz — fixes most of it. Neither can rescue chaos, and the tool for the job is a metadata pass with ComicInfo.xml before you ever start the server, in exactly the same way that audiobook folder structure decides everything in that category.

Kobo Sync connects and syncs nothing. The device needs a reachable HTTPS URL with a valid certificate; a self-signed cert fails silently on the Kobo. It also only syncs epubs and Kepubs, and a shelf of CBZ files is invisible to it — which surprises people who expected to read comics on a six-inch e-ink screen and would have been disappointed anyway.

Progress resets after a rename. Both key on file identity. Rename or re-encode a file and you have a new item with no history. Do your library reorganisation before you start reading, or accept the loss.

Verdict

Both projects are healthy, actively maintained, and free of the drama that has followed this category around. Either will serve you well for years.

Choose Komga if: you own a Kobo (this outweighs everything else), your library is comics and manga with epubs as an afterthought, you want the best duplicate detection, or you want no commercial tier in the picture at all.

Choose Kavita if: you read epubs seriously, you want a genuinely good reading application rather than a delivery mechanism, or you want the smaller footprint.

Run both if: you have the RAM, because they will happily read the same read-only mount and cost you nothing but a port. This is what I did for four months and it is how I know any of the above. Split by content type — Komga for the comics feeding Mihon and the Kobo, Kavita for the epub shelf — and the overlap stops being a problem.

The honest caveat for the whole category: this is a solved problem with two good answers, and the time you spend choosing is time you could spend reading. I lost a weekend to a decision that turned out to hinge on which e-reader was in the drawer. Go and check the drawer, then install the corresponding one, and if it turns out to be the wrong call the migration is a mount path and an evening of re-matching metadata. The stakes are lower than the comparison posts imply, mine included.