I got tired of paying monthly fees just to host a few hundred GB of files for side projects. So I built TeleCloud — a serverless file storage platform that uses the Telegram Bot API as its actual storage backend. No S3, no R2, no Backblaze, no monthly bill. It's live at telecloud.m2hio.in.

This post covers why this works, the architecture, the inevitable tradeoffs, and the situations where I'd absolutely not use this approach.

Why Telegram?

Telegram bots can send and receive files up to 2 GB each. The bot API returns a stable file_id string for every uploaded file, which you can later exchange for a temporary CDN download URL. The actual storage is on Telegram's infrastructure — your bot is just a key-management layer.

This gives you, in practical terms:

• Effectively unlimited storage — Telegram has never imposed a per-bot quota in the years it's offered this.
• Free egress — when a user downloads, they hit Telegram's CDN, not your server.
• Multi-region distribution for free.

Architecture

The system has three parts:

1. A Cloudflare Worker serving the web UI and API (free tier).
2. A Telegram bot that forwards uploads into a private channel and stores metadata in Cloudflare KV.
3. The UI — a thin React app that talks to the Worker and displays files.

Upload flow

1. User picks a file in the browser. Worker generates a one-time upload token.
2. The browser POSTs the file to the Worker, which streams it to the Telegram sendDocument endpoint with the bot token.
3. Telegram returns a file_id. The Worker stores filename, size, owner, and timestamp metadata in KV under a UUID key.
4. The user gets back a clean URL like /f/uuid.

Download flow

1. Visitor hits /f/uuid.
2. Worker reads metadata from KV, calls getFile on the Telegram bot to get a temporary download path.
3. Worker 302-redirects to the Telegram CDN URL.
4. The visitor's browser downloads directly from Telegram. The Worker is no longer involved.

Total Worker invocations per download: 1. No proxying, no egress charges, no compute cost beyond a CPU-time slice that fits inside the Cloudflare free tier.

The tradeoffs (read these before you copy this)

You don't own the storage

If Telegram changes their bot API terms or rate limits, your files become inaccessible. This is fine for personal projects and weekend tools. It is absolutely not fine for production storage anyone depends on. Don't put your customer's data here.

Per-file size cap

The 2 GB hard limit per file is fine for almost everything but breaks for large video uploads. I added a chunking layer that splits files at 1.9 GB and reassembles them on download — but that means the simple "one file, one redirect" design becomes a stream-merging proxy for chunked files, which eats Worker CPU.

Cold-cache download latency

Each download requires one getFile round-trip to the Telegram API. That's typically 80–150ms before the redirect. I tried caching the temporary CDN URL in KV with a TTL, but Telegram's URLs expire after about an hour and become 404s — so caching aggressively backfires.

Numbers

• Total stored: ~600 GB across 14,000 files (mostly mine and friends').
• Median download latency: ~190ms (worker + Telegram getFile + redirect).
• Monthly cost: $0. Cloudflare free tier is enough.
• Reliability over 8 months: ~99.7% (a few Telegram API hiccups).

Should you build this?

For personal projects, demo data, throwaway file sharing, or hobby tools — absolutely. For a service customers pay you for — no. Use R2, S3, or B2 and pay the few cents per GB. Reliability and ToS predictability are worth more than the savings.

If you want to use TeleCloud as-is, it's free at telecloud.m2hio.in. If you want me to build something similar but on real cloud storage, I'm at m2hgamerz.prince@gmail.com.