Telegram Bots From Scratch: Deployment and Operations

A bot running on a laptop is a prototype. Here is what it takes to run one continuously.

Webhook versus polling

Polling. The bot periodically asks Telegram for new messages. No inbound connections, no domain, runs anywhere.

Advantages: as simple as it gets, nothing to configure, fine for development and most production.

Disadvantages: constant requests, slightly higher latency, weaker under very high load.

Webhook. Telegram delivers updates to your address.

Advantages: more efficient, faster response, better under load.

Disadvantages: requires a public domain with HTTPS and a correctly configured certificate. Plus everything that applies to public endpoints: a secret in the path or header so nobody can send you forged updates.

Which to choose: start with polling. Moving to a webhook is an optimisation not everyone needs, done later without rewriting logic.

An important detail for both: you cannot have a webhook and polling active at once, and you cannot run two instances on one token. The symptom is a bot that replies every other time.

Hosting

A VPS covers most cases. Bots are undemanding: the bottleneck is usually memory under many concurrent conversations and disk space for logs, not CPU.

A home computer suits development only: close the laptop and the bot goes quiet.

A container is convenient when a database and other services sit around the bot: a reproducible environment and simple upgrades - the same principles described for a self-hosted stack.

A webhook additionally requires a domain and a certificate.

Autostart and resilience

A bot is a process that must always be running. What to configure:

Autostart at boot. The server reboots and the bot comes back on its own.

Restart on crash. An unhandled error must not mean “the bot is silent until Monday”.

File logs with rotation. Without logs incident analysis is impossible, and without rotation logs eventually fill the disk.

A dedicated user for the process rather than running as root.

Database backups. Users, orders and state cannot be reconstructed from memory.

Monitoring

The minimum worth having:

• Is the process alive. A simple check every minute.
• A crash notification, ideally not through the bot that just crashed.
• Error counts. A rise means something changed outside.
• Disk space. Logs and the database grow.

A practical observation: bots usually die quietly. They do not crash but stop answering because database connections are exhausted, an external request hung, or the disk filled. A process-alive check will not show that - checking that the bot actually responds is more useful.

Updates

Conversation state outside the process. The main requirement: with state in memory, every update evicts everyone who was mid-flow - see aiogram and state.

Database migrations before starting the new version, not after.

Testing on a test bot. A separate token and a separate database. A test message must not reach real users - see the token.

The ability to roll back. The previous version must start, and migrations must survive a rollback.

Practical advice: update during quiet hours. Even with state in a database, a restart is a few seconds of silence, and it is better if nobody is paying for an order during them.

The overview is in the Telegram bots guide.