Skip to content

Telegram bot VPS with HTTPS, a static IP and 24/7 uptime

A Telegram bot lives or dies by whether setWebhook can reach a public HTTPS URL, or whether your long-polling loop stays alive. You get both: an open port 443, Let's Encrypt in one command and systemd built in.

  • Static IPv4 included
  • Root SSH access
  • Pay with crypto, no KYC

Webhook or long polling: different hosting needs

Telegram bots either sit in a getUpdates loop or expose a public HTTPS endpoint. Both work properly here.

Webhook: Telegram pushes to you

Telegram POSTs each update to an HTTPS endpoint you register with setWebhook. It needs a valid TLS certificate on port 443, 80, 88 or 8443, a static IP and an always-on server. The fastest option, with no idle polling.

  • Static public IP and open port 443
  • Free Let's Encrypt certificate
  • Nginx or Caddy one apt install away
  • setWebhook is a one-liner after deploy

Long polling: your bot pulls from Telegram

getUpdates keeps a request open until Telegram has something to send. No inbound port or certificate needed, but the process must run 24/7, and duplicate handlers drop updates.

  • No TLS setup, start with one command
  • Ideal while prototyping
  • Works behind an outbound-only firewall
  • systemd keeps the poll loop alive

Telegram won't talk to a plain HTTP endpoint

setWebhook rejects http://, self-signed certificates with unknown roots and any port outside 443, 80, 88 or 8443. At home that means dynamic DNS and port forwarding. On our VPS, one certbot command gives you a valid Let's Encrypt certificate that renews itself.

  • Free Let's Encrypt certificates
  • Static IPv4
  • Nginx and Caddy ready
  • HTTP/2 and TLS 1.3
bot.example.com
# 1. TLS certificate (free, auto-renew)
$ sudo certbot --nginx -d bot.example.com

# 2. Register the webhook with Telegram
$ curl -F "url=https://bot.example.com/tg/<secret>" \
    https://api.telegram.org/bot$TOKEN/setWebhook
{"ok":true,"result":true,"description":"Webhook was set"}

# 3. Start the bot under systemd
$ sudo systemctl enable --now mybot.service

python-telegram-bot, aiogram and grammY all run natively

Root SSH, pick your stack, add a systemd unit, done.

  • python-telegram-bot
    The reference Python framework. ConversationHandler, JobQueue and PicklePersistence with one pip install, ready for systemd.
    v21, asyncio
  • aiogram
    Async-first, with FSM state, dependency injection and clean routers. Pairs well with uvicorn and FastAPI in webhook mode.
    3.x, fully async
  • Telegraf / grammY
    Node bots run behind pm2 in seconds. TypeScript, middleware and session stores. grammY's runner scales one bot across CPU cores.
    Node.js 20, 22
  • Telethon / Pyrogram
    Full MTProto access for userbot automation, channel scraping and multi-account setups, with persistent sessions and floodwait handling.
    MTProto userbots

The bots people run here most

E-commerce and order bots

Payment links, order lookup, live shipping status. Fast webhook responses keep checkout snappy.

Alerts and notifications

Price alerts, monitoring pings, deploy notifications. A dedicated VPS means no cold starts and no delivery gaps.

Community and group admin

Anti-spam, captcha gates and welcome flows across dozens of groups, with Redis rate limits on the same server.

MTProto userbot automation

Telethon or Pyrogram jobs on a static IP. Safer than a home network and less likely to be flagged for constant re-logins.

One bot today, ten on the same VPS tomorrow

Add bots as separate systemd units behind one Nginx or Caddy, with one Redis for sessions and rate limits.

  • Reverse proxy
    Nginx or Caddy on port 443 with SNI routing per subdomain. One certificate per bot via certbot's -d flag.
  • Bot processes
    One systemd unit per bot with Restart=always, a dedicated user and an environment file for tokens. Logs go to journalctl.
  • Shared state
    Redis for FSM state and dedup, Postgres for orders and users. Both idle at under 100 MB.

