WeChatPadPro: a WeChat Pad protocol management server you deploy yourself

What WeChatPadPro is, and the problem it targets

The repository describes WeChatPadPro as an advanced management tool built on the WeChat Pad protocol. In plain terms it is a server: you run it, it holds one or more WeChat sessions obtained through the Pad protocol, and it exposes those sessions to your own code over HTTP. The README's own framing is a management tool rather than a client library, and the repository layout supports that reading. There is a deploy directory, a redis directory, a webhook_config.json, and a .env.example that configures ports, database connections and a worker pool. This is infrastructure, not a script.

The audience is narrow and specific. You need this when you want programmatic access to WeChat conversations, contacts or message flow from a service you control, and you are willing to run the supporting stack yourself. The .env.example assumes Redis and MySQL are already available, so the project is aimed at people who operate servers. The README also links an online demo system with a default admin key, which tells you the intended shape of the product: a web-accessible control surface over an API.

What it is not is a hosted service. There is no managed offering in the repository. You supply the machine, the databases and the network exposure. That single fact decides most adoption questions before any technical detail matters.

The mechanism: HTTP API, Redis state, MySQL persistence

The configuration file is the clearest map of the architecture. The service listens on HOST and PORT, with PORT defaulting to 1238, and API_VERSION lets you prefix routes with something like /v1 or /v2. There is a separate MCP_PORT described as being for AI large model integration services, defaulting to 0, which in most Go services means the listener is disabled until you set it. That is an inference from the default, not a documented behaviour, and the README does not explain the MCP endpoint further.

State lives in Redis. The .env.example exposes REDIS_HOST, REDIS_PORT, REDIS_DB, REDIS_PASS and a set of pool and timeout knobs: REDIS_MAX_IDLE, REDIS_MAX_ACTIVE, REDIS_IDLE_TIMEOUT, REDIS_MAX_CONN_LIFETIME, REDIS_CONNECT_TIMEOUT, REDIS_READ_TIMEOUT and REDIS_WRITE_TIMEOUT. The presence of both idle and lifetime limits suggests sessions are long-lived and the pool is sized for sustained load rather than bursts. Persistence goes to MySQL through a single MYSQL_CONNECT_STR in DSN form.

Work is dispatched through a pool. WORKER_POOL_SIZE defaults to 500 and MAX_WORKER_TASK_LEN to 1000, so the service will queue up to a thousand tasks before applying backpressure. Message distribution can run through RocketMQ: ROCKET_MQ_ENABLED defaults to false, with ROCKET_MQ_HOST, ROCKET_ACCESS_KEY, ROCKET_SECRET_KEY and a TOPIC named wx_sync_msg_topic. NEWS_SYN_WXID controls whether messages are synced per WeChat ID. The webhook_config.json at the repository root is where outbound notifications are configured, though the README does not document its schema. The whole flow is: a session is established through the Pad protocol, inbound events are normalized and pushed onto the worker pool or the message queue, and your code reads them through the HTTP API or receives them through webhooks.

Deploying it with Docker and getting the first request through

The README has a dedicated Docker deployment section, and the repository carries a deploy directory. The repository does not reproduce the compose file, so start from the environment template, which is the part that is actually shown. Copy .env.example to .env and edit it. The two values you must change before anything else are ADMIN_KEY, which ships as 12345, and MYSQL_CONNECT_STR, which ships with working-looking sample credentials.

cp .env.example .env
# edit ADMIN_KEY and MYSQL_CONNECT_STR before starting

The defaults that matter for a first run are the listener and the two dependencies. PORT is 1238 and HOST is 0.0.0.0, so the service binds every interface. REDIS_HOST points at 127.0.0.1 on 6379 with REDIS_DB set to 1, and MYSQL_CONNECT_STR points at 127.0.0.1:3306 with the database name weixin. If your Redis or MySQL runs elsewhere, change those keys rather than editing code.

DEBUG=true
HOST=0.0.0.0
PORT=1238
ADMIN_KEY=<replace-with-a-random-string>
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_DB=1
MYSQL_CONNECT_STR=<user>:<password>@tcp(127.0.0.1:3306)/weixin?charset=utf8mb4&parseTime=true&loc=Local
TZ=Asia/Shanghai

Once the service is up, the README's demo link uses an adminkey parameter, which indicates the admin key travels as a request parameter rather than a header. The README does not spell out the API surface, so treat the demo system as the reference for route names. The repository also ships Chinese-language guides for the login flow, including files covering login security verification codes and a verification code API, which is where you should look when a session will not establish. For older installations there is usage_guide_for_old_users.md, which implies configuration or API changes across versions that the changelog does not fully enumerate.

Where the public repository and the advertised version diverge

The README's first line announces that v875 is available in the sponsorship group. The version badge in the same file reads 868, and the newest tagged release is v2.01, labelled WeChatPadPro861-18.61v0.2.1. So three version identifiers appear in one document, and the newest one is not in the public release list. The README also advertises a paid WeChat group that offers early access to 868, and a Telegram group described as having over 1400 members.

This is the central practical fact about the project. The public repository is a distribution channel for a subset of the product, and the README says so plainly. If you depend on a specific protocol version or a specific feature, you cannot assume the public tags contain it. You also cannot assume a public tag will keep receiving fixes. The last push to the repository was on 2026-08-20, so the code is recent, but recency of the repository says nothing about which build the README is promoting.

For an evaluation this changes the questions you ask. Instead of asking whether the project is maintained, ask which artefacts are public, which require group access, and whether the feature you need is in the public set. The README does not answer those questions, and the changelog section referenced in the README's table of contents is not included in the repository listing.

Limits, risks and cases where it is the wrong tool

The most concrete limitation is that the .env.example contains a MYSQL_CONNECT_STR with what appear to be real credentials, including a password, and an ADMIN_KEY of 12345. Defaults like these get copied. A deployment that keeps either value is exposed to anyone who can reach port 1238, and the README does not include a hardening checklist. Change them before the first start, not after.

Second, the project carries no licence identifier in the repository. The top-level listing has no LICENSE entry. For a service that handles message data, an unclear licence is a genuine adoption blocker in a commercial setting, and no amount of documentation elsewhere resolves it. Treat that as an open question to raise with the maintainers rather than something to interpret.

Third, the README does not document rollback, backup, or migration between protocol versions. The presence of usage_guide_for_old_users.md suggests upgrades have broken things for existing users before, but the guide's contents are not shown. If you need a supported upgrade path with a stated compatibility window, this is the wrong tool.

Fourth, the risk-control section referenced in the README's table of contents is not included in the repository listing, so the account-safety guidance the project offers cannot be evaluated. Any deployment that automates WeChat activity carries account risk, and the project's own documentation treats that as a topic worth a dedicated section. Do not adopt this if you cannot tolerate losing the accounts it operates.

Finally, the worker pool defaults of 500 goroutines and a 1000-task queue are tuned for volume. A single-account, low-traffic use case inherits that footprint for nothing, along with Redis and MySQL.

How it differs from WeChatFerry, Gewechat and itchat-style libraries

The alternatives people search for alongside this project split into two groups. WeChatFerry and itchat are libraries you embed in your own process: you write Python, import the package, and the library talks to the client on the same machine. Gewechat is closer in shape to WeChatPadPro, exposing an HTTP interface, but the architecture differs in what sits behind it. WeChatPadPro is a standalone Go service with its own Redis and MySQL dependencies, a worker pool, optional RocketMQ, and a web control surface. The library approach gives you less to operate and less to configure; it also gives you no shared session state across processes and no queue.

The meaningful difference for a team is operational. With a library, a crash takes down your application and the WeChat session with it. With WeChatPadPro, the session state lives in Redis and the service can be restarted independently, at the cost of running Redis, MySQL and the Go binary. If your integration is a single script that reads messages, a library is the smaller commitment. If you are building a service that several internal systems query, the separate process is the point.

WeChatPadPro is also explicit about the Pad protocol as its basis, which is what allows iOS version labels like 18.7 to appear in the README badges. Libraries that hook a desktop client have a different compatibility surface. The repository does not compare itself to any of these alternatives, so the choice comes down to whether you want a server or a dependency.

Maintenance, upgrades and what the licence question means in practice

The repository is not archived and the last push was on 2026-08-20, roughly five weeks before this writing. That is recent enough that the public code is being touched, though the README's own promotion of v875 in a sponsorship group means public activity is not the same as public releases. The newest public release is v2.01 from 2025-08-22, about a year before the last push. Anyone planning an upgrade cycle should plan around that gap rather than around the commit date.

Upgrade cost is hard to estimate from the repository because the changelog is not available and the README does not describe a versioning policy. The API_VERSION variable, which lets you prefix routes with /v1 or /v2, is the only hint that routes may change between versions, and it is a configuration option rather than a compatibility guarantee. The existence of usage_guide_for_old_users.md is a stronger signal: someone decided existing users needed a separate document to move forward. Read it before upgrading a running instance.

On licensing, the repository gives no identifier and the top-level listing shows no licence file. That is not a legal opinion, and it is not a statement that the project is unlicensed. It is a statement that a reader of the repository cannot determine the terms from the repository. If you intend to use this commercially, that gap is the first thing to resolve, before the technical evaluation, because it can invalidate the work regardless of how well the service performs.

Editorial conclusion

WeChatPadPro fits teams that already run Redis and MySQL, are comfortable with a Go service whose README points to a Telegram group and a paid WeChat group for the newest build, and who accept that the public repository trails the advertised v875. It does not fit anyone who needs a documented licence, a stated compliance position, or a stable API contract, because the repository carries no licence file and the README does not describe versioning policy or rollback. Before adopting it, verify three things in your own environment: that the ADMIN_KEY default 12345 has been replaced with a random string, that MYSQL_CONNECT_STR no longer contains the sample credentials committed in .env.example, and that the Redis database number you point REDIS_DB at is not shared with another application. If those three checks fail, the deployment is not ready regardless of which protocol version it reports.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. WeChatPadPro/WeChatPadPro on GitHub