Readest

Last reviewed Aug 26, 2026 · 819 words

Readest is the reader I now hand to anyone leaving Kindle: it opens EPUB and PDF with typography that does not look like a weekend project, runs on Linux, macOS, Windows, Android, iOS and in a browser from one TypeScript codebase, and keeps page position and highlights consistent across all of them. The self-hosting angle is smaller than the listing suggests. You are not hosting a library server; you are hosting the piece that keeps your reading progress and annotations off someone else's database. Set that expectation first and the project is excellent.

The reading experience is the reason to care

Readest only appeared in 2024 and already sits at 23,724 stars, which tells you how starved the open-source ebook world was for a modern reader. The desktop app is a Tauri build, so it opens fast and idles at a fraction of the memory an Electron reader would take. Formats cover EPUB and PDF properly, plus the usual long tail of MOBI, AZW3, FB2 and comic archives. Highlights, notes, in-book search, a dictionary popup, and side-by-side reading of 2 books are all present. Typography controls (font, line height, margins, justification, per-book overrides) are the best I have used outside a paid app, and dark mode is a real theme rather than an inverted screenshot.

If you have been tolerating Calibre's built-in viewer or a half-abandoned Electron reader, install the desktop build today. That part is Easy and costs nothing.

Sync is where the Medium difficulty and 512 MB come from

Out of the box, the official apps sync progress and annotations through Readest's own hosted accounts. That is convenient and, for most people, fine. The self-hosted path exists because the whole thing is AGPL-3.0: you can build the web app from source and run the account and storage backend on your own box. Plan on a Node build, a Postgres-backed auth and storage layer, and roughly 512 MB of RAM once it is idling. There is no polished one-line Docker image at the level of, say, Calibre-Web, and the documentation for a fully private deployment assumes you can read a TypeScript repo and are comfortable configuring an auth provider. It is the Medium-difficulty item inside an otherwise Easy product.

Two honest questions before you spend an evening on it. First, do your highlights need to be private, or is a reading position on a public-domain novel a threat you can live with. Second, do you actually read on more than 1 device. If the answers are "not really" and "no", the sync backend is a project, not a need.

Readest reads files; something else has to own the library

This is the misunderstanding that generates most of the confused forum posts. Readest is a reader in the sense that a music player is a player: it opens what you give it and remembers where you were. It does not catalogue 2,000 EPUBs, fix metadata, convert formats, or serve books to a Kobo. For that you still want a library server from the ebooks category. My pairing is Calibre-Web for a mixed EPUB collection with heavy metadata needs, or Kavita if comics and manga dominate. Download from the library, open in Readest, let the reader handle progress. The two roles rarely conflict, and keeping them separate means a broken reader update never touches your files.

The young-project tax is real but cheap

The listed cons are "relatively young" and "smaller community", and both are true in ways you will notice. Releases arrive frequently and occasionally move settings around. Edge-case EPUBs with strange CSS sometimes render differently between versions. Community answers live in GitHub issues rather than a decade of forum threads. None of this has cost me a book or a highlight, but I export annotations to Markdown every few weeks anyway, because a young sync service is the one component in this stack I do not yet treat as durable. The books themselves live in the library server and its backups, so the worst realistic failure is re-finding my place.

What I'd do

Install the desktop and phone apps and use Readest as the reader for every EPUB and PDF you own. Keep the library in Calibre-Web on the same box that already runs your other services, with its data folder in your normal backup rotation. Use the hosted sync for now, and export annotations on a monthly reminder. Only build the self-hosted sync backend when you have both a genuine privacy reason and a spare evening; when that day comes, put it on the same host as the library so the whole reading stack fails and restores together. That gets you 95 percent of the benefit with 10 percent of the maintenance.