I’ve used the SaaS multi-posters (the Xiaodouyai type) — one click syncs a post to a dozen platforms. Convenient, but your account cookies live in their cloud, rate limits are billed monthly, and when a platform changes its UI you wait for them to patch it. This year I want to move to open-source self-hosting — keep my accounts in my own hands, be able to edit the code, stop paying subscriptions. Possibly even fork one into my own distribution base.

GitHub has no shortage of these projects, stars ranging from 14k down to 200. But high stars don’t mean usable, and a pretty README doesn’t mean the code is there. So I cloned all 7 candidates into /tmp/survey/ and read each one’s code — not the README’s promises, but the actual find/ls/grep of real implementations. This post is what I found after the audit.

The 7 candidates, at a glance

Sorted by stars:

First impression after reading the code: stars have almost no correlation with usability, and README-vs-code mismatches are more common than you’d think.

Comparison matrix (post-audit reality)

My profile: technical full-stack, WSL with no desktop, long-term self-hosting, CN platforms first, need both image+video, have AI infra (local Go multi-provider proxy + Anthropic-compatible middleware). Fit is scored against that.

Where README and code disagree (the high-value part)

This is the part I found most worth doing — anyone can read READMEs, few clone and verify file by file. Four projects had concrete “say one thing, do another.”

Wechatsync: claims 29+ platforms, code has 20

README says in big text “sync to 29+ platforms.” I ran ls packages/core/src/adapters/platforms/ and counted: 20 adapter files. Xiaohongshu, Douyin, NetEase, Smzdm, Dayu, Yidian, X (Twitter) are all listed in the README’s platform table — none exist in code. What actually works is article sites like Zhihu/Juejin/Toutiao/CSDN/cnblogs. Also, docs claim WordPress/Typecho support, but it actually uses the MetaWeblog API protocol (Typecho-compatible), not direct integration.

turbopush-website: not a product at all, it’s the marketing site

218 stars, README says publish+schedule+analytics. I clone it — Next.js 15 static site, src/app/page.tsx is a landing page, src/components/sections/download-section.tsx is a download button. The entire repo contains zero publish logic; grep for Playwright/Selenium/puppeteer returns nothing. README line 1 finally admits it: the real publish logic lives in a separate repo, turbopush-mcp (a Tauri desktop app). This turbopush-website is literally the product’s official website. Wrong target.

social-auto-upload: README says MIT, LICENSE file absent

This is the 14.2k-star frontrunner; README line 314 says “this project temporarily adopts MIT License.” But ls LICENSE* — the file doesn’t exist, and GitHub API returns license=null. Legally, no LICENSE file = “all rights reserved” by default, which is a real risk for commercial use. You’d need to add an MIT LICENSE file first. Also, the TikTok uploader has two conflicting versions: main.py (old Firefox impl) and main_chrome.py (new Chrome impl), with the Chrome one being current; YouTube/TikTok are less complete than Douyin/XHS.

creatorhub: no LICENSE file at all

1k stars, features look the most complete (login/monitor/download/publish/comment/DM/danmaku), but the repo has no LICENSE file, and README only says at line 298 “for technical learning and personal content management.” 61 commits in 30 days, single developer, low bus factor. Powerful, sure, but you must contact the author for licensing before any commercial fork.

postbot: Apache-2.0 with two extra restrictions

postbot’s LICENSE isn’t plain Apache-2.0 — it’s the author’s own “GitCoffee Open Source License,” adding two clauses on top of Apache: (1) no multi-tenant SaaS without written authorization; (2) frontend LOGO/watermark/author/copyright info cannot be removed or modified. Lines 203-219, in black and white. So it’s not the “modify freely” Apache you might assume — weigh that for commercial use. Also README says “12+ CN platforms,” code actually has 20+.

brightbean-studio: 0 CN platforms, and the architecture can’t easily add them

This one’s architecture is the cleanest — Django 5.x + provider abstraction + OAuth + AES-256-GCM encryption + MCP server + official-API direct connection. But ls providers/ shows 13 providers, all international (Facebook/Instagram/LinkedIn/TikTok/YouTube/Pinterest/Threads/Bluesky/Google Business/Mastodon/DEV.to). Zero CN platforms. And because it’s built on official APIs — Douyin, Xiaohongshu, WeChat Channels have no public publish API — this architecture is structurally unfit for CN video platforms. Adding CN platforms means writing an entire browser-automation provider layer, against its design intent. Also AGPL-3.0 is infectious (network use triggers open-source obligation), so closed-source commercial SaaS is out.

Selection by scenario

The table alone isn’t enough — split by use case.

Just want to ship video out of the box → social-auto-upload. Docker one-shot, sau CLI stably runs 6 CN video platforms (Douyin/XHS/Bilibili/Kuaishou/Channels/Baijiahao), patchright headless-shell runs on WSL. 14.2k stars aren’t for nothing; scheduled publishing is its core scenario (the author built it to queue next-day scheduled posts).