Telegram bot VPS plans

Linux VPS plans with root access. Basic runs 3 to 5 modest bots; Standard handles ten with Redis and Postgres.

Questions before you point setWebhook at us

Still unsure? Our team answers on live chat and in tickets.

Do I actually need a VPS for a Telegram bot, or can I run it on my laptop?

A Telegram bot works exactly as well as the machine it's on. On a laptop or home PC you'll close the lid, restart for Windows Update, lose Wi-Fi, or get a new dynamic IP, and every one of those is a silent outage. Worse, if you're running webhook mode Telegram will retry a failed delivery for up to 24 hours but will pause new updates when your endpoint is unreachable. A VPS gives you a static IP, systemd, and a machine that never sleeps.

Should I use webhook or long-polling mode?

Long-polling is the fast path while you're building: getUpdates works from anywhere with outbound internet, no domain or TLS cert needed. For anything production, webhooks are lower-latency and cheaper in resources: Telegram pushes updates to your HTTPS endpoint instead of your bot idling in a getUpdates loop. Webhooks require a valid TLS certificate (Let's Encrypt is fine) on port 443, 80, 88 or 8443, plus a stable public IP, which is exactly what a VPS gives you.

How do I get HTTPS on my VPS for setWebhook?

Point a subdomain like bot.yourdomain.com at your VPS's IPv4, then run certbot with the Nginx or Caddy plugin: one command, free 90-day cert, auto-renew via cron. Caddy will do it in a single Caddyfile line with `bot.yourdomain.com { reverse_proxy localhost:8443 }`. If you don't own a domain, you can use Cloudflare's free tier and terminate TLS at their edge, though direct is simpler.

Can I run python-telegram-bot and aiogram side by side?

Yes. Each bot has its own token, its own process, and its own port (in webhook mode). We recommend one systemd unit per bot with Restart=always, and a shared nginx or Caddy reverse proxy fronting them all on :443. The Basic plan (6 GB RAM, 2 vCPU) comfortably runs 3–5 modestly-sized bots; Standard handles ten with Redis and Postgres on the same box.

How does auto-restart work when my bot crashes?

For Python bots, a 10-line systemd unit with `Restart=always` and `RestartSec=5` is the standard: your bot is back online in under 5 seconds after a crash or reboot. For Node bots, pm2 does the same job and adds log rotation and cluster mode. systemd is built into our Linux images and pm2 is one npm install away. Point Uptime Kuma at a healthcheck endpoint and you get pinged the moment anything looks off.

What are Telegram's actual limits I should design for?

The Bot API caps outbound at ~30 messages/second per bot globally and 1 message/second per chat, with bursts allowed. Group-wide announcements need to be spaced. python-telegram-bot's AIORateLimiter and aiogram's throttling middleware handle this automatically. On the VPS side you never hit any limit; the constraint is Telegram's.

Can I run a Telethon or Pyrogram userbot on the same VPS?

Absolutely. Userbots use MTProto (not the Bot API), so they run alongside your Bot API workers without conflict. If you're keeping several sessions warm, the Pro plan (6 vCPU / 12 GB) is enough for a healthy handful of concurrent Telethon workers plus a Redis session store. Static IPs help here: Telegram is less likely to flag account re-logins from a consistent address.

Linux or Windows?

Linux. Ubuntu 22.04 or Debian 12 is what every Telegram bot framework ships against: pip, apt, systemd, nginx, certbot, docker compose, all one command away. Windows is available if you need it, but every tutorial and framework's docs assumes Linux.

How fast can I deploy?

Your server is set up as soon as your crypto payment confirms: a minute or two on USDT TRC-20, 10–20 minutes on BTC or XMR, with root SSH credentials emailed instantly. After that: `git clone`, `pip install`, `systemctl start`, `curl -F url=…` to setWebhook, and you're live.

Give your Telegram bot a real address on the internet.

Static IP, valid TLS certificate and a systemd unit that survives every reboot.

Order a Telegram bot VPS