Server
KMServer is a single static Rust binary (kmrs). It scans your library directories in place and serves everything over HTTP on port 25600. The Docker image additionally bundles the kmweb UI, so the browser interface works out of the box.
Architecture
How the pieces fit together, for developers and the curious.
Libraryyour files
KMServerkmrs binary, backed by SQLite (database.sqlite, tasks.sqlite)
Web UIkmweb
OPDSv1.2 / v2
REST API
KMReaderoffline-first storage
iPhoneiPadMacApple TV
API
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 instance of komga 1.27.1.
Database
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.
Filesystem
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.
Client
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.
Offline storage
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.
Sync
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.