How the pieces fit together, for developers and the curious.
KMServer is a full-featured Komga drop-in replacement with additional capabilities, distributed as a single self-contained Rust binary (kmrs) with no JVM and a small memory footprint. It scans your library directories in place and serves everything over HTTP on port 25600. The kmweb UI is embedded in the binary, so the browser interface works out of the box. Bounded memory and container caches keep resource use predictable and page serving efficient.
The Komga-compatible surface: REST under /api, OPDS v1.2/v2 catalogs, SSE live updates, and Kobo and KOReader sync. A differential harness compares about 105 endpoints against a live Java Komga instance.
SQLite: database.sqlite and tasks.sqlite in the config directory. Existing Komga databases are upgraded in place with byte-for-byte Flyway migrations, and the Java version can still open the result.
Your media stays where it is. KMServer reads library directories in place; files are not moved or rewritten. Config and database live under /config, library content under /data in the container layout.
KMReader is a native Apple app (Swift) for iOS, macOS, and tvOS. It talks to the same Komga REST API as every other client, and works with any Komga 1.20.0 or later server.
Downloads live in an offline-first local database on the device: pages, covers, and metadata are stored locally, with per-series download policies and background transfers.
Reading progress is tracked on device first and synced to the server when you reconnect, through the same progress endpoints the other Komga clients use.
Deeper detail lives in the docs: Compatibility, Enhancements, Serving a web UI, Development.
