anasty17/mirror-leech-telegram-bot: a self-hosted Telegram bot for mirroring and leeching

What the bot actually moves, and for whom

The README frames the project as a Telegram bot for mirroring or leeching files from the Internet to Google Drive, Telegram, or any rclone-supported cloud. The two verbs matter. Mirroring means the file lands in a cloud destination. Leeching means it comes back through Telegram itself, with split sizes, thumbnails and filename prefixes controlled per user or per task. The source list is broader than most bots in this category: direct links handled by aria2c, torrents handled by qBittorrent or aria2c, nzb handled by Sabnzbd, Google Drive, Telegram documents and restricted messages, gallery-dl supported sites, jdownloader supported sites, and everything yt-dlp supports. If you already run qBittorrent, Sabnzbd or a JDownloader instance, the README describes external web access to those interfaces so you can remove files or edit settings outside the bot, then sync settings back into the database with a sync button in bsetting. That is the audience: someone who already has download infrastructure and wants a Telegram control surface on top of it, not someone looking for a hosted file transfer service.

Architecture: async Python, a Mongo store and external download daemons

The README states the bot is built using asynchronous programming in Python, and requirements.txt backs that up with asyncio, aiofiles, aioaria2, aioqbt, httpx and uvloop. The bot does not implement torrent or Usenet protocols itself. It drives aria2c, qBittorrent and Sabnzbd through their APIs, which is why the repository ships qBittorrent/ and sabnzbd/ directories alongside the bot/ package. yt-dlp, gallery-dl and rclone are pulled in as dependencies rather than reimplemented. MongoDB is the persistence layer, and the README lists what goes in it: bot settings, user settings including thumbnails and private files, RSS data, incomplete task messages, and JDownloader settings. One detail is worth reading twice. The README says the config.py file is stored in the database on first build, and that if it changes, the next build defines variables from config.py instead of the database. That ordering means an edit to config.py can override stored settings on the following start, which is a source of confusion when a setting appears to revert. The Dockerfile itself is short: it starts from anasty17/mltb:latest, creates a virtualenv at mltbenv, installs requirements.txt into it, copies the repository, and runs bash start.sh.

Installing it with Docker and running a first mirror

The repository provides a Dockerfile and a docker-compose.yml, so the documented path is container-based. The compose file defines a single app service that builds from the current directory, runs bash start.sh, restarts on failure, and uses network_mode host. Host networking matters because the bot talks to aria2c, qBittorrent and Sabnzbd over local ports, and because the file selector depends on a Base URL the README does not spell out in the feature list. The compose file is short enough to quote in full:

services:
  app:
    build: .
    command: bash start.sh
    restart: on-failure
    network_mode: "host"

The Dockerfile builds from the published anasty17/mltb:latest image, creates the mltbenv virtualenv, installs requirements.txt, copies the repository, and sets the container command to bash start.sh. Configuration comes from config.py, and the repository ships config_sample.py as the template to copy. The README does not document the individual keys, so read the sample file and fill in the values your chosen features need, such as Telegram credentials, database URI and any download client endpoints. After the container starts, the bot registers its command handlers with Telegram, and you drive it from a chat. A first mirror is a reply to a link: send a direct link, a magnet, or a Telegram message link and the bot creates a task. The README describes per-task options for upload destination, split size, thumbnail and whether the result is sent as media or as a document, and it describes status pages with Next and Previous buttons when more than 30 tasks are running. The Telegram channel and group linked in the README are where the project points users for support.

The file selector needs a Base URL, and that is a real constraint

Several of the more useful features are conditional in the README. Selecting files from a torrent before and during download, and removing files from a Sabnzbd job before and during download, are both marked as requiring a Base URL. The same pattern appears for choosing token.pickle or a service account and picking upload destinations from a list with or without buttons. This is not a decorative note. It means a deployment behind a reverse proxy without a reachable public base URL loses interactive file selection, and you fall back to downloading whole torrents or whole nzb jobs. For large torrents with a single unwanted file, that is the difference between a ten gigabyte transfer and a two gigabyte one. The README also ties index link support to Bhadoo Google Drive Index specifically, so if you run a different indexer, that integration is not the one documented here.

Where the documentation stops short

The README is a feature inventory, and it is long. What it does not contain is an operational guide. There is no documented rollback procedure, no migration path for the Mongo schema between versions, and no stated upgrade command beyond rebuilding the image. The repository does include update.py and a tests/ directory with pytest.ini, so there is some test scaffolding, but the README does not describe what the tests cover or how to run them. The config_sample.py file is the only reference for configuration keys, and the README's feature list repeatedly refers to global, user and task level settings without listing the keys that implement them. That is a normal shape for a bot of this size, but it means the first deployment is a read-the-source exercise rather than a follow-the-steps one. Budget for that, especially around which settings live in the database and which come from config.py, because the README's own description of the config.py precedence rule makes that boundary easy to get wrong.

How it differs from rclone alone or a plain aria2 front end

The obvious comparison is running rclone and aria2c directly. Those tools move bytes and they do it well, but they give you a terminal, a config file and a log. This bot gives you a chat interface with per-user permissions, per-task overrides, status pages and buttons, and a database that remembers settings across restarts. The trade is operational weight: you now run a Python service, MongoDB, and one or more download daemons, and you maintain all of them. A second comparison is the upstream project the README names, lzzy12/python-aria-mirror-bot, from which this one is derived after substantial modifications. The README attributes the RSS implementation to rss-chan by hyPnOtICDo0g, and the recursive Drive search to Sreeraj's searchX-bot. If your need is a scheduled rclone sync with no interactive component, rclone's own config and a cron entry is less machinery than this bot, and nothing in the README suggests the bot is meant to replace that. It is meant for the case where a human is choosing what to fetch, where to put it, and in what form.

Licence and the cost of keeping it current

The repository is GPL-3.0. If you run it as a private bot for yourself or your team, the practical effect is that you can use and modify it freely, and if you distribute modified versions you carry the GPL obligations with them. The project also depends on a published base image, anasty17/mltb:latest, which the Dockerfile pulls rather than builds, so the container's contents are partly outside this repository's control. On maintenance, the last push was on 2026-09-20, which is recent, but the repository has no retrieved releases, so there is no tagged version to pin against. That is the upgrade cost in concrete terms: you rebuild from master and take whatever changed, with the config.py precedence rule described above as the main thing to re-check after each rebuild. If you need reproducible deployments, the absence of releases means you should pin a commit yourself rather than track the branch. This is not legal advice; GPL-3.0 has specific terms and you should read the LICENSE file in the repository.

Editorial conclusion

Adopt it if you want one Telegram front end for torrents, Usenet, direct links and rclone remotes, and you are willing to run Docker, MongoDB and a config.py on your own host. Do not adopt it if you want a managed service or a one-command install with no database. Before committing, verify that your host can run the container with network_mode host, that you can supply the credentials the features you need require, and that the file selector works from your deployment, since the README ties it to a Base URL.

Frequently asked questions

Official sources

1. anasty17/mirror-leech-telegram-bot on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README