YYeTsBot: a self-hostable Telegram bot and website for YYeTs resource search

What tgbot-collection/YYeTsBot indexes, and who it is for

YYeTsBot is two front ends over one index of media resources. The README lists the online entry points: a website at yyets.click and a Telegram bot at t.me/mikuri520, with a separate Telegram channel for announcements. The repository behind them holds the bot, the web server and a shared Python package, so the same data serves both surfaces.

The feature list is short and concrete: search across film and TV resources, links shared by other users, favourites that sync across devices, comments, and a marker for resources that have gone dead. The homepage carries an advertising and affiliate disclosure, which tells you the hosted instance is partly funded that way rather than by subscriptions.

This is aimed at people who want to find YYeTs-related releases and netdisk shares through a chat window instead of a browser, and at operators who want to run that search service themselves. It is not a media player, not a streaming service, and not a general-purpose torrent index. The disclaimer is explicit that the project stores, uploads and distributes no video files, and that links posted in comments come from users. If you need a catalogue that guarantees working links, this is the wrong shape of tool: the dead-link marker exists precisely because links rot.

How the bot, the website and the search index fit together

The repository layout separates concerns cleanly. yyets/ is the installable package described in setup.py as a "https://yyets.click/ wrapper" with a single required dependency, requests. yyetsbot/ holds the Telegram bot entry point, and yyetsweb/ holds the Tornado web application, started as server.py. conf/ holds configuration, and docker-compose.yml defines the services those two processes talk to.

The compose file is the clearest statement of the architecture. Redis serves as cache or queue, MongoDB stores the documents, MySQL backs the web side, and Meilisearch provides the search index. The bot container depends only on redis and mongo. The web container depends on mongo, redis and mysql, and it is the one that exposes ports, bound to 127.0.0.1:8888 and 172.17.0.1:8888 rather than to all interfaces. That binding choice is deliberate: the web app is meant to sit behind a reverse proxy, not to face the internet directly.

The Dockerfile shows a multi-stage build. A Python 3.14 slim stage installs requirements.txt, a Debian bookworm stage downloads a prebuilt frontend bundle from the separate YYeTsFE repository, and the final image copies both in, then runs playwright install --with-deps chromium. That last line matters for sizing: the finished image carries a headless Chromium, so it is much larger than the dependency list alone would suggest. The README points at YYeTsFE for the frontend, which means the HTML you see is not built from this repository at all.

Installing YYeTsBot with Docker Compose

The README states that Docker self-deployment is supported, and docker-compose.yml is the deployment definition. It references an env file at env/yyets.env for both the bot and web services, so that file has to exist before anything starts. The README does not list its keys, and the compose file does not inline them. Read conf/ in the repository to work out which values are expected; treat the names below as the shape of the file, not a published reference.

The stack starts with:

docker compose up -d

Five services come up: redis, mongo, meili, mysql and bot in the compose file, plus web, which is the service that publishes port 8888. Redis, MongoDB and MySQL are configured with logging disabled, so a failing start will not explain itself in container logs. Check container state instead.

The web process is defined with its own working directory and command:

  web:
    image: bennythink/yyetsbot
    working_dir: /YYeTsBot/yyetsweb/
    volumes:
      - ./subtitle_data:/YYeTsBot/yyetsweb/subtitle_data
    command: [ "python3","server.py","-h=0.0.0.0" ]

That volume mount is the only persistent path the web service declares, and it holds subtitle data. MongoDB gets its own bind mount at ./mongo_data/mongodb. Meilisearch uses a named volume, meilisearch_data, while MySQL declares no volume at all, which means its data lives inside the container and disappears when the container is recreated. For a service you intend to keep, that is a problem worth fixing before you load anything into it.

The compose file defines the meili service with MEILI_HTTP_PAYLOAD_SIZE_LIMIT set to 1073741824, and the bot and web services do not list meili in their depends_on. Whether the application reaches Meilisearch through configuration rather than service ordering is not documented. Verify that before assuming search will work on first boot.

For the Python package on its own, setup.py declares the distribution name yyets and requires Python 3.6 or later with requests as the only dependency, so the wrapper can be installed independently of the Docker stack.

