Telegram in Production — the parts that bite you
Not a boilerplate. The five places a Telegram bot or Mini App works perfectly in testing and then fails in front of real users — each one fixed in dependency-free code, each one backed by a measurement you can read for free before you buy anything.
Instant download · 40 KB ZIP, Python + Node, no dependencies · commercial use allowed
Get the pack — $19Why this is not another starter template
Search for a Telegram bot boilerplate and you will find a dozen good ones, free, doing project setup better than anything anybody sells. Buying that would be silly, so this pack does not compete with it.
It handles the other end of the job. Your bot works. The Mini App opens. Then someone forwards a 30 MiB video and the bot goes silent, or a poll comes back with a timer you did not ask for, or the unit file that ran fine by hand crash-loops for thirty-four hours under systemd because Environment= spelled a variable differently from your code. Each of those is a specific, findable behaviour of the platform — and each one costs a weekend to discover from the inside.
What's inside
- 01-initdata-auth — 22 tests
Mini AppinitDatavalidation that survives Bot API 8.0: excludessignatureas well ashash, hashes raw values, enforcesauth_date. Python and Node, same behaviour in both. The field that breaks every validator copied from a 2023 blog post. - 02-poll-limits — 12 tests
The hard wallssendPollrefuses, and — the reason the module exists — the three things it accepts and then silently changes. Ask for a 4-second timer and get 5, withok: trueand no warning. - 03-deploy-1gb — 10 tests
A commented systemd unit template pluspreflight_unit.py, which lints a unit for the two failure modes that cost me weeks: a relativeExecStartunder systemd's empty PATH, andEnvironment=names that do not match what the code actually reads. - 04-preflight — 26 items
One page to run down before going live. Every item names the command that proves it, rather than the feeling that it is probably fine. - 05-file-limits — 11 tests
The exact download and upload boundaries, an encoder that refuses to build a body Telegram would cut, and the retry guard for the over-limit upload that returns no error at all.
Plus a README per module explaining what breaks, why, and what the code does about it — and, in each one, an explicit note on what was not measured.
What "measured" means here
Every limit in the pack was probed against the live Bot API, one byte or one character either side of the boundary, before it was written down. The strongest example is the one I would want to see if I were buying:
Telegram's upload wall is not on your file, it is on the whole HTTP request body — 52,428,799 bytes of body was cut exactly like 52,428,800 was, which is not how a file-size limit behaves. So the largest file you can send is the cap minus whatever your multipart encoder wraps around it. For the probe's exact field set that overhead computes to 350 bytes, predicting a maximum of 52,428,450. Sent live: 52,428,450 accepted, 52,428,451 cut. Exact to the byte.
That is a prediction made in advance from the structure of the request and then confirmed, not a number read off a documentation page — and it is what test_overhead_reproduces_the_measured_350_bytes pins in the test suite, so it stays true.
55 tests, and you can run them before you trust any of it
No test framework, no dependencies, nothing to install. This is a clean extract of the zip a buyer downloads, not the working tree it was built in:
Run from telegram-prod-pack-v1.1.zip, sha256 eadfd85a…, on 2026-08-08.
Read the measurements first — they are free
Each module has a write-up behind it, published here before the pack existed. Read them, take the numbers, and only buy if you would rather have the finished code than write it yourself:
- I forged Telegram Mini App initData — which payloads pass validation, and the field that broke every old validator
- I tested Telegram's poll limits — the walls, and the three silent rewrites
- 13 Telegram bots on a $4.17 VPS — measured memory, and the two systemd traps
- Telegram's file size limits, measured to the byte — where the 350-byte prediction above comes from
The asymmetry worth knowing even if you never buy this
A bot can send 2.5× what it can fetch. getFile serves 20,971,520 bytes — 20 MiB exactly, so a guard written as size > 20_000_000 turns away nearly a megabyte of files that work fine. Above that ceiling the update is still valid, the file_id is still real and file_size is populated, so nothing in your code looks wrong; the file simply never arrives.
Worse, an over-limit upload does not come back as a 413. Telegram drops the TLS connection about thirty seconds in, so your client raises a transport error — and the retry policy almost everyone writes ("give up on 4xx, retry transport errors") will re-send an impossible body forever, logging what looks like an intermittent network fault. That one is in the pack because it is the kind of bug you do not find by reading; you find it in a billing statement.
The parameter reference for all of this is the official Bot API documentation, and the higher ceilings mentioned below come from the local Bot API server project.
What this pack does not cover
Stating this here rather than after you have paid. The measurements behind the pack ran one bot over one network path against the cloud Bot API. A self-hosted Bot API server raises the file ceilings substantially and none of that was measured. The upload-by-URL path, where Telegram fetches the file itself, was not probed either. The aiogram finding in module 01 concerns versions 3.27.0 and 3.30.0 and may well be patched by the time you read this — the module ships the correct implementation, which is correct either way.
There is also no payments module, no database layer and no hosting. It is four small code modules and a checklist, not a framework.
Questions
- Is this a bot boilerplate or starter template?
- No, and deliberately not — see the first section. Free skeletons already do setup better. This is what goes wrong afterwards.
- What does it need to run?
- Python 3 for four modules, Node for the second
initDataimplementation. No framework, no dependencies, no test runner:python3 test_telegram_files.pyand it runs. - Does it work with aiogram, python-telegram-bot or grammY?
- Yes. Plain functions with no framework coupling — call them from whatever you already use, or before your library sends the request.
- What is in the download?
- A 40 KB ZIP: four code modules with their tests, the 26-point pre-ship checklist, a README per module, and the licence.
- Can I use it in client work?
- Yes, including commercial work. The one restriction is that you may not resell the pack itself.
- What if I find something wrong in it?
- Email charliemorrison2228@gmail.com. A correction with a reproduction is worth more to me than a kind review, and corrections ship as a free update.
Also on the Telegram side of this site
- The bots I run: what each one does and what it cost to keep alive
- The Telegram Party Pack: the other end of the catalogue — 255 group-chat prompts, no code involved
- The build log: everything measured along the way
Built and written by Charlie Morrison. Test counts on this page come from running the shipped zip, not from memory.
← Browse all products