zenfeed: an AI relabeling pipeline for RSS feeds, written in Go

The problem zenfeed picks: RSS selection cost, not RSS supply

The README frames the project around a specific failure of plain RSS rather than around a shortage of feeds. Its own summary of the history is that RSS asks a lot of the reader: you need strong filtering habits and self-discipline to manage subscriptions, and without them the feed becomes noise. The stated goal is to keep the control and source quality that come with active subscription while using AI to handle the filtering and summarization that most people will not do by hand. That places zenfeed in a different category from a generic reader. It is aimed at people who already have opinions about which sources are worth reading, and who want a machine to apply those opinions consistently. The README also names a second audience explicitly: people looking for an alternative to 万物追踪 style tracking products, where the emphasis is on high-quality, customizable sources rather than broad crawl coverage. A third group is described as information-anxiety sufferers, for whom the daily brief feature exists so that reading happens once at a scheduled time instead of continuously. If you do not already maintain a feed list, the project's value proposition does not apply to you yet.

Label sets and relabeling: the mechanism behind the pipeline

The README compares the processing model to Prometheus relabeling, and that comparison is the clearest description of the architecture available in the material. Each piece of content is abstracted as a set of labels. The pipeline has nodes, and at each node you can run a custom prompt against those labels to score, classify, summarize or filter the item. The output of one node becomes the input to the next, so ordering matters: a scoring step placed after a filtering step sees fewer items than one placed before it. After processing, the resulting labels are what you query, filter, route and notify on. That is the whole design in one sentence, and it explains why the project ships so much YAML. The routing and notification layer is described as configurable through notify route and notify route sub_routes keys, with email as one documented channel. The README points to a separate rewrite rules document for the details, and to a config document for scheduler settings. The important consequence for anyone evaluating this: the AI is not a chatbot bolted onto a reader. It is a transformation stage inside a declarative pipeline, and the pipeline is the product.

What the API surface actually exposes

The README lists four interfaces: a Query API, an RSS Exported API, a Notify Webhook, and the YAML configuration itself. The RSS Exported API is the one worth pausing on, because it means the output of your pipeline can be re-emitted as a feed. If you already have a reader you like, you can point it at zenfeed's exported feed and keep your existing client while the filtering happens upstream. The Query API suggests the same for search-shaped access, and the README describes the combination of custom trusted sources with these interfaces as a fast personal AI search engine, which is a claim about intended use rather than a measured result. The Notify Webhook gives you the escape hatch when a rule fires: rather than reading a feed, you get a call to an endpoint you control. There is also an MCP server mode, and the topics list includes mcp and mcp-server, so the intent is that an MCP-speaking client can consume the processed content. The README references an MCP page but does not show a tool listing or a sample invocation, so the exact tool names and argument shapes are not something I can state from this material. Check the repository docs before designing an integration around it.

Getting it running: two commands and an API key

The README gives a one-minute path. On Mac or Linux you download the compose file and start it with the key passed as an environment variable:

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

On Windows PowerShell the equivalent is Invoke-WebRequest to fetch docker-compose.yml, then $env:API_KEY = "sk-..."; docker-compose -p zenfeed up -d. The service then answers on http://localhost:1400. Two defaults matter here. First, the README states zenfeed uses SiliconFlow model services by default, with Qwen/Qwen3-8B for generation and Qwen/Qwen3-Embedding-4B for embeddings, and that changing provider or model means editing docker-compose.yml with reference to docs/config-zh.md. Second, the configuration is declarative YAML, and the README links a config document for scheduler settings, notification channels and routing. The README warns that after adding a source, zenfeed needs to reach the origin site and you should wait a few minutes for content to arrive. It also links a migration guide for people coming from Follow, which implies the source list format is close enough to be worth converting rather than retyping. Note that the configuration documentation is written in Chinese; the README's documentation links point to -zh.md files.

No authentication: the limitation that decides your deployment shape

The README states plainly that zenfeed has no authentication mechanism, and that exposing the service to the public internet may leak your API_KEY. It recommends strict security group rules limited to trusted IPs. This is not a footnote. It determines where the service can live. A public VPS with port 1400 open to the world is a configuration the README explicitly warns against, and there is no documented reverse-proxy auth recipe in the supplied material to work around it. The second constraint is dependency on an external model provider. The default path assumes a SiliconFlow account, and the README's preparation section is built around obtaining one. If that provider changes its free tier, or if your content cannot leave your network, the default deployment stops being viable and you are into editing the compose file and the model configuration. A third constraint is documentation language: config-zh.md, rewrite-zh.md, query-api-zh.md, rss-api-zh.md and webhook-zh.md are all Chinese-language documents. That is workable but it raises the cost of every configuration change for readers who do not have Chinese. The README also notes that DeepWiki's description of the project is not entirely accurate, which is a useful warning if you were planning to rely on generated summaries instead of the repository docs.

Where zenfeed sits against a plain reader and against RSSHub alone

The honest comparison is not against another AI reader. It is against the two things you probably already run. A conventional reader such as FreshRSS or Miniflux gives you folders, unread counts and keyboard navigation, and its filtering is rule-based and predictable: you write a condition, items match or they do not. zenfeed's filtering is a prompt evaluated per item, which means the boundary between kept and dropped is fuzzy and can shift when you change model or provider. You gain semantic selection and summarization; you lose the guarantee that the same input always produces the same output. The other comparison is RSSHub. zenfeed consumes RSSHub as a source of feeds and can act as an MCP server in front of it, and version v0.7.0 added RSSHub AccessKey support, which suggests the maintainer treats RSSHub as a first-class upstream rather than a competitor. If your problem is that a site has no feed, RSSHub is the answer and zenfeed is not. If your problem is that you have thirty feeds and read four of them, that is the gap zenfeed is built for. The two compose naturally: RSSHub generates the feeds, zenfeed decides what survives.

Licence, upgrade cadence and what that costs you

zenfeed is AGPL-3.0. The practical implication, stated as a fact about the licence rather than as advice, is that if you modify zenfeed and offer it to users over a network, the AGPL's source-disclosure condition applies to your modified version. Running an unmodified copy for yourself does not trigger that. If you plan to embed zenfeed inside a hosted product, this is the clause to read before you build, and I am not in a position to tell you how it applies to your situation. On maintenance, the release history shows a steady but not frantic pace: v0.5.1 in July 2025, v0.6.0 in August 2025, v0.7.0 in November 2025, with the most recent push to main in July 2026. The release notes are terse and in Chinese; v0.7.0 is titled around RSSHub AccessKey support, v0.6.0 describes itself as an unremarkable update, and v0.5.1 mentions podcasts. That pattern suggests feature additions rather than a stabilization phase, which matters if you are pinning a version for a production deployment. Pin a tag, read the release note before moving, and expect the configuration surface to keep growing. The README also links two sibling projects, epub2rss and one-coffee, both of which are waitlist-stage rather than shipped, so they are not something to plan around today.

Editorial conclusion

Adopt zenfeed if you already curate RSS sources and want prompt-driven filtering expressed as YAML you can commit, and if you can run it on a host that is not reachable from the open internet, since the README states there is no authentication and an exposed port 1400 can leak your API_KEY. Skip it if you need a multi-user reader or an out-of-the-box hosted service. Before deploying, read docs/config-zh.md to confirm your model provider is supported, and check whether the notify route and email channel keys you need are documented in the version you pin.

Official sources

1. glidea/zenfeed on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases