Glean: A Self-Hosted RSS Reader That Wants to Be a Knowledge Base
A self-hosted RSS reader and personal knowledge management tool.
At a glance
- What is it?
- Glean bundles an RSS reader, bookmark store, background sync worker and a Milvus vector database into one Docker Compose stack. The README describes it as still in development and not ready for production, which is the most important line in the repository.
- Who is it for?
- Glean suits people who already run Docker Compose on their own hardware, want OPML import and export, and are willing to accept the project's own warning that it is not ready for production. It is the wrong choice if you need a reader you can depend on today, or if you object to AGPL-3.0 terms, since the network copyleft clause applies to modified versions you expose to other users.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap Glean Is Trying to Fill
Most hosted RSS readers treat the feed list as the product. You subscribe, you read, you mark things read, and the service keeps whatever analytics it wants. Glean takes a different position: the feed list is only the input. The README describes it as a self-hosted RSS reader and personal knowledge management tool, and the feature list reflects that framing. RSS and Atom subscriptions sit alongside folders, tags, bookmarks, and a read-later queue with auto-cleanup. External URLs can be bookmarked, not just feed items. The stated goal is to help information-heavy consumers manage reading through RSS aggregation, which is a narrower claim than it sounds. The audience is someone who already runs a home server or a small VPS and finds the export options of commercial readers insufficient. If you read twenty feeds a week and never revisit an article, this is more machinery than the problem requires. If you treat saved articles as a reference collection you want to query later, the bookmark and tagging layer is the part that matters, and the planned AI features are aimed at that same layer.
What Actually Runs in the Stack
The default docker-compose.yml starts seven services, according to the deployment section of the README. The web app listens on port 80. A separate admin dashboard listens on 3001. Behind those sit a FastAPI backend, a worker process for background tasks, PostgreSQL, Redis, and Milvus. The worker handles feed fetching and cleanup, and the README states background sync runs every 15 minutes. Redis serves as the task queue, with arq named as the queue library on the backend side. The frontend is React 18 with TypeScript, Vite, Tailwind CSS, Zustand and TanStack Query. Milvus is the piece worth pausing on. It is a vector database, and the README ties it to smart recommendations and preference learning, which it labels Phase 3. That means the full deployment ships a vector store for features the README itself lists as planned work in progress. The lite Compose file exists precisely for this: it drops Milvus for operators who do not need Phase 3 features. For a reader that currently does subscriptions, folders, tags and bookmarks, the full stack is a lot of moving parts, and the lite file is the more honest starting point unless you are specifically testing the recommendation work.
Deployment Path and the Variables You Must Change
Installation is a two-command sequence. The README gives this example: download docker-compose.yml with curl from the raw GitHub URL, then run docker compose up -d. The web interface comes up on http://localhost and the admin dashboard on http://localhost:3001. An admin account is created automatically with the username admin and the password Admin123!, and the README marks that password with a warning to change it in production. The same applies to SECRET_KEY, described as the JWT signing key, and POSTGRES_PASSWORD, which defaults to glean. Both are flagged in the configuration table as requiring change. The supported way to set them is a .env file created before the first start, and the README shows generating SECRET_KEY with openssl rand -base64 32. Other keys in the table are WEB_PORT (default 80), ADMIN_PORT (default 3001), and CREATE_ADMIN, which defaults to true. Setting CREATE_ADMIN=false suppresses the automatic account, and the README then has you run docker exec -it glean-backend /app/scripts/create-admin-docker.sh to create one by hand. A full .env.example is available for download and the README points to it for the complete option list. Pre-built images live on GitHub Container Registry under ghcr.io/leslieleung/glean-backend, glean-web and glean-admin, with linux/amd64 and linux/arm64 builds. Pre-release testing uses an IMAGE_TAG variable, either exported or set inline before docker compose up.
The Warning Label Is Not Decoration
The README carries an important callout stating the project is still in development and is not ready for production use. That is unusually direct, and it should be read literally. A reader that syncs feeds every 15 minutes is stateful infrastructure. If it breaks mid-upgrade, you lose the read/unread state, the tags, and the bookmarks you accumulated. The release history offers some context: v0.2.7 in June 2026, v0.2.6 earlier the same month, and v0.2.5 back in January 2026. The gap between v0.2.5 and v0.2.6 is roughly four months, which suggests the project moves in bursts rather than continuously. The version number itself, still in 0.2.x, is consistent with the development warning. There is also a structural limitation worth naming: the feature list separates core features from planned ones, and several items people might assume are present are not. Smart recommendations, the rule engine, AI summary generation, full content fetch for truncated feeds, the Chrome extension, and the mobile PWA are all listed as work in progress. Full content fetch in particular is a common reason to self-host a reader, since many feeds ship summaries only. Until that lands, Glean will show you whatever the feed provides. Anyone evaluating it should test their own feeds against that boundary before migrating.
Where Miniflux Draws the Line Differently
Miniflux is the obvious comparison for a self-hosted RSS reader, and the difference is architectural rather than cosmetic. Miniflux is a single Go binary backed by PostgreSQL, with a deliberately minimal feature set and an API that third-party clients consume. Glean is a multi-service TypeScript and Python application with a React frontend, a separate admin dashboard, a task queue, and an optional vector database. The practical consequence is operational weight. A Miniflux deployment is one process to upgrade and one database to back up. Glean is a Compose stack where the backend, worker, web frontend and admin dashboard version independently through image tags, plus Redis and PostgreSQL state to preserve. In exchange, Glean ships a first-party web UI with folders, tags and bookmarks built in, and the admin dashboard handles user management and system monitoring without extra tooling. If you want a reader that stays out of the way and you are happy to pick a client, Miniflux's approach is leaner. If you want the reading interface and the organizational layer to be the same product, and you accept the development warning, Glean's bet is that the integration is worth the extra containers.
Maintenance Load and the AGPL Question
Upgrades run through image tags. The README documents IMAGE_TAG for pinning a specific version, which means you can hold a working release while testing a newer one, and the pre-release note states that pre-release builds do not trigger auto-updates for Electron apps. That is a small but useful detail: it implies an Electron client exists or is planned, though the README does not otherwise describe one, so treat that as unconfirmed. The database is the part that needs care. PostgreSQL and Redis both hold state, and Milvus holds vectors if you run the full stack, so a backup strategy has to cover three stores rather than one. For development work, the repository uses a Makefile with targets including make up for infrastructure, make db-upgrade for first-time schema initialization, make dev-all to start services, and pre-commit hooks installed via make pre-commit-install. Those hooks run ruff format, ruff lint and pyright on the backend, ESLint and Prettier on the frontend, plus file-level checks. On licensing, the repository is AGPL-3.0. The practical reading is that if you modify Glean and let other people use it over a network, the licence's network clause is generally understood to require offering them the modified source. Running an unmodified copy for yourself does not trigger that. This is a description of the licence, not legal advice; if you plan to fork and host for others, get your own reading of the terms.
Who Should Install It, and What to Check First
Glean fits a specific profile: you already run Docker Compose, you want your reading data on hardware you control, you care about OPML import and export so you are not locked in, and you are comfortable with a 0.2.x project that tells you plainly it is not production ready. The lite Compose file makes that a smaller commitment, since it removes Milvus and the vector workload entirely. It does not fit anyone who needs a reader to be dependable tomorrow, and it does not fit anyone who wants full article text from summary-only feeds today, because that feature is still listed as planned. Before deploying, three things are worth verifying against the repository rather than the README summary. First, read .env.example in full, since the configuration table in the README is described as partial. Second, confirm what the lite Compose file omits beyond Milvus, because the README only states that it excludes the vector database. Third, decide your upgrade policy up front using IMAGE_TAG, because the release cadence between v0.2.5 and v0.2.6 suggests you will not get frequent small updates. Set SECRET_KEY, POSTGRES_PASSWORD and ADMIN_PASSWORD in a .env file before the first docker compose up -d, and the default admin account never exists in a guessable form.
Editorial conclusion
Glean suits people who already run Docker Compose on their own hardware, want OPML import and export, and are willing to accept the project's own warning that it is not ready for production. It is the wrong choice if you need a reader you can depend on today, or if you object to AGPL-3.0 terms, since the network copyleft clause applies to modified versions you expose to other users. Before committing, check the .env.example file for the full variable list, confirm whether the lite Compose file covers the features you actually need, and verify that the default admin credentials have been replaced.
Community notes