How to use xianyu-auto-reply? Xianyu automatic reply system functions and deployment notes

Sat, 06 Jun 2026 19:16:35 +0800

zhinianboke/xianyu-auto-reply is an automated management system for Xianyu scenarios. It is not an automatic reply script with only a few lines of rules, but a complete web system that puts account management, message sending and receiving, automatic replies, AI replies, automatic shipping, product release, order processing and backend management together.

If you just want to add a few keyword replies to Xianyu messages, it may be a bit heavy; if you are also doing virtual goods, coupon shipping, multi-account management, automatic evaluation and product release, its functional coverage is relatively complete.

What can this project do?

Judging from the project README, the main system mainly covers these modules:

Multiple account management: supports multiple Xianyu account logins, status switching, cookie maintenance and login renewal;
Automatic reply: supports text keywords, image keywords, default replies and product-specific replies;
AI reply: supports access to large models for contextual dialogue and intelligent replies;
Automatic delivery: supports coupons, virtual goods, automatic reissue and delivery records;
Online chat: Provides conversation list, messaging and chat linkage;
Product release: supports material library, address library, single product release, batch release and release log;
Orders and evaluation: Supports order pulling, automatic evaluation, request for red flowers and status tracking;
Commodity collection and distribution: including Goofish collection, supply management and settlement links;
Notification and risk control: including message notification, risk control log, system feedback and announcement management.

There is also a promotion rebate subsystem in the project, which is used to manage rebate accounts, product selection rules, material libraries, publishing rules, deletion rules and compensation tasks. However, the README also states that Docker Compose in the root directory only covers the main system by default, and the rebate subsystem needs to be started separately.

Technology stack and system structure

The technology stack of this project is relatively typical:

Backend: FastAPI, SQLAlchemy 2.0, Loguru;
Database: MySQL 8.0;
Cache and task assistance: Redis 7;
Browser automation: Playwright, Chromium / Chrome;
Scheduled tasks: APScheduler;
Front-end: React 18, TypeScript, Vite, TailwindCSS, Zustand, Lucide React;
Deployment: Docker, Docker Compose, Nginx.

The service split is also relatively clear:

Service	Default Port	Function
`frontend`	`9000`	Main system front end
`backend-web`	`8089`	Main system API gateway and business interface
`websocket`	`8090`	Xianyu WebSocket, messaging, login and order linkage
`scheduler`	`8091`	Automatic shipping, evaluation, order pulling, cookie refresh and other scheduled tasks
`promotion/backend`	`8092`	Rebate backend API
`promotion/frontend`	`9001`	Rebate front end

The dependencies of the main system are roughly:

1
2

mysql / redis -> backend-web -> websocket -> scheduler
frontend -> backend-web

That is, it is not a single-container application. Before deployment, it is best to confirm that the server port, memory, database persistence and reverse proxy are all arranged.

Server deployment method

It is recommended to use Docker and Docker Compose for project deployment. The server needs to be installed first:

Docker 20.10+
Docker Compose 2.0+
Minimum 2-core CPU / 4GB RAM
Recommended 4-core CPU / 8GB RAM

The one-click deployment command given by README is:

`1`	`curl -fsSL https://xy-update.zhinianboke.com/deploy.sh \| sed 's/\r$//' \| bash`

The update command is:

`1`	`curl -fsSL https://xy-update.zhinianboke.com/update.sh \| sed 's/\r$//' \| bash`

If you want to see the script content clearly yourself, you can clone the repository first and then deploy:

1
2
3

git clone https://github.com/zhinianboke/xianyu-auto-reply.git
cd xianyu-auto-reply
bash deploy.sh

The first run will automatically generate the .env configuration file and docker-compose.deploy.yml, and pull the pre-built image to start the service. After deployment is complete, the default access address is usually:

Frontend: http://服务器IP:9000
API documentation: http://服务器IP:8089/docs -Default account: admin / admin123

Here’s a very practical suggestion: don’t blindly run remote scripts directly on the production server. At least run it on a test machine first, or download the script and check it clearly. It will create configurations, pull images, clean up old containers and start services, and the scope of permissions is not small.

Local source code build

If you want to build from source, you can execute in the root directory of the repository:

`1`	`bash build.sh rebuild`

Commonly used commands include:

Command	Description
`bash build.sh rebuild`	Delete old containers and images, rebuild and start
`bash build.sh start`	Start service
`bash build.sh stop`	Stop service
`bash build.sh restart`	Restart service
`bash build.sh logs`	View real-time logs
`bash build.sh status`	Check service status

You can also rebuild a service individually:

bash build_frontend.sh
bash build_backend_web.sh
bash build_websocket.sh
bash build_scheduler.sh

Python 3.11+, Node.js 18+, MySQL, Redis and Chromium/Chrome are also required for source code development. Playwright is used in the backend service. If the browser is missing when logging in or publishing, you need to execute:

`1`	`python -m playwright install chromium`

Things that must be changed after deployment

The default administrator account for this project is:

`1`	`admin / admin123`

The first thing to do after the deployment is completed is to change the password. As long as the front-end port is exposed to the public network, the default password is equivalent to handing over the backend.

Also check these configurations:

CORS_ORIGINS: Do not use * directly in the production environment;
BACKEND_WEB_PUBLIC_URL: used to generate external file URL, which must be filled in correctly after reverse proxy;
HTTPS: It is best to use HTTPS for external network access;
MySQL data volume: automatic shipping, products, orders, and account status are all in it and must be backed up;
Static resource directory: involving pictures, materials, and file URLs, which must also be included in the backup;
Playwright browser environment: automatic login, cookie refresh, and publishing functions all rely on it.

If you are only testing on your own internal network, you can first use the LAN IP to access it; if you want to use it on the public network, it is recommended to put it behind a reverse proxy and limit the access scope of the management background.

Who is it suitable for?

This program is more suitable for these people:

If you have multiple Xianyu accounts, you need to check the messages and status in a unified manner;
To make virtual goods or coupons, automatic delivery and reissue records are required;
Frequently answer similar questions repeatedly, hoping to use keywords or AI replies to reduce the workload;
Have some experience in using servers and Docker;
Able to maintain MySQL, Redis, container logs and backups by yourself;
Understand the risks of platform rules and do not intend to use them to violate regulations or harass you.

It is not suitable for completely zero-based users. The system has many functions, which also means that deployment, configuration, troubleshooting and risk control are all your own responsibility.

Risks and Boundaries

For tools like Xianyu Automation, what you really need to pay attention to is not “whether it can run”, but “whether something will happen after running”.

There are at least a few risks that you need to think about in advance:

Platform rules risks: automatic replies, automatic publishing, and automatic shipping may touch platform risk control;
Account risk: Cookie maintenance, WebSocket connection and browser automation may cause account abnormalities;
Data risk: account information, orders, chat records, and shipping materials must be protected;
Security risks: Do not expose the backend, API documents, and database ports to the public network casually;
Compliance risk: The README clearly states that the project is only for learning and research, and reminds not to use it for behavior that violates platform rules.

In addition, this project adopts the AGPL-3.0 license, and the README specifically states “No commercial use”. If you want to re-develop and deploy it to others, or put it into business processes, it is best to carefully read the restrictions of LICENSE and README first, and don’t just look at the function list.

Summary

zhinianboke/xianyu-auto-reply is positioned more like an automated backend for Xianyu, rather than a simple automatic reply script. Its advantage is that it has a wide range of functions. The main system includes accounts, chats, replies, shipments, releases, orders and risk control logs. The technology stack is also relatively modern, and the Docker deployment path is relatively clear.

But its threshold is not low either. You need to be able to deploy services, manage databases, handle the Playwright environment, modify default accounts, configure reverse proxy and backup data. More importantly, Xianyu Automation itself has platform rules and account risk control risks.

My suggestion is: first run through the main system in the test environment, connect only one low-risk account, and then consider whether to expand the scope of use after confirming that the reply, delivery and order processes are stable. Don’t connect multiple important accounts and real transactions right away.

Reference sources

zhinianboke/xianyu-auto-reply - GitHub

FastAPI on KnightLi Blog