TorToolkit Telegram, the bot that moves files between Telegram and your cloud

A file mover that lives inside a chat window

TorToolkit Telegram is a Telegram bot that downloads content from across the internet and syncs it to cloud storage. The README now carries the name Relaykit and notes that RelayKit was formerly TorToolkit, which is worth knowing because the repository, the config folder and the Docker image still use the older name.

The audience is someone who wants to trigger a download from a chat and have the result land in a drive they control, without logging into a separate server and running commands by hand. The bot advertises support for P2P transfers through qBittorrent, direct link downloads through Aria2, uploads to Google Drive through rclone, and support for services such as Mega, OneDrive, Pixeldrain and InstaDL.

Group behaviour is the part that distinguishes it from a personal script. When the bot sits in a group, each user gets their own settings, including a permanent thumbnail, a choice of file or video output, and the ability to load their own rclone config so the direct link is uploaded to their own drive. The documentation marks that last one as work in progress, which is an honest signal that the per-user upload path is not finished.

Admins can set hard limits on maximum file size and maximum YouTube playlist size, which is what makes the bot usable in a shared chat without turning into an abuse channel.

Extraction, limits and the password retry rule

The archive handling is unusually specific for this class of bot. ZIP, TAR, ISO and RAR archives are extracted with or without a password. If you choose to extract and enter the wrong password, the bot prompts for it up to three times, after which the archive is uploaded as it is.

That fallback is a sensible failure mode. A password-protected archive that a user cannot open would otherwise stay on the server forever, so the bot degrades to storing the original rather than losing it. It also means the extraction is not a security boundary: anything that arrives is unpacked on the host, so a malicious archive is a risk to the machine running the bot.

Other operational limits are named as configuration rather than hidden in code. Mega limits and direct leech limits are both listed as additions, and Mega folder and file leech can be disabled outright, which is the switch a group admin would use to shut that feature off without redeploying.

The changelog also mentions that all mirrors available at the time of the leech can be shown through an option in the rclone settings, service account support that can switch at runtime, and native OneDrive support for both personal and SharePoint accounts. Overall download and upload progress and a central message update are listed as newer additions, along with an alert sent when the bot boots.

The deployment paths, including the one that needs a prebuilt image

Four deployment routes are documented: Heroku, Zeet, VPS with Docker, and VPS without Docker. The last two are the ones with actual instructions.

The Docker route is short. Clone the repo, edit the sample variables file at tortoolkit/consts/ExecVarsSample.py, then run compose. The commands given for the repository root are:

    1. `apt install docker-compose`
    2. `docker-compose up`

If you edit a file later, the documented rebuild is `docker-compose build` followed by `docker-compose up` again. The compose file ships a Postgres service with database tortk and user postgres, and the bot service itself builds from the repository and listens on port 80 mapped from the container.

The catch is the base image. The Dockerfile starts with:

FROM yashk7/tortoolkitbase

COPY requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt

The image is not built from this repository, so it has to exist in a registry and support your architecture. If it is not maintained, the Docker path breaks before your own code is even involved.

The non-Docker path is longer and requires PostgreSQL setup, a virtualenv, and a stack of system packages including aria2, ffmpeg, mediainfo, unzip and p7zip. The final step is to make start.sh executable and run it.

The variables that decide who may use the bot

Configuration lives in a sample variables file, and the compulsory entries are the Telegram credentials plus an allowlist.

API_HASH and API_ID are the Telegram API credentials used to connect, and BOT_TOKEN comes from Botfather. ALD_USR is described as a list of IDs of allowed groups and users who can use the bot in private, with multiple IDs separated by commas. BASE_URL_OF_BOT is the address of the deployment, used for file selection, and the documentation is specific about the format: no trailing slash, and a port appended if you are not on 80.

DB_URI selects the database. The sample line is a Postgres connection string with database tortk, user postgres, a password, host 127.0.0.1 and port 5432, and the instructions tell you to uncomment the lower DB_URI and comment out the upper one when you edit the file. Mongo DB and Postgres DB are both supported, so the URI is not the only backend option.

IS_VPS is the odd one out. Its use is described as only setting it to True if you get errors regarding the web server in a VPS deployment, and only using it as a backup, with SERVPORT changed to your desired port when it is true. In other words, the normal path is a hosted deployment and IS_VPS exists to work around a specific web server problem.

Because the project states that most settings can be changed without restarting the bot, the runtime settings menu is the primary interface, and the file is the fallback for credentials and identity.

A dependency list frozen in 2021 and 2022

The requirements file pins every dependency exactly, and the pins are old. Pyrogram sits at 1.2.9, Telethon at 1.23.0, gunicorn at 20.0.4, psycopg2-binary at 2.8.5 and pymongo at 4.1.1. Two entries matter more than the rest for behaviour: youtube-dl is pinned to 2021.12.17 and yt-dlp to 2022.5.18.

That is the price of the feature set. A YouTube downloader and an Instagram downloader depend on the upstream sites not changing, and both upstream projects have moved a long way since those dates. Expect the download side of the bot to need attention that the rest of the stack does not.

The pinned list also has security implications worth stating plainly. lxml 4.9.0, beautifulsoup4 4.8.2 and gunicorn 20.0.4 are old releases, and the bot runs with a wide surface: it accepts content from arbitrary chat users, unpacks archives on the host, and talks to cloud APIs with the credentials you put in the config file.

On that last point, the licence matters. The project is GPL-3.0, which is the right licence for a self-hosted bot you modify and run yourself. It also means that if you distribute a modified version to others, you owe them the source. No legal advice is offered here, but for a personal VPS that never leaves your control the obligation is theoretical.

Maintenance status and what the docs leave unsaid

The repository is not archived and the last push was on 2026-08-19, on the default branch named alpha rather than main. There are no GitHub releases, so there is no versioned artefact to pin and no changelog beyond the list in the readme.

The documentation is honest about its own gaps. The Whats new section ends with a line saying many more features will be documented if the author remembers, which tells you the documentation trails the code by an unknown margin. The variables section shown in the readme covers IS_VPS and the compulsory entries, but it stops there, so the remaining configuration keys, including the ones that toggle features like the Beta YouTube download progress, are discoverable only by reading the sample file in the repository.

There is also a small inconsistency worth checking before you deploy. The Docker section points at tortoolkit/consts/ExecVarsSample.py, while the non-Docker section has you edit tortoolkit/config/ExecVarsSample.py. One of those paths is probably stale.

The service side is not documented anywhere in the readme either. The rclone configuration, the Mega limits and the G Drive Index support all depend on external accounts and credentials, and the documentation does not explain how to obtain them or what the resulting setup looks like. The documentation assumes you already know the surrounding ecosystem.

Editorial conclusion

TorToolkit Telegram is worth considering for a household or small team that wants a personal Telegram-controlled file pipeline into cloud storage, since the rclone integration, per-user group settings and admin size limits are more concrete than most bots in this space. It is a poor fit for anything that needs a maintained dependency tree or a documented upgrade path, because the requirements are pinned to libraries from 2021 and 2022 and the project publishes no releases. Before deploying, verify that the yashk7/tortoolkitbase image is still pullable for your architecture, decide between Mongo and Postgres in DB_URI, and read the extraction and cloud-upload features against the terms of the services you are pointing them at, because the bot automates large transfers and the responsibility for what moves through it stays with the operator.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. yash-dk/TorToolkit-Telegram on GitHub