Omnivore: a self-hosted read-it-later server you run yourself

What Omnivore solves, and who it is built for

Omnivore is a read-it-later system: you save an article, it extracts the readable text, and you come back to a clean page with your place kept. The README describes it as "a complete, open source read-it-later solution for people who like text", and the feature list backs that up: highlighting, notes, search, sharing, full keyboard navigation, automatic position saving, PDF support, labels, offline support, and text to speech on iOS only. Newsletter articles can arrive by email, with Substack support called out explicitly.

The audience is narrower than the feature list suggests. Omnivore is for readers who already keep a notes system and want their highlights to land there. The repository ships a Logseq plugin and an Obsidian plugin, and both are listed in the README rather than buried in the docs. If your workflow ends in one of those two tools, the export path is the point. If you only want a bookmark list with thumbnails, the machinery here is heavier than the job.

The important framing is the deprecation notice. The README states that Omnivore is now a completely self-hosted application and that the cloud application was deprecated in November 2024. That single sentence moves the project out of the consumer-app category. You are not signing up for a service. You are running one.

How the pieces fit: Next.js frontend, GraphQL API, content fetcher

The architecture is visible from the repository layout and the Makefile. The frontend is a Next.js application written in TypeScript, and the README notes that data fetching on the web side uses SWR. The API is a separate service, and the Makefile exposes it as an npm workspace: yarn workspace @omnivore/api dev. Content extraction is its own service too, split into a content-handler build and a puppeteer-parse build, which the Makefile combines into content_fetch by building both and then starting the content-fetch workspace.

That split matters when something breaks. A page that renders as a blank or partial article is a content-fetch problem, not an API problem, and the two run as separate processes. Mozilla's Readability library is named in the README as the tool used to make pages readable, so the extraction path is a known library rather than a bespoke parser. PDF handling uses PDF.js.

The client story is unusually broad for a project of this size. There is a native iOS app under apple/, an Android app under android/Omnivore, a progressive web app for Android, and browser extensions for Chrome, Safari, Firefox and Edge. GraphQL code generation is wired into both mobile clients: the Makefile copies packages/api/src/generated/schema.graphql into the Android project, and generates queries on iOS with Swift GraphQL. All of this lives in one monorepo managed with lerna and Yarn workspaces, which is why the root package.json declares workspaces: packages/*.

Installing Omnivore with docker compose

The README gives a short path for local development and points to ./self-hosting/GUIDE.md for a real server deployment. The development route clones the repository and starts the self-build compose stack, which the README says starts postgres, initializes the database, and starts the web and API services.

git clone https://github.com/omnivore-app/omnivore
cd omnivore/self-hosting/docker-compose/self-build
docker compose up

When the stack is up, the web app answers on port 3000. The README tells you to open http://localhost:3000 to confirm Omnivore is running, and database setup creates a test account with the address [email protected] and the password demo_password. You choose Continue with Email on the login screen. Change that account before the instance is reachable from anywhere but your own machine; it is created by the setup scripts, so it exists on every fresh database.

If you want to work on the frontend alone, the README splits the stack: run only the API and the content fetcher in Docker, then start the web app on the host.

docker compose up api content-fetch
cd packages/web
cp .env.template .env.local
yarn dev

The README notes that you must configure values in the new .env.local file for running the web service directly on your host machine. It does not enumerate those values in the text that is available here, so read .env.template before assuming defaults will work. Toolchain versions are pinned by Volta in the root package.json: Node 24.19.0 and Yarn 1.22.19.

Where self-hosting Omnivore gets expensive

The README is honest about one thing and quiet about several others. It says the cloud application was deprecated in November 2024 and that the community still exists on Discord, with the team endeavouring to keep things updated and bug fixes ongoing. That is a maintenance promise, not a support contract. There is no hosted fallback, no migration path back to a managed service, and no documented rollback procedure in the README for an upgrade that goes wrong.

The operational surface is larger than "one container". You are running postgres, the web frontend, the API server, and a content fetching microservice, plus whatever handles inbound email for newsletter articles. Each of those is a place where an upgrade can fail independently. The content fetcher is the one most likely to surprise you: it uses a headless Chromium process to render pages, and the README lists Chromium as a development requirement alongside Node and Yarn. Sites that block automated browsers will fail extraction regardless of how healthy the rest of the stack is.

Email ingestion is another boundary. Newsletter support is advertised, but the README does not describe the mail configuration in the text available here, and the acknowledgements credit community contributors specifically for "fixes for SNS Emails" and "fixes for emails". That suggests the email path has needed patching by outside contributors, which is worth knowing before you route a real newsletter subscription through it. The self-hosting guide is the place to check what is actually required.

Omnivore against Wallabag and the browser reading list

The obvious comparison is Wallabag, the long-running self-hosted read-it-later server. Both give you an article list, extraction, tagging and a mobile client, and both put the database on your hardware. The difference is in where the data is meant to end up. Wallabag is built around the reading list and its own API; Omnivore is built around highlights flowing into a notes system, which is why Logseq and Obsidian plugins are first-class entries in the README rather than community add-ons.

The second alternative is doing nothing: the reading list built into your browser. That option has no server, no postgres, no Chromium dependency and no upgrade work. It also has no cross-device highlight sync, no PDF annotation, no newsletter ingestion, and no way to pull your annotations into a graph. Omnivore is not a better bookmark button. It is a small content pipeline, and you should only run it if you want the pipeline.

A third case is worth naming because it is the wrong one. If you want a managed service with an uptime expectation and someone to call, Omnivore is not that product any more, and the README says so directly. Choosing it means accepting that you are the operator.

Licence and the cost of running your own instance

The repository is licensed AGPL-3.0, and the root package.json records the licence field as AGPL-3.0-only. That is a strong copyleft licence with a network clause: if you modify Omnivore and let other people use it over a network, the AGPL's source-disclosure obligations are generally understood to apply to your modified version. For a personal instance this is unlikely to matter. For a company that wants to fork Omnivore, rebrand it, and offer it to customers, it matters a great deal. This is a description of the licence, not legal advice; talk to a lawyer about your specific case.

Upgrade cost is the other recurring expense, and it is mostly your time. The repository is a lerna monorepo with pinned toolchain versions, a GraphQL codegen step, and separate build targets for the content handler and the puppeteer parser. The Makefile shows that mobile clients depend on a generated schema file copied out of the API package, so an API schema change can ripple into the Android and iOS builds. The last push to the repository was on 2026-09-19, and the most recent releases listed are Android builds from late August 2026, which tells you where recent activity has concentrated. It does not tell you how smooth an upgrade from your current version will be.

Editorial conclusion

Adopt Omnivore if you want highlighting, notes, PDF support and Logseq or Obsidian export on hardware you control, and if you accept that the hosted service no longer exists. Do not adopt it if you expect a vendor to run the database, the content fetcher and the mail ingestion for you, or if you need a product with a commercial support contract. Before committing, verify that docker compose up in self-hosting/docker-compose/self-build completes on your machine, that the [email protected] login works, and that the content-fetch service can reach the pages you actually read.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. omnivore-app/omnivore on GitHub
4. README
5. Releases