WZML-X Review: Telegram Mirroring and Leeching with Docker

WZML-X's Telegram Transfer Problem

WZML-X addresses a specific coordination problem: moving files into or out of Telegram while retaining control over download sources, queueing, storage, and upload destinations. It is aimed at administrators who want Telegram to act as the user-facing control surface for larger transfer workflows. The intended users are not limited to people who send ordinary documents. The project supports torrent and NZB selection, direct downloads, qBittorrent, Aria2, JDownloader, Mega, Telegram files, and sites handled by yt-dlp.

The other half of the problem is delivery. A file can be downloaded locally, split for Telegram, mirrored back to Telegram, or uploaded to Google Drive, Rclone, Mega, or another supported route. WZML-X also provides a web interface for reviewing and selecting contents before finalization. That selection stage matters for archives and torrents containing multiple files because it can prevent a transfer from starting without a deliberate choice.

This is a platform-oriented tool rather than a narrow downloader script. Its value comes from putting several transfer paths behind one bot and configuration layer. The cost is a larger deployment surface: the application, bot identity, database, web tunnel, local volumes, and optional external services all become relevant during setup and troubleshooting.

How WZML-X Moves Files Through Docker

The documented runtime combines a Python Telegram bot with a FastAPI-based web interface and a configurable transfer pipeline. The repository layout places the bot logic under bot/, plugins under plugins/, web resources under web/, and operational configuration files such as config_sample.py, start.sh, update.py, and cron_boot.py at the repository root. This layout supports the README's claim that mirroring, leeching, and selection are parts of one application rather than unrelated clients.

Docker Compose defines an app service and a tunnel service. The app builds from the Dockerfile, runs bash start.sh, mounts config.py as read-only, and persists accounts and downloads in host directories. It exposes port 8080 internally. The tunnel container shares the app's network namespace and reads a shared tunnel data volume. According to the deployment guide, its generated Cloudflare quick-tunnel URL is the address of the web interface.

Configuration controls both routing and user experience. DEFAULT_LANG selects the bot language, DEFAULT_UPLOAD selects the initial destination, LEECH_SPLIT_SIZE controls leech output splitting, and QUEUE_ALL, QUEUE_DOWNLOAD, and QUEUE_UPLOAD govern concurrency and pressure. SHOW_CLOUD_LINK controls whether generated cloud links are exposed to users. WEB_PINCODE adds a protection mechanism for web access.

This design is convenient for central administration, but it does not make every transfer backend self-contained. A configured target still has to authenticate, accept uploads, impose its own quotas, and remain reachable from the container.

Deploying WZML-X and Reaching Its Web UI

The README recommends Docker on a VPS or dedicated server. The initial deployment copies the repository, creates config.py from the sample, and starts the Compose project. The required configuration names are BOT_TOKEN, TELEGRAM_API, TELEGRAM_HASH, OWNER_ID, and DATABASE_URL. Optional integrations require their corresponding service credentials.

The following commands reproduce the documented deployment sequence. config.py is mounted read-only by the app service, so edits should be made in that host file before restarting the services.

git clone https://github.com/SilentDemonSD/WZML-X.git
cd WZML-X
cp config_sample.py config.py
docker buildx compose up -d

After editing config.py with the Telegram credentials, owner ID, MongoDB connection, and desired integration settings, start the stack again if it was already running. The documentation then directs the operator to inspect the tunnel logs:

docker compose logs tunnel

The reader should look for a `https://*.trycloudflare.com` URL. That URL is the documented entry point to the bot's web interface. Its changing hostname matters for any later browser bookmarks or access documentation.

Stopping the deployment uses the Compose teardown command:

docker buildx compose down

A manual single-container path also exists, although it bypasses the documented multi-container tunnel setup:

docker build -t wzmlx .
docker run -p 8080:8080 wzmlx

Queueing, Selection, and Cloud Uploads

The configuration separates queue controls for the overall system, downloading, and uploading. This is useful when Telegram output and remote storage have different throughput limits. Operators can tune the queue variables rather than replacing the bot or rewriting its workflow. LEECH_SPLIT_SIZE then governs how large leech outputs are divided, while DEFAULT_UPLOAD determines the destination used by default.

The web selection interface covers torrent, NZB, and upload contents. Based on the repository structure, selection state is handled by the web portion of the application while bot plugins carry out transfer operations. WEB_PINCODE should be treated as an operational control rather than decorative UI configuration, especially because the documented default deployment publishes the interface through a Cloudflare quick tunnel.