Want a web panel to manage image+video together → creatorhub. FastAPI panel, login/monitor/download/publish/comment/DM/danmaku all covered, best risk control among the 4 CN-platform options. But you must first solve three problems: no LICENSE, no Docker, first-login QR scan needs GUI.

Want to fork one into your own distribution platform → depends on priority. For pure CN video distribution, social-auto-upload is the most permissive (MIT after you add the file, commercial-OK). For a full multi-workspace SaaS panel (including international platforms), brightbean-studio’s provider abstraction is cleanest — but accept AGPL and write your own CN browser providers.

Top-3 (for my situation)

🥇 social-auto-upload — primary

The only project that simultaneously satisfies “CN video platforms + permissive license + Docker + WSL headless.” 6 CN video platforms with real implementations, sau CLI + Flask web panel (:5409) + Vue3 frontend, patchright headless works, 14.2k-star community is the most mature.

Risks: LICENSE file missing (fix first), no AI hooks, no account isolation, plaintext cookies, stealth.min.js is a 2023 build, weak on image-text (video-first).

🥈 creatorhub — backup / risk-control + AI transplant source

The most feature-complete CN video panel, enterprise-grade risk control (unified gate + sticky proxy + fingerprint isolation + random jitter), native AI copywriting (ai_base_url can point straight at a local proxy port). But no LICENSE, single dev, no Docker, only 4 platforms. My plan: don’t fork it as primary — transplant its app/risk.py risk gate and app/engine/compose.py AI module into social-auto-upload to fill the latter’s risk-control and AI gaps.

🥉 brightbean-studio — fork-base reference

Cleanest architecture, suited for forking into a full SaaS panel. Official API = lowest ban risk, full Docker + Caddy auto-HTTPS, native MCP connects directly to Claude Code/Codex. But AGPL infectious, 0 CN platforms, and “CN video has no official API” means it can only be the base for an international-platform panel — misaligned with “CN first.”

Four killed

• MultiPost-Extension: Chrome MV3 extension, can’t run headless on WSL; zero anti-detection = high ban risk. Widest platform coverage (100+ handlers), wrong model.
• postbot: same extension-GUI dependency; restricted license; single dev.
• Wechatsync: GPL infectious + article-only (no video) + needs a browser; 0 commits in 30 days, stale.
• turbopush-website: marketing site, not a product; publish logic is in a separate repo.

WSL no-desktop deployment reality

This is the most practical part — my env is WSL2 with no desktop, so the three browser-extension projects are out immediately (MultiPost/postbot/Wechatsync’s extension form requires a running Chrome/Edge GUI). The survivors that can go headless each have their own traps.

social-auto-upload is easiest via Docker:

1
2
3
4
5
6

git clone https://github.com/dreammis/social-auto-upload.git
cd social-auto-upload
docker build -t sau .
docker run -d --name sau -p 5409:5409 -p 5173:5173 \
  -v $(pwd)/db:/app/db -v $(pwd)/videos:/app/videos sau
# visit http://localhost:5173

The biggest trap is first-time QR-code login needs a GUI. Two workarounds for no-desktop WSL: (1) log in via a Windows browser and export cookies — the project ships export_douyin_cookie.sh; (2) run headed patchright in WSL pointed at the Windows X server (export DISPLAY=:0), scan once, cookies persist to local JSON, then everything goes headless. Xiaohongshu also needs an external signing service (XHS_SERVER=127.0.0.1:11901).

brightbean-studio is ironically the easiest — pure official API, no browser, Docker Compose up, perfect headless. But as noted, zero CN platforms.

creatorhub sits between: QR first-login needs GUI, after that headless monitoring works; but no Docker means manual venv, and LICENSE must be resolved first.

AI infra wiring

I have a local Go multi-provider proxy (OpenAI-compatible, multi-model rotation) and an Anthropic-compatible middleware, both want to plug in for content generation.

• creatorhub supports it natively: set ai_base_url to the local proxy port, fill ai_api_key and ai_model, done — app/engine/compose.py already calls an OpenAI-compatible chat/completions. It’s the only one of the 7 that’s plug-and-play for AI (brightbean’s MCP counts too, but that’s an agent protocol, not content generation).
• social-auto-upload has no reserved hooks: to connect it you have to add a generation endpoint to sau_backend.py yourself, or port creatorhub’s compose.py over. This is exactly why I’m treating creatorhub as a “transplant source.”

Conclusion

If I had to pick one: social-auto-upload as primary (add LICENSE + transplant creatorhub’s risk-control and AI modules), creatorhub as the risk-control/AI transplant source, brightbean-studio as the fork-base reference for international-platform panels.

One sentence: this space has no silver bullet — no single project nails “CN image+video + self-hosting + low ban risk” at once. social-auto-upload is the most pragmatic starting point for CN video, creatorhub is the sample most worth borrowing for risk-control design, brightbean is the base most worth studying for architecture. Stitching the three together is what gets me close to what I want. The three browser extensions cover the most platforms, but on a no-desktop WSL they’re a dead end — and without anti-detection, they’re effectively walking your accounts to the ban hammer.

I kept the full six-dimension evaluation cards and deployment roadmap locally; this post is the condensed version.