Komga: a self-hosted comics and eBook server with OPDS, Kobo and KOReader sync

What Komga solves for people with a shelf full of CBZ files

A folder of comic archives is easy to accumulate and hard to browse. File names, folder nesting and whatever metadata the files carry are the only structure you get, and no two readers agree on how to present it. Komga's stated purpose is to be the server layer over that folder: it indexes comics, mangas, BDs, magazines and eBooks, then exposes them through a responsive web UI for desktop, tablets and phones. The features list also covers organisation beyond the filesystem, with collections and read lists, metadata editing for series and books, and automatic import of embedded metadata. Access control is part of the pitch: multiple users, per-library access control, age restrictions and label restrictions. The intended audience is someone running their own hardware who wants their collection reachable from a browser and from e-readers, not someone looking for a storefront. That distinction matters, because Komga does not sell or license content. It serves what you already have.

How the server, the API and the sync protocols fit together

Komga is a Kotlin application built on Spring Boot, and the repository topics list both, along with domain-driven design. The top-level layout shows the shape of the deliverable: a komga/ directory for the server, komga-webui/ and next-ui/ for the front ends, komga-tray/ for a desktop tray wrapper, and a Gradle build (build.gradle.kts, gradle/, gradlew) as the build entry point. The README describes a REST API as a first-class surface, with community tools and scripts interacting through it, and lists OPDS v1 and v2 alongside Kobo Sync and KOReader Sync. Those are three different consumption paths over the same library: OPDS for reader apps that speak the feed format, Kobo Sync for Kobo hardware, KOReader Sync for KOReader devices. The webreader is the fourth, with multiple reading modes. On the maintenance side, Komga handles library hygiene as a server concern: duplicate files detection, duplicate pages detection and removal, importing books from outside your libraries directly into a series folder, and importing ComicRack cbl read lists. The last push to the default branch was on 2026-09-21, and release 1.27.0 is dated 2026-09-17.

Installing Komga and getting a first library indexed

The README does not carry install commands. It points to the installation section of the project website, at komga.org/docs/category/installation, and that is where platform-specific instructions live. The repository does publish a Docker image, since the README links to the gotson/komga Docker Hub page and the topics include docker. The exact image tag, volume paths and port mapping are not stated in the README, so take them from the website or the DOCKERHUB.md file in the repository rather than from a guess. Once the server is running, the workflow described in the feature list is: point it at your files, let it index, then organise. The REST API is the other entry point for anything scripted. Because the README gives no endpoint examples, the API reference on komga.org is the place to look before writing a client. For a first run, the practical check is whether the web UI lists your series after indexing and whether the embedded metadata you expected shows up, since automatic import of embedded metadata is a documented feature rather than a default you can assume for every file format.

Where Komga is the wrong tool

Komga is a server, and that is the constraint. It has to be running for the web UI, OPDS clients, Kobo Sync and KOReader Sync to reach it, so a machine that sleeps, a laptop you close, or a host you shut down for the night all break the experience for every client at once. The README says nothing about offline operation or a standalone desktop reader, and the presence of komga-tray/ in the repository does not change the client-server relationship. Remote access is the second gap. The feature list does not describe a reverse proxy setup, a tunnelling option or a hosted relay, so exposing Komga beyond your local network is something you design and secure yourself. If you want a service where someone else runs the server, handles TLS and keeps the uptime, Komga is the wrong shape entirely. The same applies if your collection is small enough that a single reader app opening local files is less work than maintaining a server.

Komga compared with Kavita

The comparison people search for is Komga against Kavita, and the honest answer from what the project documents is that only one side is covered. Komga's README lists OPDS v1 and v2, Kobo Sync, KOReader Sync, a REST API, per-library access control with age and label restrictions, duplicate file and duplicate page detection, and ComicRack cbl import. That is a specific set of protocol integrations and library-management features, and it is what you would evaluate a Kavita deployment against: which sync protocols each one supports for your actual reading devices, and which library-maintenance operations each one performs. The README does not compare itself with anything, so treat any side-by-side you read as something to verify feature by feature on both projects rather than as a conclusion. If your devices are Kobo or KOReader, that is the concrete axis to check first, because sync support is the part of a media server that is hardest to substitute after the fact.

Licence, upgrade cost and what the repository tracks

Komga is MIT licensed, which is permissive and places few conditions on reuse; the LICENSE file at the repository root is the authority, and nothing here is legal advice. Upgrades are a real maintenance item rather than a background detail. Releases are frequent, with 1.27.0 on 2026-09-17 following 1.26.3 and 1.26.2 in August 2026, so a self-hosted instance will fall behind quickly if nobody looks at it. The repository ships a CHANGELOG.md, which is the file to read before moving between releases, and it also carries ERRORCODES.md and SECURITY.md, which are worth knowing about when something fails or when you need to report a vulnerability. The project accepts translations through Weblate, so the UI language coverage moves independently of the server releases. Running Komga is not a one-time install; it is a service you keep current, and the cost is measured in the releases you choose to skip.

Editorial conclusion

Adopt Komga if you keep a large comic or eBook collection on your own hardware and want a browser reader plus Kobo or KOReader sync on top of it. Skip it if you need a managed cloud service or if you cannot run a long-lived server process, because Komga is software you host and keep running yourself. Before committing, read the installation page at komga.org, confirm your platform is covered there, and check the CHANGELOG for the upgrade notes between your current release and the target release.

Frequently asked questions

Official sources

1. gotson/komga on GitHub
2. License: MIT
3. Project website
4. README
5. Releases