Cloud delivery is configurable rather than limited to Google Drive. The README names Rclone, Mega, and other supported routes. SHOW_CLOUD_LINK determines whether users receive the resulting link. This setting should be matched to the privacy model of the deployment. Enabling links can improve usability, but it also means the audience for the bot may receive direct addresses to uploaded content.

The pipeline has many possible endpoints, so diagnosing a failed transfer requires identifying the stage. A local download failure, bot API rejection, split-size problem, remote upload failure, and database update failure are not interchangeable. The README does not provide a complete troubleshooting matrix or rollback procedure for these states.

qBittorrent, Aria2, yt-dlp, and Integration Boundaries

WZML-X does not implement every transfer mechanism as a standalone Python downloader. Its dependency list includes aioaria2, aioqbt, qbittorrent-api, yt-dlp[default,curl-cffi], and libraries for Google APIs, Mega-related operations, SABnzbd, and Rclone integrations. The design therefore sits above specialized clients and services. It coordinates requests and destinations while delegating protocol or client work to configured backends.

That approach is a good fit when several sources must feed one Telegram workflow. It also means operator error can occur at several layers. qBittorrent needs a reachable instance and working credentials. Aria2 needs a compatible RPC endpoint. Google Drive uploads require Google API credentials. yt-dlp support still depends on the external sites remaining compatible with the installed extractor.

The README specifically warns qBittorrent users to tune `AsyncIOThreadsCount` to the machine size. That is a resource-management concern rather than a feature toggle. The container also persists downloads on a host-mounted volume, so disk capacity and filesystem permissions can become transfer constraints.

For a direct-link workflow that must only fetch and upload files, WZML-X may be excessive because it requires a Telegram bot, owner credentials, database configuration, and web access. A dedicated yt-dlp or aria2 workflow would have fewer moving parts. WZML-X becomes more defensible once the same bot also needs Telegram leeching, content selection, queue control, and several storage destinations.

Security, Secrets, and Multi-Instance Operations

The deployment requires a bot token, Telegram API credentials, an owner ID, and a MongoDB connection string. Optional integrations add more credentials to config.py. The repository's Compose file mounts that file into the container as read-only, which prevents runtime modification through the container mount, but host access control and file permissions still determine whether secrets remain private. The README does not document a secrets manager or an external secret-injection procedure.

The default web route uses a Cloudflare quick tunnel. The README identifies the resulting URL but does not document a custom stable domain, authentication provider, or production hardening guide beyond `WEB_PINCODE`. Operators should verify whether a PIN code is sufficient for their audience before exposing selection and upload controls.

Multi-instance deployment is possible through separate config files and separate host directories for accounts and downloads. The commented Compose example also gives each tunnel a distinct `TUNNEL_URL_FILE` value. This separation reduces state collisions between bots, but it also multiplies database, volume, port, and credential administration.

Operators who need all outbound traffic through a VPN can uncomment the Gluetun service, add provider credentials, and set the app service to use `network_mode: "service:gluetun"`. That route covers both the application and cloudflared tunnel according to the README. It introduces another failure domain, so VPN connectivity and container restart behavior need verification.

License, Upgrades, and Container Cleanup

WZML-X is distributed under AGPL-3.0. That matters for operators considering source modifications or network deployment because the license includes source-code obligations for covered modifications, but this review does not provide legal advice. The repository includes a LICENSE file, which should be reviewed for the intended deployment and distribution model.

The last push was on 2026-10-04, and the listed releases include v3.1.6-x from 2026-07-04, v3.1.5-x from 2026-06-14, and v3.1.4-x from 2026-06-11. The repository is not archived. Its Python dependencies include a fixed cryptography version and unpinned package names, while the Dockerfile installs requirements into the image during the build. An upgrade can therefore combine project changes with dependency changes.

The Compose stack bind-mounts downloads and accounts from host directories and uses a named volume for tunnel data. The README advises stopping the container before removing it and removing the container before pruning images. These ordering requirements reduce accidental disruption, although pruning commands can delete other unused Docker data as well:

docker container prune
docker image prune -a

The README does not document backup procedures for MongoDB or the persisted volumes, nor does it define a rollback sequence for a failed upgrade. Those gaps should be settled before treating the stack as the only copy of transfer state or configuration.

Editorial conclusion

WZML-X fits operators who already manage Telegram credentials, MongoDB, Docker volumes, download clients, and cloud upload accounts, and who want selection and upload workflows under one bot interface. It is a poor fit for a casual user seeking a one-command installer or for anyone unwilling to secure the web UI and credential files. Before adoption, verify that the default Cloudflare quick tunnel suits the deployment, confirm every required value in config.py, and test the intended qBittorrent, Aria2, cloud, and upload integrations in the chosen environment.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. SilentDemonSD/WZML-X on GitHub