How to choose a VPS for a Telegram bot
A small bot needs modest resources. Reliability comes from deployment, queue handling, monitoring and tested backups rather than an oversized server.
Size by workload
| Bot type | Starting point | Scale when |
|---|---|---|
| Simple bot without a database | 1 vCPU, 1 GB RAM, 10–20 GB SSD | Handlers queue or memory becomes tight |
| Bot with PostgreSQL or Redis | 2 vCPU, 2–4 GB RAM, NVMe | Database or queue metrics require it |
| Media or background jobs | 2–4 vCPU, 4+ GB RAM | Measured CPU, memory or storage pressure |
Leave memory for the OS and updates. Database latency and memory often matter more than a large disk. Move long-lived media to object storage or delete it by policy. Use the CPU and RAM guide for a measured upgrade decision.
Long polling, webhooks and location
Long polling is simple and does not require inbound HTTPS. A webhook suits scalable deployments but needs a domain or stable HTTPS endpoint and a valid certificate. In both cases, stable routing to Telegram and third-party APIs matters more than a headline gigabit port.
Test a provider from the real application before moving production. A bot that processes media may also need a generous transfer allowance; review the bandwidth guide for large or unpredictable volumes.
Deploy for repeatable recovery
- Create a non-root service account and use SSH keys.
- Store tokens and passwords in secrets or environment variables, never in the repository.
- Run the process under systemd or a container restart policy.
- Close unused ports and install security updates.
- Rotate logs before they fill the disk.
- Make releases reproducible and document rollback.
Set timeouts for external APIs and use bounded retries with backoff. Do not perform a long task in the message handler: enqueue it, acknowledge the user and limit duplicate execution.
Database, queue and files
| Component | Risk | Monitor |
|---|---|---|
| Bot process | Stops after error or reboot | Health check, restart count, errors |
| Database | Loss or slow queries | Backups, size, connections, query time |
| Queue | Jobs accumulate | Queue length and oldest-job age |
| Media | Disk fills | Quota, retention and cleanup |
| External API | Limits or outage | Timeouts, failure rate and bounded retries |
SQLite may suit one small process with limited writes. PostgreSQL is easier to operate when handlers run concurrently or reporting grows. Redis is useful for cache and queues, but important data needs persistence and backups.
Monitor and test recovery
Use external monitoring: a dead server cannot alert from inside itself. Watch CPU, memory, swap, disk, error rate, handler duration and queue delay. Back up the database separately and restore it periodically. A provider snapshot does not replace a portable copy; see the VPS backup guide.
- Secrets are absent from code and logs.
- The process starts after a VPS reboot.
- Retries cannot create endless duplicate jobs.
- A database backup exists outside the server and restores successfully.
- External monitoring covers uptime, disk and queue health.
- The release and rollback procedure is documented.
Test failure modes before launch
Use a separate test bot or environment and simulate a database timeout, an unavailable third-party API and a server reboot. Confirm that jobs are retried only as intended, duplicate messages are not produced and the process returns automatically. Then fill a temporary disk or trigger an alert threshold safely to verify that monitoring reaches an operator.
This exercise reveals reliability problems that extra CPU cannot solve. Keep the recovery instructions short enough for another maintainer to follow, including token rotation, database restore, deployment and DNS or webhook changes.
Frequently asked questions
Is 1 GB RAM enough?
Often for a simple bot. PostgreSQL, Redis and several containers make 2–4 GB a safer starting point.
Do I need a domain?
Not for long polling. A webhook needs a reachable HTTPS endpoint, and a domain simplifies certificates and migration.
Can the database run on the same VPS?
Yes for a small project with external backups. Separate it later if load or availability requirements justify the complexity.