Where YYeTsBot gets thin: configuration, upgrades and the MySQL volume

The gap between the feature list and the deployment documentation is the main cost of running this yourself. env/yyets.env is referenced twice and never described. conf/ is not explained in the README. There is no documented migration procedure, no schema versioning, and no rollback instructions for the database containers. If you are the kind of operator who needs a written upgrade path before touching production, this project does not provide one.

The MySQL container is the sharpest example. It uses the image ubuntu/mysql:8.0-22.04_beta, starts with --skip-log-bin and mysql_native_password, and mounts no volume. Recreating that container discards its contents. Because the web service depends on MySQL, anything the web side stores there is at risk on every image update. Adding a volume is a one-line change, but you have to notice it first.

The test surface is also unclear. requirements.txt includes fakeredis, which suggests some tests run without a live Redis, but the repository gives no test command and no CI description beyond the Docker image build badge. There is no statement about what happens when Meilisearch is unavailable, whether the bot degrades to database queries, or how reindexing works. Those are the questions to answer by reading yyetsweb/ before you commit to running this for other people.

One more constraint from the Dockerfile: the runtime is Python 3.14 slim and the build installs Chromium through Playwright. That is a heavy base image for a service whose visible job is search and link display. If you are deploying to a small VPS, budget for it.

What you would use instead, and how the approaches differ

The closest alternative in kind is a general-purpose media metadata service such as Jellyfin or a Sonarr-style indexer front end. The difference is the data model. Those tools organise a library you already have and fetch metadata from public databases; YYeTsBot indexes YYeTs resources and netdisk links shared by users, with comments, dead-link flags and cross-device favourites built around that shared index. If your goal is to manage files on your own disk, YYeTsBot solves a problem you do not have.

A second comparison is with the hosted yyets.click instance itself. Running the Docker stack gives you control over the index and the data, but the README's advertising disclosure applies to the hosted site, and the bot at t.me/mikuri520 is the maintainer's. Self-hosting means you inherit the operational work: five services, an undocumented env file, and no upgrade guide. Using the hosted bot means you inherit none of that, and also no control over availability or content.

Finally, the Python package named yyets is not a replacement for the stack. setup.py describes it as a wrapper around the site with requests as its only dependency, so it is a client, not an index. If you only need to query the service programmatically, that package is the smaller commitment.

Licence, maintenance and what the repository tells you about cost

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive, but it says nothing about the content the bot indexes. The README's disclaimer states the project stores, uploads and distributes no video files and that comment links come from users. If you run a public instance, the licence on the code does not settle questions about the material flowing through it. That is a question for your own counsel, not something the repository answers.

Maintenance is visible but not described. The last push to master was on 2026-07-27. The most recent release listed is yyetsbot-app-v0.1.0 from 2024-01-07, alongside a commit tagged as an offline one-click run package on the same day. The release cadence and the commit activity do not line up, so do not read the release list as a schedule.

Upgrade cost is dominated by the missing pieces rather than by dependency churn. requirements.txt pins exact versions for most packages, including requests==2.33.0, redis==7.4.0, pymongo==4.17.0, tornado==6.5.5 and meilisearch==0.33.0, so a rebuild is reproducible until you change a pin. One dependency is pulled straight from a Git URL, git+https://github.com/tgbot-collection/python-akismet, which means builds depend on that repository remaining reachable. The Dockerfile also downloads a frontend build zip from a GitHub release at a fixed URL, so image builds break if that asset is removed. Those two external fetches are the real fragility in the build, not the Python version.

Editorial conclusion

Adopt YYeTsBot if you want a Telegram front end for YYeTs resource indexing and you are comfortable assembling the missing configuration by reading conf/ and docker-compose.yml yourself. Do not adopt it if you expect a documented API, a supported upgrade path, or a stack you can run without Redis, MongoDB, MySQL and Meilisearch. Before you start, verify which environment variables env/yyets.env actually needs, whether the meili service in the compose file is wired into the running containers, and that the bot image bennythink/yyetsbot still starts under Python 3.14.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tgbot-collection/YYeTsBot on GitHub