Stump: A Self-Hosted Comics and Manga Server That Runs the Rust Part and the React Part

The gap Stump fills between a file share and a reading client

A folder of CBZ files on a NAS is readable by exactly one person at a time, on one device, with no metadata, no progress tracking and no way to hand a specific series to a specific account. Stump exists to sit between that folder and a reading client. The README describes it as a free and open source comics, manga, and digital book server with OPDS support, and the supported formats are EPUB, PDF, CBZ/ZIP and CBR/RAR, each with a built-in reader. The audience is the self-hoster who wants their library reachable from a browser, a Kobo device or KoReader without converting anything first. The project also lists multi-user account management with permissions and age restrictions, which points at a second audience: households or small groups where not every reader should see every shelf. Stump is not the first project in this space and the README says so directly, listing audiobookshelf, Codex, Kavita, Komga and Storyteller under Similar Projects. That honesty is useful, because it means the differentiator has to be found in the feature list and the architecture, not in a claim of novelty.

Rust server, React client, and where the pieces actually live

The repository is split across yarn workspaces and cargo workspaces, and the layout tells you more about the architecture than the marketing copy does. Under apps/ there are four applications: desktop, which the README describes as Tauri wrapping the web UI; expo, a React Native app; server, the Axum server; and web, the UI served by the server. The core/ directory holds what the README calls the primary internals, like file processing. Supporting Rust crates live under crates/, with migrations/ for database migrations and models/ for database models, plus cli, graphql and integrations. Shared TypeScript packages sit in packages/, and documentation in docs/. The stack is named in the first paragraph: Rust, Axum as the HTTP layer, SeaORM as the database layer, React for the interface. That combination means the server binary and the web UI ship together rather than as two independently deployed services. It also means a contributor touching library scanning works in Rust while someone touching the reader works in React, and the two meet at an API boundary. The presence of a migrations crate is worth noting for anyone planning upgrades: schema changes are versioned artifacts in the repository rather than something applied by hand.

OPDS 1.2, OPDS 2.0 and the sync integrations that decide your client

The headline interoperability feature is OPDS. Stump supports OPDS v1.2, including OPDS PSE (page streaming extension), and OPDS v2.0. Those are different specifications with different client support, and the distinction matters when you pick a reader. A client that only understands 1.2 will not consume a 2.0 feed, so the practical question before installation is which catalog format your existing app expects. Beyond OPDS, the README lists Kobo and KoReader sync integrations and links to separate guide pages for each. Sync is a narrower promise than catalog browsing: it implies progress or position moving between Stump and the device. Annotations and highlights are listed for EPUB books specifically, not for the comic formats, which is a reasonable boundary given that CBZ and CBR are page images with no text layer to anchor a highlight to. OIDC authentication is supported, so an existing identity provider can front the login instead of Stump managing passwords itself. Theming is handled through a set of built-in themes documented on the project site. Translations are managed through Weblate, and the README lists translation work first among the areas where contributions are wanted.

Getting it running: Docker, binaries, and the documentation handoff

The README does not contain installation commands. It states that installation guides are available in the documentation at stumpapp.dev/docs/getting-started/installation, or in the markdown file at docs/content/docs/getting-started/installation/index.mdx for people who prefer to read the source. What the README does confirm is that there are multiple installation methods, including Docker and pre-built binaries, and the badge at the top of the repository points at the Docker Hub image aaronleopold/stump. That image name is the concrete artifact to look for, and it is the only installation identifier present in the supplied material. For the developer path, the README again defers: the developer guide lives at stumpapp.dev/docs/developer/contributing with a markdown equivalent at docs/content/docs/developer/contributing.mdx, and the README explains the reason plainly, that maintaining two copies of the same information is undesirable. That is a sensible choice but it has a cost for anyone reading the repository offline. If you are evaluating Stump from a git clone on a machine without network access, the setup steps are not in the README you just cloned. The repository structure section does give you the workspace layout, which is enough to know that yarn workspaces and cargo workspaces both need to be present for a source build, but not enough to know the exact commands. Treat the site as the source of truth for install steps and re-check it at upgrade time.

