We-MP-RSS: Turning WeChat Official Accounts into RSS Feeds

The gap We-MP-RSS fills: WeChat accounts have no feeds

WeChat Official Accounts publish inside a closed client. There is no public feed endpoint a reader can subscribe to, so anyone who wants to follow a set of accounts has to open WeChat and scroll. We-MP-RSS targets that specific gap. It logs into WeChat, collects article content from accounts you name, and republishes it as an RSS feed that any standard reader can consume. The README describes it as a tool for subscribing to and managing WeChat Official Account content that provides RSS subscription functionality. The audience is narrow and identifiable: people who already live in an RSS client such as Folo (the README links to Folo specifically and ships a screenshot of it), who read Chinese-language WeChat accounts, and who are willing to run a container to get those articles into that client. It is not a general-purpose scraper and not a hosted service. The homepage at werss.csol.store exists, but the README's own instructions are all local Docker, which tells you the intended deployment is self-hosted.

Architecture: FastAPI backend, Vue frontend, SQLite or MySQL

The repository states a front-end and back-end separation architecture. The backend is Python with FastAPI, the frontend is Vue 3 with Vite, and the database is SQLite by default with MySQL as an option. A single Docker container serves the web interface on port 8001 and expects a data directory mounted at /app/data, which is where the SQLite file and presumably the authorization state live. Collection runs on a schedule rather than on demand, which is why the feature list includes scheduled automatic content updates and authorization expiration reminders. The README also mentions a cascade system described as a parent-child node architecture with intelligent task distribution for scaling collection, and an environment exception statistics feature that tracks failures when accessing WeChat articles. Both are named in the feature list but not explained in the material available here, so treat them as documented capabilities rather than understood mechanisms. The optional weread_mp collection mode for MP_WXS_* feeds is documented separately in docs/weread-mp.md, which the README links but does not reproduce.

Getting it running: one docker run command and a mounted volume

The README gives a single command for the official image: docker run -d --name we-mp-rss -p 8001:8001 -v ./data:/app/data ghcr.io/rachelos/we-mp-rss:latest. The same command is repeated for the Docker Hub image rachelos/we-mp-rss:latest and for a China mirror at docker.1ms.run/rachelos/we-mp-rss:latest. After that you visit http://<your-ip>:8001/ and work through the web interface. The upgrade path is also given verbatim: stop the container, remove it, pull the latest tag, and run the same command again with your own parameters restored. The README warns explicitly that if you added other parameters you must modify the run command accordingly, which is a real operational hazard with this pattern. Anything you configured outside the mounted volume, such as extra environment variables or port mappings, disappears with the removed container. The volume mount at ./data is the only state the README guarantees. Configuration for filtering lives in the web UI rather than in files: the Filter Rules page lets you add rules with a name, an optional official account, a priority from 0 to 100 where higher runs first, and filter configuration covering element IDs, CSS classes, CSS selectors, attribute matches and regular expressions. Rules created through POST /api/filter-rules accept an mp_id field, where an empty array means the rule is global.

The authorization session is the fragile part

The README lists QR code authorization as a screenshot and lists authorization expiration reminders as a feature. That combination is the clearest signal about how this tool actually behaves: it holds a WeChat session obtained by scanning a QR code, that session expires, and the software will remind you when it does. Between expirations, scheduled collection runs against WeChat on your behalf. This is the design constraint that shapes everything else. A feed produced this way is only as reliable as the session behind it. If the session lapses and nobody re-scans, collection stops and the feed goes quiet, which in an RSS reader looks identical to an account that simply stopped publishing. Anyone evaluating this should plan for who re-scans the code and how they will notice the reminder. The environment exception statistics feature exists precisely because access failures happen often enough to be worth counting. The README does not state how long a session lasts, whether multiple accounts can share one authorization, or what happens to scheduled jobs during an outage, and I cannot confirm any of that from the supplied material.

Exports, notifications and the API surface

Beyond RSS, the feature list includes export to md, docx, pdf and json, which makes the tool useful as an archiving layer rather than only a reader feed. Custom notification channels and webhook support are listed, and the feature list mentions headers and cookies authentication for message tasks when calling webhooks, meaning outbound webhook calls can carry custom headers. The filter rules API shown in the README covers listing rules with GET /api/filter-rules and creating them with POST /api/filter-rules. HTML filtering matters more here than in a typical scraper because WeChat article bodies routinely contain promotional blocks and recommendation lists that pollute a feed. The rule model is sensible: global rules apply when no account is selected, account-specific rules override for particular accounts, and priority decides order. The configuration cache feature supports Redis, Memcached or in-memory caching, which is an odd thing to advertise for a single-container deployment but makes sense if you run multiple instances against one MySQL database. The README does not describe how the cache is invalidated, so I would not enable Redis caching without reading the source first.

Where it is the wrong tool, and what to use instead

If you want WeChat content without maintaining a logged-in session, this is the wrong tool, because its collection model depends on that session by design. The natural alternative in the same space is RSSHub, which the repository itself lists as a topic tag. The difference in approach is fundamental. RSSHub is a routing framework: you request a route for a given source, it fetches and transforms on demand, and it covers hundreds of sites through community-maintained routes. We-MP-RSS is a stateful service that maintains a WeChat authorization, schedules collection in the background, stores articles in its own database, and serves feeds from that store. RSSHub gives you breadth and statelessness; We-MP-RSS gives you persistence, a management UI, per-account HTML filtering, and export to document formats. If your need is one feed from one account and you already run RSSHub, adding a second container with its own database and its own QR-code maintenance burden is probably not worth it. If your need is a curated set of Chinese accounts, cleaned of promotional HTML, archived to PDF, and delivered on a schedule, RSSHub's route model does not give you the filtering or the archive. That is the trade.

Maintenance cost, licensing and what the metadata does not say

The release cadence visible in the repository is modest: v1.5.1 and v1.5.2 in April 2026, v1.5.3 in August 2026, with the last push in September 2026. That is roughly a few releases a year, which suggests a project that is maintained but not moving fast. Upgrading means pulling a new image and recreating the container, and because the README's upgrade instructions delete the container, any configuration you passed as flags has to be reapplied by hand each time. Budget for that. The dependency surface is Python 3.13.1 or later, FastAPI, Vue 3, and optionally MySQL plus Redis or Memcached, so the operational footprint grows if you enable the optional pieces. On licensing, the repository metadata reports NOASSERTION while the README displays an MIT badge. Those two signals conflict, and I am not in a position to resolve which governs. Check the LICENSE file in the repository before you redistribute anything or build it into a product. Nothing here is legal advice; it is a note that the two sources disagree and that disagreement is worth ten minutes of your time before adoption.

Editorial conclusion

Adopt We-MP-RSS if you already run Docker, want WeChat Official Account articles inside a standard RSS reader, and can accept re-scanning a QR code when the authorization session expires. Do not adopt it if you need a feed that survives without a logged-in WeChat account, or if you cannot host a persistent volume. Before committing, verify three things: that the QR authorization flow completes against your account, that the weread_mp collection mode works for the MP_WXS_* feeds you care about, and that the license terms in the repository match how you intend to use it, since the GitHub metadata reports NOASSERTION while the README badge says MIT.

Official sources

1. Issues
2. Project website
3. rachelos/we-mp-rss on GitHub
4. README
5. Releases