# Feiyang Digital bot: AI assisted Telegram group moderation

> Feiyang Digital is a Telegram group management bot built on Spring Boot and the Telegram bot API, which removes violating videos, stickers and images, recognises gambling and other rule breaking content with DeepSeek and Google Cloud Vision, and applies regex keyword rules. It ships as a Docker Compose stack with MySQL and Redis.

**youshandefeiyang/feiyangdigital-bot** — 这是一个基于SpringBoot和Telegrambot-Api的多功能Telegram群管机器人，Powered By DeepSeek And Google Cloud Vision。

- Repository: https://github.com/youshandefeiyang/feiyangdigital-bot
- Website: https://t.me/feiyangdigital
- Stars: 867 · Forks: 117
- Language: Java
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/youshandefeiyang-feiyangdigital-bot

## What the bot does for a group administrator

The repository is a Telegram group management bot, and the feature list in the README is the whole pitch. It claims effective detection and removal of 18 or more categories of violating video, sticker and image. It recognises gambling and other violating images and text using DeepSeek and Google Cloud Vision.

On top of detection it adds the everyday utilities a group needs: regex based custom keyword replies, deletion of violating words, daily word cloud statistics, and a welcome message for new members.

The implementation choices follow from that feature set. The bot is written in Spring Boot with the Telegram bot API, so the Java side handles the long polling or webhook conversation with Telegram, the scheduled jobs behind the daily statistics, and the persistence of group configuration. The moderation logic itself is mostly a question of which model you ask.

That matters for how you should judge the project. The interesting engineering is not in the Java, it is in the loop of take a message, decide whether it violates a rule, and act on it. The bot does that for text through a language model and for images through a vision model, which means content moderation quality depends on the models it calls and on the thresholds you set, not on tuning inside the bot.

The public bot itself runs at the t.me/feiyangdigital address, which the repository lists as its homepage.

## The Compose stack: bot, MySQL and Redis

The deployment is a Docker Compose file with three services, and reading it tells you the architecture.

The bot service runs the image from Docker Hub and maps host port 38455 to container port 8080, which is the Spring Boot server inside. It mounts a configuration file from the host into the container and declares a restart policy of unless-stopped. It also declares a dependency on both MySQL and Redis, so Compose starts those first.

The database service runs MySQL 8.0 with caching_sha2_password as the default authentication plugin and with the bind address skipped so that other containers can reach it. It creates a bot database, sets the root password, and mounts a SQL file from the host into the container's entrypoint directory so that the schema is created on first start. A named volume holds the database files.

The cache service runs Redis with three save points configured, and with compression and checksum options on for the RDB file. It also uses a named volume.

Two named volumes are declared at the bottom, one for MySQL and one for Redis. Those are the pieces you must not delete blindly, as the update instructions in the README show.

The configuration reaches the bot through environment variables rather than through the mounted file alone. The datasource URL, the user name, the password and the driver class are all passed as SPRING_DATASOURCE_ variables, which is the standard Spring Boot way of configuring a datasource.

## First run: create the bot, edit the config, start the stack

The README starts with the account setup you would expect. You create a bot through @BotFather, record its token and user name, and the README links a step by step article if you are unfamiliar. You also need Docker and Docker Compose installed.

Then it gives a single command to fetch and run the setup script.

```bash
curl -o start.sh https://ghproxy.com/https://raw.githubusercontent.com/youshandefeiyang/feiyangdigital-bot/main/start.sh && chmod +x start.sh && ./start.sh
```

Note what that does. It downloads a shell script through a third party proxy and runs it directly, so the script is what creates the configuration directory and the compose file on your host. It is convenient and it is also the part to read before running, because it is remote code fetched over a proxy URL.

After that, the configuration lives in a directory named for the bot, and you edit the conf.json file there, filling in the user name and token into the botConfig name and token fields.

Then the container is started from the same directory:

```bash
docker-compose up -d
```

The README also warns that your network must be able to reach the Telegram servers, and that if you are behind a soft router you should use an enhanced proxy. That is the usual failure mode for a bot that appears to start and then never receives an update.

## Day to day operations and the update procedure

The README documents the container commands you would use day to day, all of them run from the configuration directory.

Pausing and restarting are one liner Gradle free Docker commands:

```bash
docker-compose stop
```

```bash
docker-compose restart
```

Following the logs is the one you will use most when a rule is not firing:

```bash
docker-compose logs -f 
```

The update procedure is longer and more dangerous, and the README is careful to warn about it. First the stack is taken down with docker-compose down. Then, and this is the step the README marks with a warning, the database persistent volume is deleted, after backing up the database to a file in the home directory:

```bash
docker exec -it feiyangdigitalbotconf-mysql-1 mysqldump -uroot -ppassword bot  > /home/bot.sql
```

```bash
docker volume rm feiyangdigitalbotconf_mysql-data
```

The warning says to compare the database file in the repository with the one you have, and not to run the deletion otherwise, and to back up the keyword documents before deleting. That caution is well placed: deleting the volume discards the group configuration, the keyword lists and the statistics, and the README explicitly warns that the operation is dangerous.

After that, the new image is pulled and the stack started again, and one host level change is required, an entry in /etc/sysctl.conf followed by a reboot:

```bash
vm.overcommit_memory = 1
```

The value is the setting Redis asks for on Linux when it wants to fork without risking a failed allocation, which is why it is tied to the database update steps.

## What the AI layers mean for privacy and cost

