How to Host a Telegram Bot 24/7 on a VPS: Production Guide

Polling vs Webhook: Which Architecture Should You Choose?

Before writing a single deployment script, you must determine whether your bot will retrieve incoming user messages using Long Polling (getUpdates) or Webhooks (setWebhook). Each pattern involves fundamentally different server networking and resource consumption profiles:

The Verdict: If your bot manages high-volume customer orders, payment notifications, or group chats with over 5,000 members, always configure a Webhook behind an Nginx reverse proxy. For private automation tools and internal notification scripts, Long Polling managed by systemd is perfectly reliable.

Server Preparation (Ubuntu 24.04, Python / Node, venv)

Provision an Ubuntu 24.04 LTS instance on SkyRainCloud. Avoid using the root user for executing user-facing scripts. Creating an isolated system user prevents accidental operating system file corruption or security breaches:

# Update repositories and basic tools
sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl ufw build-essential python3-pip python3-venv

# Create a dedicated system user for the bot
sudo adduser --disabled-password --gecos "" botuser
sudo usermod -aG sudo botuser

Setting Up Node.js Environment (For JavaScript/TypeScript Bots)

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
sudo npm install -g pm2

Setting Up Python Environment (For aiogram / python-telegram-bot)

su - botuser
mkdir -p ~/telegram-bot && cd ~/telegram-bot
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install aiogram aiohttp python-dotenv

Deploying Bot Code with Git & Environment Variable Security

Never hardcode your Telegram Bot API token directly into your codebase. If your repository is accidentally exposed or pushed to a public branch, scraping bots will compromise your token within 60 seconds and spam your users.

Clone your repository via SSH deploy keys or HTTPS, and generate an isolated .env file on the server:

# Inside /home/botuser/telegram-bot/.env
BOT_TOKEN=7123456789:AAFlkjw098dfSDFKjlw3_sampleTokenHere
ADMIN_TELEGRAM_ID=987654321
ENVIRONMENT=production
DATABASE_URL=sqlite:///bot_database.db

Lock down file permissions so other local users or compromised web services cannot read your bot token:

chmod 600 /home/botuser/telegram-bot/.env

Keep It Alive with systemd or PM2 (Zero Downtime)

If you run your bot inside a terminal window using python bot.py, closing your SSH session kills the bot. Even if you use nohup or screen, any unexpected API timeout or memory exception will crash the process indefinitely. You need a dedicated daemon supervisor.

Option A: Managing Python Bots with Linux systemd

Create a systemd unit file at /etc/systemd/system/telegram-bot.service:

[Unit]
Description=Telegram Business Bot Daemon
After=network.target

[Service]
Type=simple
User=botuser
WorkingDirectory=/home/botuser/telegram-bot
ExecStart=/home/botuser/telegram-bot/venv/bin/python main.py
Restart=always
RestartSec=5s
EnvironmentFile=/home/botuser/telegram-bot/.env

# Security Hardening Directives
ProtectSystem=full
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Reload systemd, enable the service to start automatically on system boot, and start it:

sudo systemctl daemon-reload
sudo systemctl enable telegram-bot
sudo systemctl start telegram-bot
sudo systemctl status telegram-bot

Option B: Managing Node.js Bots with PM2

cd /home/botuser/telegram-bot
pm2 start index.js --name "tg-order-bot" --max-memory-restart 300M
pm2 save
pm2 startup systemd

Set Up Webhook with Nginx & Let's Encrypt SSL

Telegram strictly enforces that all webhook URLs use valid SSL/TLS certificates issued by a trusted CA. Self-signed certificates require complex manual public key uploads, whereas a free Let's Encrypt certificate takes 60 seconds to configure.

Assuming your internal bot runs a local HTTP webhook server on port 8080 (e.g. via aiohttp or express), create an Nginx configuration file at /etc/nginx/sites-available/telegram-webhook:

server {
    server_name bot.yourdomain.in;

    location /webhook {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo certbot --nginx -d bot.yourdomain.in --agree-tos -m admin@yourdomain.in

Register your webhook URL directly with Telegram's servers via curl:

curl -F "url=https://bot.yourdomain.in/webhook" "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/setWebhook"

Logs, Monitoring & Auto-Restart Troubleshooting

In a production environment, you should never have to guess why a bot rejected an input. Systemd forwards all stdout and stderr streams directly to the Linux journal system. You can inspect real-time live logs with:

# Stream real-time logs:
sudo journalctl -u telegram-bot -f

# Check last 100 log lines on failure:
sudo journalctl -u telegram-bot -n 100 --no-pager

If you are using PM2, execute pm2 logs tg-order-bot or pm2 monit for a visual terminal dashboard showing real-time CPU spikes, heap memory usage, and exception stack traces.

Scaling Architecture for 10,000+ Active Users

When your bot surpasses 10,000 active users or handles broadcast notifications, executing heavy business logic (such as generating PDF invoices or querying external CRM APIs) directly inside the message-receiving handler will block Telegram's incoming requests and trigger timeout drops.

• Asynchronous Message Handlers: Always leverage asynchronous frameworks such as aiogram 3.x (Python) or GrammY / Telegraf (Node.js). Never use blocking I/O functions like requests.get() or time.sleep().
• Background Task Queues: Offload heavy execution tasks to a local Redis instance paired with Celery or BullMQ. The bot acknowledges Telegram instantly with an HTTP 200 OK, while background workers process the job.
• Database Connection Pooling: SQLite fails under high concurrent writes. Upgrade to a local PostgreSQL instance running with connection pooling to handle simultaneous customer checkout flows.