# zenfeed: an AI pipeline that turns RSS feeds into filtered briefs and alerts

> zenfeed is a Go service that scrapes RSS and RSSHub sources, runs every item through configurable LLM prompts, stores the results, and serves them as a reader, a query API and email notifications. It is aimed at heavy RSS users who want automated filtering, not at people who want a hosted reader with accounts.

**glidea/zenfeed** — Make RSS 📰 great again with AI 🧠✨!! 数据打标请联系 glidea123 (数万并发随时狂飙)

- Repository: https://github.com/glidea/zenfeed
- Website: https://zenfeed.xyz
- Stars: 1,714 · Forks: 109
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/glidea-zenfeed

## The problem zenfeed targets: RSS without the firehose

The README opens with an argument rather than a feature list. RSS solved distribution but never solved triage, and the project quotes the standard explanation for why: readers have to manage their own source list and filter the noise themselves. Its stated goal is to keep the control that comes with subscribing directly to sources while using an LLM to do the filtering, summarising and scoring that a human would otherwise do by hand.

The intended audience is narrow and the README says so. It lists three groups: existing RSS users who want an AI reader alongside zenfeed-web, people looking for a replacement for hosted tracking products such as 万物追踪, and developers who want a pipeline they can script. The third group gets the most detail, which tells you where the project's centre of gravity is. This is not a consumer reader with a sign-up page. It is a self-hosted engine with a web front end bolted on, and the front end lives in a separate repository.

## How the pipeline works: label sets, rewrites and scheduled runs

The mechanism the README describes most precisely is the rewrite pipeline. Each piece of content is abstracted as a set of labels, and at each node of the pipeline you can run a custom prompt against those labels to score, classify, summarise or filter. The project compares the model to Prometheus relabeling, and the analogy holds in the sense that matters: transformation is declarative, ordered, and applied per item, not per feed.

Downstream of the rewrites, the labels become queryable. The README describes free-form querying, filtering, routing and notification on top of processed labels, with notification routing configured under notifyRoute and notifySubRoutes and delivery channels under notifyChannels (email is the documented channel, configured through gomail.v2 in the dependency list). Scheduling is a first-class config section, which is what makes the daily brief possible: the service collects items from a time window and delivers one digest instead of a stream.

The storage layer is worth noting because it constrains deployment. The Go module list includes nutsdb, an embedded key-value store, and mmap-go, plus minio-go for object storage. There is no external database in the compose file, so state lives in the data volume. That keeps installation to one command, and it also means your feed history is a directory you need to back up yourself. The README does not document a migration or export path for that data.

## Installing zenfeed with docker-compose and adding a first source

The README's quick start assumes Docker and an API key. It defaults to siliconflow models, Qwen/Qwen3-8B for generation and Qwen/Qwen3-Embedding-4B for embeddings, and notes that the compose file can be edited to point at another provider. On macOS or Linux the documented flow downloads the compose file and starts the stack with the key passed as an environment variable.

```bash
curl -L -O https://raw.githubusercontent.com/glidea/zenfeed/main/docker-compose.yml
API_KEY="sk-..." docker-compose -p zenfeed up -d
```

The compose file brings up three services. zenfeed-web publishes port 1400 and is what you open in a browser. The zenfeed service publishes 1300, 1301 and 9090, and mounts two named volumes, data and config. rsshub runs on port 1200 and is wired into the config as scrape.rsshub_endpoint, so RSSHub routes work without extra configuration. On first start the entrypoint copies /app/config.init.yaml to /app/config/config.yaml only if that file does not already exist, which is why later edits should go through the config volume or the web UI rather than the init file.

```yaml
llms:
  - name: general
    default: true
    provider: siliconflow
    model: Qwen/Qwen3-8B
    api_key: ${API_KEY:-your-api-key}
  - name: embed
    provider: siliconflow
    embedding_model: Qwen/Qwen3-Embedding-4B
    api_key: ${API_KEY:-your-api-key}
scrape:
  rsshub_endpoint: http://rsshub:1200
```

Once the stack is up, the README says to open http://localhost:1400 and add a source through the web UI. It adds two cautions: the host running zenfeed must be able to reach the source site, and after adding a feed you should wait a few minutes for content to arrive, because scraping and processing are not instantaneous. For a first real test, add one feed you already read daily and watch whether the rewrite prompts produce labels you would actually filter on. If they do not, the problem is the prompt, not the pipeline.

## No authentication: the limitation that decides where you can run it

The README carries a warning box that is more consequential than any missing feature: zenfeed has no authentication mechanism, and exposing the service to the public internet may leak your API_KEY. There is no mention of users, sessions, tokens or roles anywhere in the README. The web UI on port 1400 talks to the API on 1300 with no credential in between.

That single fact rules out a whole class of deployments. You cannot hand a zenfeed instance to a team and expect per-person feeds, because there is no concept of a person. You cannot put it on a public VPS and forget about it, because the README's own advice is to restrict the security group to trusted IPs and access it at http://<your-IP>:1400. For a single operator on a home network or behind a VPN, this is fine. For anything shared, it is not.

A second limitation is quieter. The README states that DeepWiki's description of the project is not fully accurate, which is a useful signal about how much of the surrounding documentation ecosystem you should trust. The authoritative sources are the config and rewrite documents in docs/, and the README's own sections covering source management and migration are only partially reproduced in the repository front page. If you are migrating from Follow, the README points to docs/migrate-from-follow.md rather than describing the process inline.

## zenfeed compared with a plain RSS reader and with Feedly AI

The obvious alternative is a conventional reader such as FreshRSS or Miniflux: fetch, store, display, with rules based on keywords or regex. The difference is where the decision happens. A conventional reader filters on strings the author wrote. zenfeed filters on labels an LLM produced from the content, and those labels can be numeric scores, categories or summaries. That lets you write a rule like "notify me when this source publishes something about a specific event" without the source tagging it that way. The cost is that every item consumes model calls, so your feed volume becomes a bill and a latency budget rather than just disk usage.

The README itself positions zenfeed against Feedly AI and against hosted tracking products, and the honest difference is control versus convenience. Feedly AI is a managed service with an account and a subscription; zenfeed is a compose file, two volumes and your own API key. You get the ability to change the prompt, swap the model, route notifications to your own webhook and query the store directly through the Query API. You also get the responsibility for uptime, backups and the model provider relationship.

There is a third comparison worth drawing, with RSSHub, which zenfeed bundles rather than replaces. RSSHub turns sites that have no feed into feeds. zenfeed consumes feeds, including RSSHub's, and decides what to do with them. Running both is the normal configuration, not an either-or choice.

## Maintenance, releases and what AGPL-3.0 means here

The repository is not archived and the last push was on 2026-07-10. Releases are infrequent rather than continuous: v0.5.1 in July 2025, v0.6.0 in August 2025, and v0.7.0 in November 2025, whose release note mentions RSSHub AccessKey support. If you depend on a specific upstream behaviour, pin the image tag rather than using latest, because the compose file as written pulls glidea/zenfeed:latest and glidea/zenfeed-web:latest.

Upgrade cost is mostly configuration drift. The entrypoint only seeds config.yaml when the volume is empty, so a new image can ship a changed init config that your existing volume will never see. After an upgrade, diff the new config.init.yaml against your config volume rather than assuming the defaults moved with the image. The bundled rsshub service is pinned to diygod/rsshub:2024-12-14 in the compose file, so RSSHub fixes do not arrive unless you change that tag yourself.

The licence is AGPL-3.0, which is a network copyleft licence. The practical consequence people care about is that if you modify zenfeed and let users interact with it over a network, the licence's terms reach that modified version. Whether that matters depends on whether you plan to distribute or expose a modified build. This is not legal advice; if you intend to offer zenfeed as part of a product, read the licence text and talk to someone qualified.

## Conclusion

zenfeed fits engineers and heavy RSS users who already curate their own sources and want LLM scoring, rewriting and email briefs over them, and who can run Docker on a host with a reachable model API key. It does not fit anyone who needs multi-user accounts, per-user isolation or a hosted reader, because the README states there is no authentication mechanism and warns that exposing the service publicly can leak your API_KEY. Before adopting it, check three things in the repository: whether the docker-compose.yml model defaults (Qwen/Qwen3-8B and Qwen/Qwen3-Embedding-4B on siliconflow) match a provider you can pay for, whether the config volume already holds a config.yaml so your edits survive the init copy, and whether the AGPL-3.0 licence is acceptable for how you plan to run and modify it.

## FAQ

### What is zenfeed and who is it for?

zenfeed is a self-hosted AI information hub that combines an RSS reader with a pipeline that scores, classifies, summarises and filters items using LLM prompts. The README targets three groups: experienced RSS users, people looking for a replacement for hosted tracking products, and developers who want a scriptable engine with an open API.

### How do I install zenfeed?

The README documents a docker-compose deployment: download docker-compose.yml, then run API_KEY="sk-..." docker-compose -p zenfeed up -d. The stack starts zenfeed-web on port 1400, zenfeed on 1300, 1301 and 9090, and a bundled RSSHub on 1200.

### Does zenfeed need an API key and which models does it use by default?

Yes. The default configuration uses siliconflow with Qwen/Qwen3-8B as the general model and Qwen/Qwen3-Embedding-4B for embeddings, with the key supplied through the API_KEY environment variable. The README notes that the compose file can be edited to use another provider or model.

### Is zenfeed safe to expose on a public server?

The README warns that zenfeed has no authentication mechanism and that exposing it publicly may leak your API_KEY. It advises accessing it at http://<your-IP>:1400 with firewall or security group rules that allow only trusted IPs.

### What licence is zenfeed released under?

The repository lists AGPL-3.0. That is a network copyleft licence, so the terms apply to modified versions that users interact with over a network; the README does not discuss licence implications further.

## Sources

- [glidea/zenfeed on GitHub](https://github.com/glidea/zenfeed)
- [License: AGPL-3.0](https://github.com/glidea/zenfeed/blob/main/LICENSE)
- [Project website](https://zenfeed.xyz)
- [README](https://github.com/glidea/zenfeed/blob/main/README.md)
- [Releases](https://github.com/glidea/zenfeed/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/glidea-zenfeed