Two external services do the detection work, and the README names both: DeepSeek and Google Cloud Vision. The language model handles the text, and the vision service handles the images and stickers.

The first consequence is that group content leaves your server. Every message and every image that the bot evaluates is sent to a third party API. For a group where members discuss anything sensitive, that is a real consideration, and the README does not offer an on premises mode.

The second consequence is that moderation quality is set by someone else's model. When the model changes, the behaviour of your group rules changes with it, and the README does not document a way to pin or to tune that beyond the configuration file.

The third is cost and rate limits. A busy group means a continuous stream of API calls, one per candidate message or image, billed per call. The README does not give any pricing or rate information, so you have to work that out from the providers themselves.

Against that, the regex keyword rules and the word cloud statistics are local and free, and they cover the predictable part of moderation. A sensible deployment is to let the keyword rules handle the obvious cases and reserve the model calls for what they cannot decide, but that split is your configuration decision rather than a documented setting.

## Defaults you should change before going live

The Compose file is written for a quick local trial, and a few of its defaults should not survive contact with a public server.

The database password is the obvious one. The MySQL service sets the root password to the literal value password, and the bot service passes the same value through the SPRING_DATASOURCE_PASSWORD variable. Anyone who has seen this repository knows that credential, and the root host is set to accept connections from any host, with the bind address skipped. Anyone who can reach the MySQL port can attempt to log in with a known user name and a known password.

The published port is the second one. The bot service maps 38455 on the host to 8080 in the container, and the Spring Boot application is a web application, so whatever the application exposes on 8080 is reachable from the network unless a firewall says otherwise.

The third is the configuration file. The README asks you to edit conf.json on the host and that file holds the bot token, which is a credential for the bot itself. It is mounted into the container as a file, and it lives in a directory under /home on the host, so the permissions on that directory are what protects the token.

The fourth is the update procedure, which deletes a volume that holds the group configuration and the keyword lists. The README warns about it and tells you to back up first, and that warning deserves to be read as a step rather than skimmed.

None of this is unusual for a self hosted project of this kind, and the authors are candid in the README about the dangerous steps. It does mean the configuration work is part of installing it.

## Building the bot image from source

The repository contains a Dockerfile, a pom.xml file and a src directory, so the image can be built rather than pulled.

The build stage uses a Maven image with Eclipse Temurin 17 and runs a Maven package command, copying the pom file first and the source afterwards so that dependency resolution is cached between builds. The runtime stage switches to a Temurin 17 JRE on Ubuntu Jammy and copies the built jar out of the build stage. It installs a Chinese font package along the way, which is what lets the application render Chinese text in any image or chart it produces, and it sets the JVM into headless mode because a server container has no display. The entry point is a plain java jar launch.

```dockerfile
FROM eclipse-temurin:17-jre-jammy

WORKDIR /app

COPY --from=build /app/target/*.jar app.jar
COPY --from=build /app/src/ /app/src/

ENV JAVA_TOOL_OPTIONS="-Djava.awt.headless=true"

ENTRYPOINT ["java", "-jar", "app.jar"]
```

So the runtime baseline is Java 17, and building from source needs a JDK that matches, or the container build does the work for you.

On maintenance, the facts are modest. The last push was on 2026-07-03 and the repository has no GitHub releases at all, so there is no tag to pin and no release note to read; the Docker Hub image is tagged latest, which means the image you pull can change under you without any version marker. The licence is Apache 2.0, which permits commercial and internal use with attribution, and whether that fits your organisation is a question for your own legal review.

## Conclusion

Feiyang Digital is worth a trial for an admin of an active Telegram group who spends real time deleting gambling and promotional posts, because the combination of keyword rules, media scanning and per group statistics removes a repetitive chore. It is the wrong choice for a group that needs moderation decisions a human should make, for a deployment where images and message text cannot leave your infrastructure, and for anyone uncomfortable with the default credentials in the compose file. Verify first that the detection thresholds in conf.json suit your group, that your network reaches the Telegram servers and the two AI providers, and that you have replaced the example database password and closed the published port before you run it anywhere public.

## FAQ

### What is the Feiyang Digital bot?

It is a Telegram group management bot built with Spring Boot and the Telegram bot API that removes violating videos, stickers and images, detects gambling and other rule breaking content with DeepSeek and Google Cloud Vision, and adds keyword replies, daily word cloud statistics and a welcome message.

### How do I start the Feiyang Digital bot?

Create a bot with @BotFather to get a token, run the setup script the README provides, put the user name and token into the botConfig fields of conf.json in the configuration directory, and then run docker-compose up -d from that directory.

### What databases does the bot need?

The Compose file runs MySQL 8.0 for storage and Redis for caching, and the bot service declares a dependency on both. The MySQL data lives in a named volume called feiyangdigitalbotconf_mysql-data.

### Does group content leave the server?

The README states that the bot is powered by DeepSeek and Google Cloud Vision for recognising violating text and images, so the content being checked is sent to those external services for evaluation.

## Sources

- [Issues](https://github.com/youshandefeiyang/feiyangdigital-bot/issues)
- [License: Apache-2.0](https://github.com/youshandefeiyang/feiyangdigital-bot/blob/main/LICENSE)
- [Project website](https://t.me/feiyangdigital)
- [README](https://github.com/youshandefeiyang/feiyangdigital-bot/blob/main/README.md)
- [youshandefeiyang/feiyangdigital-bot on GitHub](https://github.com/youshandefeiyang/feiyangdigital-bot)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/youshandefeiyang-feiyangdigital-bot