Omnivore dropped its cloud in 2024 and now asks you to run the stack

The cloud application was deprecated in November 2024

The single most consequential line in this project is an admonition at the top of the README: Omnivore is now a completely self-hosted application, and the cloud application was deprecated in November of 2024. That removes the hosted tier from the product. There is no Omnivore server you can sign up for, no account created for you, and no sync service connecting your phone to somebody else's database. The project still describes itself as a complete read-it-later solution with highlighting, notes, search, sharing, labels and offline support, and every one of those features now resolves against a server you run. Anyone who follows the README expecting a signup page will find the deploy guide instead. The self-hosting instructions live in one file, self-hosting/GUIDE.md, referenced repeatedly in the README.

docker compose up creates an account whose password is printed in public

The whole local stack is three commands. It starts postgres, initializes the database, and brings up the web frontend, the API server and the content fetching microservice.

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

You then open http://localhost:3000 and log in with the test account created during database setup: [email protected] with the password demo_password, using the Continue with Email option. This is a development convenience, and it is also the sharpest edge in the setup. Those credentials are printed in a public README, so any deployment that keeps them has a publicly known login. The steps after the compose call stop being a tutorial and start being your job.

Saving an article needs a Chromium that you install on the host

Reading a page is the core act of a read-it-later tool, and Omnivore does it through a service named puppeteer-parse. To run that service on your own machine instead of inside Docker, the project asks you to install and point at Chromium yourself.

brew install chromium --no-quarantine
export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
export CHROMIUM_PATH=`which chromium`

The two exports exist because the install is manual: the download is skipped so the tool does not fetch its own copy, and the path is handed over explicitly. The consequence for anyone not on a Mac is immediate. This is a Homebrew command, and no Linux or Windows equivalent is written down here. Without a resolved Chromium path the parser has no browser to drive, and article capture is the first thing that stops working.

The web app runs on your host while the API stays in a container

If you are changing the frontend rather than the backend, the project splits the stack between your host machine and Docker.

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

The five values you then write into .env.local decide which host each piece of the frontend talks to.

NEXT_PUBLIC_BASE_URL=http://localhost:3000
NEXT_PUBLIC_HIGHLIGHTS_BASE_URL=http://localhost:3000
NEXT_PUBLIC_LOCAL_BASE_URL=http://localhost:3000
NEXT_PUBLIC_SERVER_BASE_URL=http://localhost:4000
NEXT_PUBLIC_LOCAL_SERVER_BASE_URL=http://localhost:4000

The NEXT_PUBLIC_ prefix is the trap. These values are compiled into the client bundle and served to the browser, so nothing secret belongs in .env.local even though the file sits in your source tree next to a template you copied.

The Makefile copies generated files into the native apps by path

The iOS and Android clients do not generate their GraphQL layer on the fly. The android_graphql_gen target copies a checked-in schema from the API package into the Android app.

The webview_gen target builds the shared reader package and copies the resulting bundle into two destinations.

yarn workspace @omnivore/appreader build
cp mobile/appreader/build/bundle.js mobile/apple/OmnivoreKit/Sources/Views/Resources/bundle.js
cp mobile/appreader/build/bundle.js mobile/android/Omnivore/app/src/main/assets/bundle.js

The consequence is a silent failure mode. Change the GraphQL schema on the server and forget these targets, and the native apps keep compiling against the previous schema and keep rendering the previous reading view. Nothing in the build stops you. These copies are manual, and the Makefile records the two destination paths.

There is no version to quote: the tags are Android only, and Volta pins the toolchain

The three most recent releases are android-0.230.0 from 2026-10-14, android-0.229.0 from 2026-08-28, and android-0.228.0 from 2026-08-27, all with the android- prefix and an incrementing minor number. None of them tags the API, the web app or the container images. Meanwhile the root package.json declares version 1.0.0 and private true, with workspaces covering packages/*, packages/mail/* and packages/content/* and no individual package versioned in that file. So there is no single number to quote when someone asks which Omnivore they are running. Pinning a self-hosted deployment means pinning a commit or a container image, and the tags in the releases list say nothing about the server side. The build side is pinned harder, by contrast. Volta locks node 24.22.1 and yarn 1.22.19, Lerna 7.4.1 runs the workspaces, and the root scripts are lerna run --stream test, lerna run --parallel lint, lerna run build and graphql-codegen. The deploy:web script is vercel --prod, so that route needs a Vercel account and is closed to anyone self-hosting.

Community patches mark Minio and email as the fragile parts of self-hosting

The README credits specific people for specific self-hosting repairs, and reading the credits is the closest thing to a known-issues list. Poudlardo provided a Podman-compose file for self-hosting. leopku fixed build issues with the v3 manifest. travisemslander-fn provided fixes for SNS Emails, and andrew-craig with lukebtaylor provided further email fixes. Benature provided fixes for Minio. rbarbazz provided an HTML toggle for notes, and pgrosslicht made assorted fixes to the iOS applications. jacksonh, sywhb and satindar provided the initial repository and core functionality. Read that list as a dependency map. Object storage and outbound email each needed community work, and both are the kind of service that turns into an operational chore once you leave the hosted version.

The name is answered by griddles, holsters and pet food

The name Omnivore is shared with unrelated products, from griddles to holsters to pet food, so searching for the project by name alone is unreliable. Search on omnivore-app on GitHub instead, where the project namespace is unique.

Editorial conclusion

Omnivore is a reasonable choice for a group that already runs containers and wants a read-it-later stack under its own control, and a poor choice for anyone who wants an account that already works. Before you commit, read self-hosting/GUIDE.md, because the README is a summary of it. Replace the demo credentials the setup creates, because they are printed in public. Decide whether you can host Minio and an email path, since community patches exist for both. And treat the Android tag numbers as the only published version signal, since nothing here tags a server or a web release.

Frequently asked questions

Official sources

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