A Telegram bot needs almost nothing — except being always on
A Python Telegram bot uses 80 MB of RAM and 1% CPU at idle. Even with 10,000 active users, you stay under 1 GB. The real challenge isn't power: it's availability. A bot hosting your customer support or monitoring alerts can't afford 3 hours of downtime because a neighboring shared VPS saturated the hypervisor.
On an Apex (8 GB, 4 Ryzen 9 vCores), you run a Python bot, its PostgreSQL database, a Redis for message queues — with headroom left for three other projects. It's the use case where our entry plan is objectively oversized, and that's just fine.
Webhook or polling?
Two modes to receive messages:
- Polling (
getUpdates): the bot queries Telegram every second. Simple, works behind any NAT, but adds ~1 s of latency and wastes requests. - Webhook: Telegram pushes each message over HTTPS to your server. Near-zero latency, zero load at idle. This is production mode — and it requires a server with a stable public IP and a TLS certificate. In other words: a VPS.
import telebot
bot = telebot.TeleBot(TOKEN)
bot.set_webhook(url="https://bot.mydomain.com/tg")With Caddy as reverse proxy, the Let's Encrypt certificate renews itself. Telegram only accepts ports 443, 80, 88 and 8443 for webhooks.
Docker + systemd: the combo that never falls
docker run -d --name mybot --restart unless-stopped \
-v /srv/bot:/app mybot:latestAdd a Docker healthcheck that restarts the container if the asyncio loop freezes, and a systemd timer checking every minute that the webhook responds. With that, your bot's availability matches our infrastructure's — 99.99% measured on our public monitors.
Token security
The BotFather token gives total control of the bot. Never commit it: pass it as a Docker environment variable or in a git-ignored .env file. If you suspect a leak, /revoke at BotFather generates a new one instantly — webhooks to update afterwards.
Scaling up
The day your bot exceeds 30 messages/second (Telegram's per-bot limit), the answer isn't a bigger VPS but architecture: Redis queue + multiple workers. An Apex absorbs that architecture without breaking a sweat.