SaveAny-Bot: a Telegram bot that files your media into Alist, S3 and WebDAV

What SaveAny-Bot does that a plain Telegram download does not

Telegram lets you save a file to your own account or forward it to a chat. It does not let you drop that file into an Alist mount, an S3 bucket or a WebDAV share, and it does not let you save media that a channel has marked as restricted. SaveAny-Bot sits between the two. The README lists the supported inputs as documents, videos, photos and stickers, plus Telegraph pages, and states that it can bypass "restrict saving content" media. Output goes to one of six backends: Alist, S3, WebDAV, local filesystem, Rclone via the command line, or another Telegram chat as a re-upload.

The intended user is someone who already runs storage. If you have an Alist instance, a MinIO bucket or a WebDAV server, the bot turns Telegram into an ingestion channel. The repository also mentions batch download, streaming transfer, multi-user support and storage rules that organize files automatically, so a single bot process can serve several people and route each person's files to a different backend. That is a different shape from a personal downloader script: it is a small service, and the docker-compose.yml gives it a data directory, a cache directory and a downloads directory.

How the bot moves a file from Telegram to your storage

The Go module path is github.com/krau/SaveAny-Bot, and go.mod shows the Telegram side built on gotd/td and celestix/gotgproto, which are MTProto client libraries rather than the simpler HTTP Bot API. That choice is what makes restricted-content saving possible: an MTProto client can fetch media the Bot API refuses to hand over. The storage side is split by backend, with minio-go for S3, and the repository keeps a storage/ directory alongside core/, database/ and plugins/.

Two integrations extend the input side. yt-dlp is used to download media from sites yt-dlp supports, and Aria2 handles URLs and magnets. The Dockerfile installs curl, ffmpeg and yt-dlp into the runtime image, which tells you the container expects to shell out to those binaries rather than reimplement them. There is also a parser plugin mechanism: the repository has a parsers/ directory and the README says you can write JS parser plugins to save files from almost any website. Finally, the watch feature, visible in the pr247-test release tag as feat/watch-notify, monitors specified chats and auto-saves messages that pass filters. So the data flow is: a message arrives from a chat, a user command, a watch rule or a parser; the bot resolves the media; a storage rule picks a backend; the bytes stream to that backend.

Installing SaveAny-Bot with Docker and saving your first file

The README's quick start is a single config.toml plus a docker run. Create the config first. The token comes from @BotFather, and the users block identifies who may use the bot. Note that the sample id, 114514, is a placeholder and the README does not explain what blacklist=true does in this context, so read the linked docs before copying the block as-is.

lang = "en"
[telegram]
token = ""
[telegram.proxy]
enable = false
url = "socks5://127.0.0.1:7890"

[[storages]]
name = "Local Disk"
type = "local"
enable = true
base_path = "./downloads"

[[users]]
id = 114514
storages = []
blacklist = true

With the file in place, start the container. The README mounts config.toml and the downloads directory; the compose file in the repository adds ./data and ./cache and publishes port 8080, so if you use compose rather than docker run, expect those directories to appear next to the compose file.

docker run -d --name saveany-bot \
    -v ./config.toml:/app/config.toml \
    -v ./downloads:/app/downloads \
    ghcr.io/krau/saveany-bot:latest

Once the container is running, message the bot from the Telegram account whose id you put in the users block and send it a file. Because the only enabled storage in this config is the local backend with base_path "./downloads", the file should land inside the mounted downloads directory on the host. If nothing arrives, check the container logs first, then confirm the account id, since a mismatch means the bot will ignore you.

Where SaveAny-Bot gets awkward

The configuration model is the first friction point. Storage backends are declared in a TOML file, and the README shows one local example while pointing to the docs for everything else. That means every new backend is a config edit and a restart, not a setting you toggle in a chat. For a single-operator setup that is fine; for a bot you want to hand to a group of users, it is a maintenance task that never quite goes away.

The second is the dependency surface. The runtime image carries ffmpeg and yt-dlp, and the feature list includes Aria2 and Playwright-based parsers. Those are real processes with their own update cycles, and yt-dlp in particular breaks when sites change. A bot that worked last month can stop extracting from a given site without any change to SaveAny-Bot itself.

Third, the restricted-content feature is an MTProto client logging in as a user, not a bot account. That is the mechanism, and it carries the consequences of that mechanism. The README does not describe session handling, revocation or what happens if the underlying account is limited, and those are the questions to answer before pointing it at anything you care about. Finally, the README does not document rollback, so there is no stated procedure for undoing a storage migration or recovering from a bad write.

SaveAny-Bot against gallery-dl and plain rclone scripts

The closest thing to an alternative is a script that combines gallery-dl or yt-dlp with rclone. That approach is stateless and transparent: you write a shell script, cron runs it, and rclone copies files to the remote. It has no Telegram login, no long-running process and no config schema to learn. What it lacks is the Telegram side entirely. It cannot receive a file someone sends in a chat, it cannot save restricted media, and it has no per-user routing.

A second comparison is a generic Telegram mirror or leech bot. Those typically upload the result back to Telegram or to a single configured cloud drive, and they are built around a command interface in a group. SaveAny-Bot's difference is the storage abstraction: one bot instance can target Alist, S3, WebDAV, local disk, Rclone and Telegram re-upload, and the README describes transferring files between different storage backends. If your goal is "get this Telegram file into my existing object storage," the abstraction is the point. If your goal is "re-upload this to another chat," the simpler bots do that with less setup.

Maintenance cost, licence and what the AGPL means here

The repository is not archived, and the last push was on 2026-09-28, the same day as the v0.62.0 release. Releases are frequent: v0.61.2 landed two days earlier, and a test build tag for a watch-notify feature appeared in between. That cadence cuts both ways. You get fixes quickly, and you also get a moving target, so pinning a specific image tag rather than :latest is the safer default for anything you depend on.

The licence is AGPL-3.0. For self-hosting, that is usually unremarkable. The clause worth understanding is the network one: if you modify SaveAny-Bot and let other people interact with it over a network, the AGPL's source-availability condition can attach to your modified version. Running the unmodified container for yourself or your team is the ordinary case. This is not legal advice; if you plan to offer a modified build as a service, get your own reading of the licence text. Upgrades are a container pull plus a config review, since new options appear in config.example.toml and your existing file will not have them.

Editorial conclusion

Adopt SaveAny-Bot if you already operate a storage backend such as Alist, S3 or WebDAV and want a Telegram front end that files media into it without manual steps. Skip it if you need a hosted service, a per-user quota system for strangers, or a project with a documented rollback path, since the README does not describe one. Before deploying, verify two things yourself: that your storage credentials work against the exact backend type you configured, and that the user entry in config.toml matches your own Telegram account id, because the sample value is a placeholder.

Frequently asked questions

Official sources

1. krau/SaveAny-Bot on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases