social-auto-upload: a Python CLI for publishing video to Douyin, Bilibili, Xiaohongshu and more

What social-auto-upload actually automates

The project publishes video files and image sets to a list of platforms from one Python codebase: Douyin, Bilibili, Xiaohongshu, Kuaishou, WeChat Channels (视频号, the `tencent_uploader` module), Baijiahao, Alipay Life Account, Weibo, Hupu, TikTok and YouTube. The README presents the feature matrix as a table with columns for login, video upload, image upload, scheduled publishing, CLI and Skill, and the gaps are visible in that table rather than hidden: Bilibili and WeChat Channels have no image upload, Baijiahao, Alipay, Weibo and Hupu have no scheduled publishing, and only Douyin, Bilibili, Xiaohongshu and Kuaishou are marked as having both CLI and Skill support.

The intended user is someone operating several accounts on several platforms with the same asset, which is why the README frames the pitch against AI browser agents. Its argument is that uploads are high-frequency, repetitive work, so a fixed script that has already been validated against a platform beats an agent that re-reads the page and takes screenshots every run. That is a reasonable position, but it also defines the project's shape: it is a collection of per-platform uploader modules with hard-coded knowledge of each site's DOM and flow, not a generic publishing API.

Browser automation, patchright, and the per-platform uploader modules

There is no official publishing API behind this. The mechanism is a scripted browser session. The repository has an `uploader/` directory where each platform gets its own module, and a `utils/` directory that ships `stealth.min.js` as package data in pyproject.toml, which is the usual pattern for patching browser fingerprint signals before a page loads.

The current rewrite is moving the driver to `patchright`, pinned at `patchright==1.58.2` in pyproject.toml. Patchright is a Playwright derivative, and the README's refactor plan states the switch is for compatibility and for lowering detection risk. The same plan says the main line is moving toward headless mode, meaning the browser runs without a visible window, which suits CLI, server and agent use. The older `requirements.txt` still pins `playwright==1.52.0` and a long tail of web dependencies including Flask, SQLAlchemy and alembic; the README says that file is kept for the historical path and that ordinary users should not start there.

Login is per account. The CLI exposes a `login` subcommand for each platform and a separate `check` subcommand, which implies credentials are persisted to disk after a QR or cookie flow and then validated later. The repository also has an `examples/` directory full of `get_*_cookie.py` scripts for Alipay, Baijiahao, Bilibili, Douyin, Kuaishou, Tencent, TikTok and Xiaohongshu, plus `upload_to_*.py` scripts, so the cookie acquisition path predates the CLI and is still present.

Installing social-auto-upload and running a first Douyin upload

The README does not put install steps in the top-level file. It redirects to `docs/install.md` and `docs/update.md`, and says installation, updating and environment preparation have been consolidated there. It also says to prefer `uv`, the `sau` CLI and the `skills/` directory. The package metadata confirms the entry point: pyproject.toml declares `sau = "sau_cli:main"` under `[project.scripts]`, and requires Python `>=3.10,<3.13`.

Because the README delegates installation, the concrete commands below are the CLI invocations it does document, not an install sequence. The CLI examples in the README use an `<account_name>` placeholder, so substitute the label you want for that account.

Log in to Douyin and then verify the session before uploading anything. The README shows `login` and `check` as separate steps for every platform it covers.

sau douyin login --account <account_name>
sau douyin check --account <account_name>

Once `check` passes, the video upload takes a file path, a title and a description. The README uses `videos/demo.mp4` as the example file.

sau douyin upload-video --account <account_name> --file videos/demo.mp4 --title "示例标题" --desc "示例简介"

Douyin is also the platform with image upload in the CLI. The `upload-note` subcommand takes `--images` with one or more paths, then `--title` and `--note`.

sau douyin upload-note --account <account_name> --images videos/1.png videos/2.png --title "图文标题" --note "图文正文"

Other platforms follow the same shape with different flags. Bilibili adds `--tid 249` for the category, while Tencent and Baijiahao add `--tags tag1,tag2`. Kuaishou and Xiaohongshu mirror the Douyin commands with `login`, `check`, `upload-video` and `upload-note`. If you would rather hand the repository to an agent, the README points to `docs/agent-bootstrap.md` and says that prompt tells the agent to install the current main line, prefer `uv` and the `sau` CLI, and first verify the bilibili, douyin, kuaishou and xiaohongshu entry points.

Where the browser-automation approach breaks down

Every platform here is a moving target. The uploader reads a page that the platform controls, so a redesign of the upload form, a new anti-automation check, or a changed cookie requirement can break a platform without any change to this repository. The README's own refactor plan is an admission of this: it lists switching drivers for better stealth and moving to headless mode as open work, which means the current state is not the finished state. The README also states plainly that the Web front end is no longer the main line, is not guaranteed to run, and is not guaranteed to stay in sync with the current uploader and CLI code. If you were looking for the web UI shown in older write-ups, that is the part the project has stepped away from.

There is also a maintenance-history signal in the release list. The most recent release is tagged `baijiahao` and dated 2025-04-12, before `ks-support` in 2024-08-08 and `tk-chrome` in 2024-07-03. The README's status note, dated 2026.03.24, says the author's attention was on other work for a long stretch and that a refactor is now underway. The last push to the repository was on 2026-09-02, so work is happening, but the release tags do not reflect it and several platforms are still marked as having no Skill support at all.

Finally, this is the wrong tool if you want a supported integration contract. There is no vendor relationship with any of these platforms, no rate-limit documentation, and no stated behaviour for what happens when an upload fails midway. The README does not document rollback.

Compared with scheduling through each platform's own tools

The obvious alternative is not another open source uploader, it is the native scheduling that Douyin, Bilibili, Xiaohongshu and YouTube already provide in their creator dashboards, plus a social media management product for the accounts that lack one. The difference in approach is where the account session lives. Native scheduling keeps you inside the platform's own authenticated UI, so there is nothing to break when the page changes and nothing to re-authenticate outside the platform. social-auto-upload keeps the session on your machine as a saved login and drives the same UI programmatically.

That buys two things native tools do not give you. First, one command per platform from a script, which is what makes the same asset publishable across ten accounts without ten browser tabs. Second, an agent-facing surface: the `skills/` directory and the per-platform SKILL.md files let an OpenClaw, Codex or Claude Code session call the uploader as a tool. If your publishing is already driven by code or by an agent, the native dashboards are not addressable that way. If it is not, you are taking on browser automation and its failure modes for convenience you may not need.

The Bilibili path is a partial exception worth noting. The feature table says Bilibili prepares `biliup` at runtime, and `requirements.txt` pins `biliup==0.4.98`. So at least one platform has a dedicated uploader tool underneath rather than pure page automation.

Licence, upgrade cost and what a rebuild implies

The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; nothing in the README describes a separate commercial tier, a hosted service, or additional terms. Note that the dependencies carry their own licences, and `requirements.txt` pulls in a large set including `yt-dlp`, `streamlink`, `xhs` and `biliup`, which you would need to review independently.

The upgrade cost is dominated by the driver switch and the CLI consolidation. pyproject.toml is the current main line and pins a short dependency list: loguru, opencv-python, patchright, qrcode, requests and segno, with Flask and flask-cors behind an optional `web` extra. The `requirements.txt` file is the older, much larger set. If you installed from `requirements.txt` at some point, moving to the main line means changing both the dependency set and the way you invoke uploads, from example scripts to `sau` subcommands. The README says `requirements.txt` is for historical compatibility and that ordinary users should not prioritise it.

There is a Dockerfile in the repository, but it builds the legacy web stack: it compiles `sau_frontend` with Node 22, runs `playwright install chromium-headless-shell`, copies `conf.example.py` to `conf.py`, creates `/app/videoFile` and `/app/cookiesFile`, exposes port 5409 and starts `python sau_backend.py`. That is the web backend, not the CLI main line. Treat the Dockerfile as a path to the deprecated front end rather than as the recommended deployment.

Editorial conclusion

Adopt it if you publish the same video to several Chinese platforms on a schedule and you are willing to re-authenticate accounts when a platform changes its upload page. Do not adopt it if you need a stable public API contract, if your content is English-first and YouTube-only, or if you cannot tolerate a headless browser session per upload. Verify first that the four platforms the bootstrap prompt names, bilibili, douyin, kuaishou and xiaohongshu, log in and check successfully on your machine, and confirm that `patchright` and its Chromium build install under your Python version, which pyproject.toml pins to >=3.10,<3.13.

Frequently asked questions

Official sources

1. dreammis/social-auto-upload on GitHub
2. License: MIT
3. Project website
4. README
5. Releases