We-MP-RSS: Turning WeChat Official Accounts into RSS, Markdown and PDF

The gap We-MP-RSS fills: WeChat articles have no feed

WeChat Official Accounts publish inside the WeChat client. There is no public per-account feed URL a normal RSS reader can poll, so following twenty accounts means opening WeChat twenty times a day and scrolling a timeline that mixes subscriptions with messages. We-MP-RSS exists to break that loop: it authenticates against WeChat, collects article content, and republishes each account as an RSS feed that any reader can subscribe to.

The intended user is someone who already runs a home server or a small VPS and treats RSS as their reading inbox. The README also points at Folo as a client, and the repository topics list rsshub, folo and mysql, which tells you the author expects this to sit alongside an existing RSS stack rather than replace it. It is not aimed at teams that want a managed product. Everything, including the login, runs in a container you operate.

Inside the container: FastAPI, Playwright and a SQLite file

The README describes a front-end and back-end split: Python plus FastAPI on the server, Vue 3 with Vite in the browser, and SQLite by default with MySQL as an option. The dependency list confirms the scraping side is browser automation, not plain HTTP: playwright, playwright-stealth, selenium and webdriver-manager are all pinned in requirements.txt. The Dockerfile sets BROWSER_TYPE=webkit and installs Chromium on top, with a comment stating the extra browser is for automatic refresh of the WeChat Reading cookie. So the data flow is: a scheduled job (APScheduler is in the dependency list) drives a headless browser through the WeChat web pages, parses the article HTML with BeautifulSoup and lxml, stores it, and FastAPI serves both the management UI and the generated feed.

Two design details are worth flagging. First, the Dockerfile pins a base image from the author's own registry and a Tsinghua PyPI mirror, which speeds up builds in China but means the image depends on infrastructure outside Docker Hub. Second, the README advertises a cascade system of parent and child nodes for distributing collection tasks, and the repository carries config-node.yaml plus several cascade debugging scripts and troubleshooting documents. That is a lot of operational surface for a feature the README describes in one line. Treat cascade mode as something to enable only after the single-node setup works.

Installing We-MP-RSS with Docker and adding a first subscription

The README's quick start is a single docker run. The container listens on port 8001 and expects a volume at /app/data, which is where the SQLite database and the WeChat Reading licence file live. Note that the README does not show a docker compose file in the quick start even though a compose directory exists in the repository.

docker run -d --name we-mp-rss -p 8001:8001 -v ./data:/app/data ghcr.io/rachelos/we-mp-rss:latest

After the container starts, open http://<your-ip>:8001/ in a browser. The README's screenshots show a login screen followed by a main interface, and .env.example lists USERNAME=admin and PASSWORD=admin@123 as the default credentials, so change those before exposing the port. The next screen is QR code authorization: you scan it with WeChat to give the service a session, which is what the collection job uses.

docker stop we-mp-rss
docker rm we-mp-rss
docker pull ghcr.io/rachelos/we-mp-rss:latest
docker run -d --name we-mp-rss -p 8001:8001 -v ./data:/app/data ghcr.io/rachelos/we-mp-rss:latest

That second block is the README's upgrade path, and it is the reason the volume mount matters: removing the container without -v ./data:/app/data would take your subscriptions and database with it. Once authorized, add a subscription from the web interface and the service generates a feed URL you paste into your reader. If you are in China and the ghcr.io pull is slow, the README offers a mirror, docker.1ms.run/rachelos/we-mp-rss:latest, and a Docker Hub image, rachelos/we-mp-rss:latest.

The QR session is the weak point

Every feature in this project rests on a WeChat session obtained by scanning a QR code, and the README's own feature list includes authorization expiration reminders. That phrasing is the honest part of the documentation: the session expires, the collector stops returning articles, and you scan again. There is no documented way to authenticate without a WeChat client, and the README does not document rollback for a failed authorization or a recovery procedure beyond re-scanning.

The second limitation is legal and structural rather than technical. The project scrapes pages through browser automation with stealth patches, and the repository ships files named atack.py and env exception statistics for tracking failures when accessing WeChat articles. Those names tell you the author expects the target pages to push back. If your use case requires guaranteed delivery of every article from an account, this is the wrong tool, because a single expired session silently stops the pipeline until you notice and re-authorize. The same applies if you want to run this for many accounts at high frequency: the cascade feature exists precisely because one node cannot scale collection, and the accompanying troubleshooting documents suggest it is not turnkey.

How it differs from RSSHub and hosted WeChat-to-RSS services

RSSHub is the obvious comparison, and the difference is architectural. RSSHub is a route-based generator: you request a URL, it fetches and transforms on demand, and it is typically deployed as a shared instance. We-MP-RSS is the opposite shape. It keeps a database, runs scheduled jobs, stores articles, and serves feeds from that store, which is why SQLite and MySQL appear as options and why the UI has subscription management, export formats and filter rules. The practical consequence: RSSHub gives you a stateless route you can call from anywhere, while We-MP-RSS gives you a persistent archive you can export to Markdown or PDF and filter per account.

Hosted WeChat-to-RSS services occupy a third position. They remove the container and the QR scan from your plate, at the cost of trusting someone else with the session and accepting whatever retention policy they set. We-MP-RSS is for people who specifically do not want that. The trade is that you own the failure modes: expired authorization, a browser dependency inside the image, and a database file you must back up.

Licence, maintenance and the real upgrade cost

The repository's LICENSE file is present but GitHub reports the licence as NOASSERTION, while the README badge says MIT. Those two signals disagree, so read the LICENSE file itself before you build anything commercial on top of it. If it is MIT, the usual obligations apply: keep the copyright notice and the licence text with redistributed copies. That is a statement about the file, not legal advice.

On maintenance, the last push was on 2026-09-10 and the most recent release is v1.5.3 from 2026-08-13, so the project is being worked on. Upgrade cost is low by design: the README's upgrade sequence is stop, remove, pull, run, and the only state that survives is the data volume. The hidden cost is that the image is large, since it bundles a Python environment plus WebKit and Chromium, and the Dockerfile's comment about not adding frontend compilation to the workflow suggests build times were already a concern. If you pin a tag instead of latest, you control when that pull happens; the README only shows latest.

Editorial conclusion

Adopt We-MP-RSS if you already read WeChat Official Accounts and want them in a normal feed reader, and you are willing to run a container with a persistent data volume and re-scan a QR code when the session expires. Do not adopt it if you need a hosted service, an SLA, or a tool that works without a logged-in WeChat account, because the collection path depends on that session. Before committing, verify three things on your own deployment: that the QR authorization completes against your account, that the scheduled job actually writes new rows after the first run, and that the export format you need (md, docx, pdf or json) renders your target account's article layout correctly.

Frequently asked questions

Official sources

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