A VPS for a Telegram bot

Far less than it is usually sold. A bot is a long-lived process that spends nearly all of its time waiting: a stateless command bot sits around 60 MB, and one carrying an ORM, a scheduler and a cache is nearer 150 MB. After the operating system takes its 300 MB or so, a 1 GB machine still has room for 4 heavy bots or 12 light ones. The number of USERS barely enters into it, because Telegram delivers updates one at a time to your process, not a connection per user. What does change the answer is state you hold in memory yourself — a large cache, an in-process database, a model.

Long polling to start, webhooks when it matters. With long polling your bot opens a connection out to Telegram and waits — it needs no domain, no certificate and no open port, which means it works behind NAT and is the fastest way to get something running. A webhook has Telegram connect to YOU, so it needs a public address, a valid TLS certificate and a port open to the internet, and in exchange it removes the polling loop entirely and scales better when the bot is genuinely busy. Both run fine on the smallest machine here. The honest reason to move is load or latency, not fashion.

Telegram's own limits, not ours: a bot using the public Bot API can download files up to 20 MB and upload up to 50 MB. Running your own Bot API server lifts that to 2 GB and, more importantly, makes the files land on your server's disk rather than passing through Telegram's. That is the one change that genuinely alters what machine you need — suddenly disk and transfer matter, which is why the table above puts BD-8 against that row and not against the others.

A text bot, never. A media bot, possibly, and it is worth thirty seconds of arithmetic: average file size × messages a day × 30. Fifty thousand voice notes a day at 3 MB is about 4.3 TB a month, which is past the allowance on most cheap plans and nowhere near the 32 TB on BD-8 — or the unmetered line, where the question does not arise. Both directions count: a file your bot receives and a file it sends are both traffic.

A systemd unit, not a screen session. Write a small service file with Restart=always, enable it, and the bot comes back after a crash and after a reboot without you being awake for it. This is the single most common reason a bot "goes down" on a VPS, and it is not a hosting problem — a process started by hand dies with the SSH session that started it. Docker with a restart policy does the same job if you would rather package it that way.

Yes, and most people should. Each is a separate process with its own systemd unit and its own token; they share the machine, the database if you want, and nothing else. The arithmetic in the table is exactly this question — a 4 GB machine holds 25 heavy bots before memory is the constraint. Keep them on separate ports and separate users if they are for different people.

Anywhere your users can reach and your latency to Telegram is sane — the bot talks to Telegram's infrastructure, not directly to your users, so the usual "close to your audience" rule matters less here than for a website. If the bot also serves a web dashboard or an API to those same users, size the region for that instead. If you are unsure, deploy by the hour in two regions, measure, and destroy the one that loses: $0.0108 an hour makes that a cheap experiment.