The beta caveat is not boilerplate

Most projects carry a disclaimer. Stump's is unusually specific. The README states that Stump is under active development and should be treated as beta software until it reaches a stable 1.0 release, that the maintainer does their best to avoid breaking changes or changes which might cause data loss, and that there are no guarantees. It goes further: the maintainer develops and maintains Stump in their free time, it is not their job, and there is no guarantee of any timeline for features or bug fixes. Read together, those two paragraphs describe a project with a single-maintainer release cadence and no support commitment. The release history in the repository metadata is consistent with that: v0.1.5, v0.1.6 and v0.1.7, all still in the 0.1 series. The practical consequence is that a Stump instance holding the only copy of a library is a bad arrangement. The data-loss warning is the maintainer's own, and it should be taken at face value. The second limitation is scope: the built-in readers cover EPUB, PDF, CBZ/ZIP and CBR/RAR, and anything outside that set is not addressed in the README. If your collection includes formats the project does not list, Stump is the wrong tool for those files, and mixing them in will produce a library with holes in it.

Komga and Kavita solve overlapping problems with different priorities

The README names Komga and Kavita as similar projects, and the difference in approach is worth stating rather than gesturing at. Komga is a comics and manga server built on the JVM, which means it runs on a Java runtime rather than as a single Rust binary; the operational difference is in how you deploy, patch and monitor it, not in the reading experience. Kavita covers a similar range of book and comic formats and is also self-hosted. Stump's distinguishing choices are the Rust and Axum server with SeaORM, the Tauri desktop wrapper and the React Native app under apps/expo, and the fact that the web UI is served by the server itself. The multi-client story is the sharpest contrast: a project that ships a desktop wrapper and a mobile app alongside the browser UI is betting that reading happens on more than one device class, and the Kobo and KoReader integrations reinforce that. The counterargument is maturity. Komga and Kavita are established projects in this space; Stump is at 0.1.7 and describes itself as beta. Choosing Stump means choosing the newer stack and accepting the release cadence that comes with it. Choosing Komga or Kavita means accepting a different runtime and a different set of defaults. Neither choice is settled by a feature checklist alone.

Licence split, upgrade cost, and what to check before you commit

The repository-level licence is MIT, but the README is explicit that a package or subfolder with its own licence file takes precedence. Two such cases are listed. The expo application at apps/expo/LICENSE is GPL-3.0. The icons borrowed from the Spacedrive repository are under FSL-1.1-ALv2. Everything else in the repository is MIT. If you are running Stump as a self-hosted service for your own library, the MIT terms are the ones that apply to the server and web UI. If you are building on the mobile app, or redistributing a build that includes it, the GPL-3.0 terms attach to that component, and the FSL-1.1-ALv2 terms attach to the borrowed icons. This is not legal advice; read the licence files in the repository before you redistribute anything. On upgrade cost, the material supports a few concrete observations. Database migrations live in crates/migrations, so schema evolution is tracked in the repository rather than applied ad hoc. The README's warning about breaking changes means an upgrade between 0.1.x releases is not guaranteed to be drop-in. The release cadence visible in the metadata is roughly monthly across v0.1.5, v0.1.6 and v0.1.7, which is frequent enough that pinning a version and reading the release notes before moving is the reasonable posture. Verify three things first: that the current installation guide matches the method you intend to use, that your library's formats fall inside EPUB, PDF, CBZ/ZIP and CBR/RAR, and that your reading client speaks the OPDS version Stump publishes.

Editorial conclusion

Stump fits self-hosters who already run a media server stack, keep backups, and want OPDS plus built-in readers for EPUB, PDF, CBZ/ZIP and CBR/RAR in one place. It does not fit anyone who needs a stability guarantee: the README states it should be treated as beta until a stable 1.0 release and that there are no guarantees against breaking changes or data loss. Before committing a library, verify the current installation guide at stumpapp.dev, confirm which of your files are CBR/RAR and whether your client speaks OPDS 1.2 or 2.0, and read apps/expo/LICENSE because that subfolder is GPL-3.0 while the rest of the repository is MIT.

Official sources

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