VPS for a Telegram bot: what the bot needs and how to pick a plan

A search for "VPS for a bot" usually ends with the cheapest plan, and half the time that is the right call. Problems show up later: a broadcast returns 429 errors, the bot cannot download a video a user sent, the webhook stops arriving after a move to a new server, or messages get lost during a night of downtime. Almost all of this comes from how the Bot API works, not from a lack of cores. Below: how to estimate your bot's load, which Telegram rules set the server requirements and what to check in a plan before paying.

What a bot actually consumes

The bot itself is a small process that receives updates from Telegram and sends replies. The resources go to everything around it.

• Network and latency. Every bot action is an HTTPS request to api.telegram.org. For a menu bot, a stable connection matters more than bandwidth: traffic is measured in megabytes per day.
• Database. With a few hundred users SQLite is enough. Once there are thousands of users, orders, statistics and concurrent requests, you need PostgreSQL or MySQL, which means hundreds of megabytes of memory and a fast disk.
• Queues and background jobs. Broadcasts, scheduled reminders, payment processing through external services. Usually that is Redis plus a separate worker process.
• Files. Video conversion, image generation and PDF reports load the CPU and disk more than everything else combined.
• External APIs. A bot that forwards requests to an AI model over an API barely loads the server: it just waits for the answer. A bot with a local model is a job for a powerful server or a GPU.

Estimate not "how heavy the bot is" but how many such components it has and which of them run all the time.

Bot API limits that affect the server

Telegram has limits that no amount of server power will lift. Know them before choosing a plan so you do not pay for resources the bot cannot use.

• Sending rate. Telegram advises against sending more than one message per second to a single chat, more than 20 messages per minute to a group, and bulk broadcasts faster than about 30 messages per second. Above that, the Bot API returns error 429 with a retry_after parameter. A broadcast to 10,000 users takes several minutes on any server, so you need a rate-limited queue, not extra cores.
• File size. Through the standard Bot API a bot downloads files up to 20 MB and uploads up to 50 MB. For more, you run your own Bot API server (the open-source telegram-bot-api project): it removes the download limit and allows uploads up to 2000 MB. That server keeps files on disk, so it needs spare disk space and memory.
• Update retention. While the bot is down, Telegram stores incoming updates, but for no longer than 24 hours. A day of downtime without monitoring and some user messages are gone for good.

Webhook requirements for the server

The basic webhook rules, HTTPS and ports 443, 80, 88 or 8443, are covered on the VPS for a Telegram bot page. A few more requirements usually come up only after the server is bought.

• IPv4 only. Telegram delivers webhooks to IPv4 addresses only; IPv6 is not supported. The cheapest plans without a dedicated IPv4 will not work for webhooks: you are left with long polling or a paid IPv4.
• TLS 1.2 and newer. Old SSL versions and TLS 1.0/1.1 are rejected. The certificate must match the domain; a self-signed certificate works if you upload it when calling setWebhook.
• Source addresses. Requests come from the subnets 149.154.160.0/20 and 91.108.4.0/22. You can open the webhook port in the firewall for these only.
• Secret header. The secret_token parameter of setWebhook makes Telegram add the X-Telegram-Bot-Api-Secret-Token header to every request. Check it in your app to drop forged requests.
• Parallel connections. By default Telegram keeps up to 40 simultaneous connections to the webhook (configurable from 1 to 100). If the handler is slow, requests pile up, so hand heavy work to a queue and answer Telegram right away.

While a webhook is set, you cannot receive updates with getUpdates. When moving to a new server, bring the bot up there first, then point the webhook to the new address; use the drop_pending_updates parameter only if you really do not need the queued updates.

Which plan for which bot

Guidelines for a Linux server running a bot in Python, Node.js or Go. The figures include headroom for the system, logs and updates.

For the first two profiles see VPS with 1 GB and VPS with 2 GB. If the bots live in containers you need KVM virtualization, see VPS for Docker. A database with thousands of users benefits noticeably from NVMe, see VPS for databases.

What to check in a plan

• A dedicated IPv4 is mandatory for webhooks and makes working with external APIs easier.
• Core type. Shared cores are fine for a menu bot. For media conversion and scheduled broadcasts that coincide with the neighbours' peak hours, dedicated cores are more stable.
• Hourly billing. Handy for testing the bot under real load before a long payment period without paying for a test server for the whole month, see VPS with hourly billing.
• Snapshots and backups. The bot's user database is the most valuable thing on the server. Check whether backups are included or cost extra.
• Location. For a bot, a stable route to Telegram and to external APIs matters more than ping to users. If the bot stores personal data, check the data residency rules that apply to your users, such as the GDPR in the EU.

How to compare different hosts' network and disk before paying is explained in How to test VPS ping and speed before you pay.

Reliability: so the bot does not lose messages

Restarting after a crash via systemd or Docker is the minimum. It is not enough if the bot earns money.

• External monitoring. Every few minutes check that the bot responds: the getWebhookInfo method shows the number of pending updates and the last delivery error. A growing queue means the bot is stuck even though the process is formally alive.
• Database backups off the server. A daily dump to separate storage. A snapshot at the same host does not help if the problem is with the account or the data centre.
• System updates. Automatic security updates and reboots in a night window when the bot has the fewest users.
• Log rotation. A bot with verbose logs can fill a small disk within a few months, and then the database stops writing.

The token and server access

The bot token gives full control over the bot: with it anyone can read incoming messages and post as the bot. Keep it in environment variables or in a file readable only by the bot's user, never in the repository. Run the bot under a separate user without root rights. Log in to the server with SSH keys and disable password login. If the token may have leaked, revoke it in @BotFather with the /revoke command and issue a new one.

If the bot takes payments, keep payment keys separate from the token and do not log full request bodies from the payment provider.

When one VPS is not enough

A single server handles a bot with tens of thousands of users if heavy tasks go through a queue. Split things up when the database and workers get in each other's way: the database moves to a separate server with NVMe, media workers to a server with more cores. General principles for choosing CPU, memory and disk are in How to choose a VPS. For bots on other messengers there are separate selections, such as VPS for a Discord bot.