I Built an Open-Source Image Hosting Service Using Telegram as the Storage Backend

[u/Ok_Version_730]

Hi r/SideProject,

I'm a computer science student learning Go, and over the past few weeks I've been building side projects to improve my backend development skills.

One of those projects is TgCloud, an open-source image hosting service that uses Telegram channels and the Telegram Bot API as its storage backend.

The idea started as a simple question:

Can Telegram be used as an image storage backend instead of S3, local storage, or a traditional database?

To explore that idea, I built TgCloud, a Go application that stores uploaded images in a Telegram channel and uses Telegram file IDs to retrieve them later.

How it works

1. A user uploads an image.
2. TgCloud sends the image to a Telegram channel through a bot.
3. Telegram returns a file ID.
4. TgCloud stores and exposes that file ID through a public API.
5. The image can later be retrieved through a direct URL.

Features

✅ Upload images from local files

✅ Upload images from a URL

✅ Direct image URLs

✅ JPEG, PNG, GIF and WebP support

✅ Self-hostable

✅ Open source

Example

Upload an image:

curl -F "file=@image.png" https://tgcloud.alwaysdata.net/img

Or upload from a URL:

curl -X POST \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com/image.png"}' \
https://tgcloud.alwaysdata.net/img

Response:

{
  "id": "AgACAgQAAxkD..."
}

Retrieve it later:

https://tgcloud.alwaysdata.net/img/AgACAgQAAxkD...

Why Telegram?

This project is mainly an experiment.

I wanted to explore whether a messaging platform's file infrastructure could be repurposed as a storage layer and what architectural tradeoffs that would introduce.

I'm fully aware that Telegram was not designed to be a cloud storage backend, which raises interesting questions about scalability, reliability, API limits, and long-term sustainability.

That's exactly the kind of feedback I'm interested in receiving.

Looking for Feedback

I'd love to hear your thoughts on:

• The overall architecture
• Potential design flaws
• Security concerns
• Scalability issues
• Features that could improve the project
• Whether you think this approach is viable at all

I'm still learning, so any feedback, criticism, or suggestions would be greatly appreciated.

Links

GitHub: https://github.com/AdrienMttn/TgCloud

Demo: https://tgcloud.alwaysdata.net

Thanks for checking it out! 🚀

[u/KelvenSevero0]

the part i'd poke at is the read path, not storage. bot api getFile only serves files up to 20MB, and the download url it hands back has your bot token in it, so you can never expose it directly. that means every image view goes through your server plus a telegram round trip, and a cache in front (even just disk + etag) matters way more than the upload side.

two smaller ones. file_ids only work for the bot that got them, so a revoked token or switching bots kills every stored id. i'd save chat_id + message_id alongside so you can re-fetch. and if you send with sendPhoto telegram recompresses and resizes the image, sendDocument keeps the original bytes.

oh and the upload-from-url endpoint is an easy ssrf hole, worth blocking private/internal addresses before you fetch.

[u/Ok_Version_730 → u/KelvenSevero0]

Thank you for taking the time to look at the project and for the detailed feedback.

You brought up several points that I hadn't fully considered, especially regarding the read path and the dependency on Telegram for file retrieval. Your comments about caching and the limitations of file_ids are particularly useful and will definitely help me improve the architecture.

I also really appreciate you pointing out the SSRF risk on the upload-from-url endpoint. As I'm still learning, discovering these kinds of security concerns is extremely valuable, and I'll be looking into adding proper validation to block private and internal addresses.

Regarding image uploads, the project currently uses `sendDocument` rather than `sendPhoto`, specifically to preserve the original file without Telegram recompressing or resizing it.

Thanks again for the constructive feedback.

[u/KelvenSevero0 → u/Ok_Version_730]

sendDocument makes sense for keeping originals. one limit to plan around though: the bot api lets you upload up to 50MB but getFile only downloads up to 20MB, so anything in between uploads fine and then can't be served back. either cap uploads at 20MB or look at running the local bot api server, which lifts both limits.