Omnivore
Read-it-later app with highlights and newsletter support
Omnivore is an open-source read-it-later application that saves articles for distraction-free reading. It supports highlights, notes, full-text search, and forwarding newsletters to your library.
Key features
- Distraction-free reading
- Highlights and notes
- Newsletter inbox support
Pros & cons
Strengths
- Newsletter inbox support
- Highlights and notes
- Full-text search
Trade-offs
- Complex microservice deployment
- Development has stalled
Omnivore replaces
Last reviewed Aug 26, 2026 · 761 words
Do not start a new read-it-later setup on Omnivore in 2026. The hosted service shut down in late 2024 after ElevenLabs acquired the team, the AGPL code on GitHub has gone quiet since, and the self-hosted deployment was always the hardest in its category: eight or so containers including PostgreSQL, Redis, a headless-Chromium fetcher and an object store, with 1 GB of RAM as the floor and a "Hard" rating that is not an exaggeration. The 16,229 stars are the outline of a product that was genuinely good. Wallabag or Readeck gives you 90% of it in one container that someone is still maintaining.
What happened, briefly
Omnivore launched in 2022 as an open-source Pocket replacement with a polished reader, highlights and notes, full-text search, and a feature nobody else had done well: an email address per user so newsletters landed in the reading queue instead of the inbox. In late 2024 the team joined ElevenLabs to work on that company's reader app, the hosted service was wound down within weeks, and users were told to export. The repository stayed public. Commits from the original maintainers stopped, forks appeared, and none has become a clear successor. Pocket itself closed in 2025, so the Pocket alternatives list now contains two ghosts and the projects that outlived them.
What running the frozen code actually involves
The self-hosting Compose in the repository starts the API, a queue processor, the web app, a content-fetch service that drives Chromium to render pages, an image proxy, PostgreSQL, Redis and MinIO, with a migration container on top. Expect 2 GB of RAM in practice once Chromium is fetching articles, and several evenings of environment variables. The newsletter inbox is the awkward part: on the hosted service it worked because Omnivore ran the mail domain, so self-hosted you need your own inbound mail path feeding the mail-watch component, which is a second project on top of the first.
The bigger issue is that a stalled Node.js microservice stack accumulates unpatched dependencies. I would not expose it to the internet at all. Behind Tailscale it is a reasonable way to keep reading an archive; as a public service it is a liability waiting for a CVE.
Getting your data out, and into what
Omnivore's export is a zip of JSON metadata files (URL, title, labels, saved date, reading state) alongside HTML for each article and your highlights. Both Readeck and Wallabag added importers for that format after the shutdown, so the archive moves in one step rather than a script. Labels become tags, highlights come across in Readeck, and anything that was a saved PDF or a newsletter arrives as an article with its original content.
| Omnivore | Wallabag | Readeck | Karakeep | |
|---|---|---|---|---|
| Containers | 8 or so | 1 plus database | 1 | 3 |
| RAM in practice | 2 GB | 256 MB | 128 MB | 1 GB plus |
| Highlights | Yes | Annotations | Yes | Yes |
| Newsletter inbox | Yes, with your own mail | No | No | No |
| Maintained | No | Yes | Yes | Yes |
Nothing in the table replaces the newsletter inbox. If that was the reason you used Omnivore, the honest substitute is a mail filter rule that forwards newsletters to your reader's save-by-email address (Wallabag supports one through a plugin-style setup) or a dedicated RSS reader that converts newsletters to feeds. The bookmarks category covers the wider field, including Karakeep for people who want bookmarks and AI tagging more than a long-form reader.
Who should still run it
Someone with years of highlights who wants the exact reading experience while they migrate, or who has the time to maintain a fork. The official mobile apps were pulled from the stores with the service, so on a phone you are building the app yourself and pointing it at your server, which is another cost to count. For everyone else, the code is worth reading as a design reference and not worth operating.
What I'd do
Export from any Omnivore instance you still have, import into Readeck if you read alone or Wallabag if the household shares it, and check the highlights came across before you tear anything down. Set up a mail rule for newsletters. If you truly need the Omnivore reader for a while, run the Compose stack on an isolated host reachable only over Tailscale, and set a calendar date to switch it off. The product deserved better; the software as it stands does not deserve your weekends.
Compare Omnivore
15 head-to-head comparisons.
- Omnivore vs Karakeep
- Omnivore vs ArchiveBox
- Omnivore vs Linkwarden
- Omnivore vs Wallabag
- Omnivore vs Shiori
- Omnivore vs Linkding
- Omnivore vs Shaarli
- Omnivore vs Archivy
- Omnivore vs Grimoire
- Omnivore vs Promnesia
- Omnivore vs Read-later nono Reminiscence
- Omnivore vs Readeck
- Omnivore vs Espial
- Omnivore vs Bookmark dashboard nono Benotes
- Omnivore vs omnom
Similar bookmarks & read-it-later apps
Karakeep
Bookmarks & Read-It-LaterSelf-hosted bookmark everything app with AI tagging
Replaces Pocket, Raindrop.io
ArchiveBox
Bookmarks & Read-It-LaterSelf-hosted web archiving from bookmarks and feeds
Replaces Pocket
Linkwarden
Bookmarks & Read-It-LaterCollaborative bookmark manager with page archiving
Replaces Pocket, Raindrop.io
Wallabag
Bookmarks & Read-It-LaterSelf-hosted read-it-later application
Replaces Pocket, Instapaper
Shiori
Bookmarks & Read-It-LaterSimple bookmark manager built with Go
Replaces Pocket, Raindrop.io
Linkding
Bookmarks & Read-It-LaterMinimal and fast self-hosted bookmark manager
Replaces Pocket, Raindrop.io