A Telegram bot is, at its core, a small program that talks to the Telegram Bot API. What makes hosting interesting is the two delivery models — long-polling and webhooks — which have very different infrastructure implications. Pick the wrong model for your host and you'll either burn idle compute or miss updates. Here's a fair 2026 guide to hosting Telegram bots, from hobby projects to bots with real state.
Long-polling vs webhooks: the decision that drives everything
Long-polling: your bot continuously asks Telegram "any new messages?" via getUpdates. This needs a persistent, always-running process with outbound internet access. It does not need a public URL. Simple to develop; wasteful to keep running 24/7 if traffic is sparse, and it cannot scale to zero (a sleeping poller misses nothing only because it never sleeps).
Webhooks: you register a public HTTPS URL with Telegram, and Telegram POSTs updates to you. This needs a public endpoint with valid TLS but can be event-driven — ideal for serverless or scale-to-zero hosting, since the process only needs to run when an update arrives.
| Model | Needs public URL | Needs TLS | Always-on? | Best host type |
|---|---|---|---|---|
| Long-polling | No | No | Yes | Always-on container/VM |
| Webhooks | Yes | Yes | No (event-driven OK) | Web service / serverless / edge |
Choose webhooks if you want efficient, scale-friendly hosting. Choose long-polling for the simplest local-to-prod parity when you're fine paying for an always-on process.
A minimal webhook bot
Using a typical Node setup (e.g. Telegraf or grammY), a webhook bot is just a web server:
import { Telegraf } from 'telegraf';
const bot = new Telegraf(process.env.BOT_TOKEN);
bot.start((ctx) => ctx.reply('Hello!'));
bot.on('text', (ctx) => ctx.reply(`You said: ${ctx.message.text}`));
// Expose webhook on the platform's port
const port = process.env.PORT || 3000;
bot.launch({ webhook: { domain: process.env.PUBLIC_URL, port } });Set the BOT_TOKEN and PUBLIC_URL as env vars. Telegram requires the webhook URL to use HTTPS on a valid certificate — which is why automatic SSL from your host matters.
Hosting options at a glance
| Platform | Webhook (public HTTPS) | Long-polling (always-on) | Managed DB | Scale-to-zero |
|---|---|---|---|---|
| PandaStack | Yes (auto SSL) | Yes (paid tier) | Yes (PG/Mongo/Redis) | Yes (free tier) |
| Render | Yes | Yes (worker) | Yes (PG) | Limited |
| Railway | Yes | Yes | Yes | Limited |
| Fly.io | Yes | Yes (Machines) | Managed PG | Auto-stop |
| Serverless (Cloud Run / Workers) | Yes | No (not suited) | Separate | Yes |
PandaStack
PandaStack covers both models and bundles a database, which most non-trivial bots eventually need (to store users, state, or settings).
- Webhook bots deploy as a web service with automatic SSL on a custom domain — exactly the valid-HTTPS endpoint Telegram requires. On the free tier, scale-to-zero means the bot idles to zero cost and cold-starts when an update arrives (acceptable for low-traffic bots; for instant responses use a warm tier).
- Long-polling bots run as an always-on container on a paid compute tier (don't use scale-to-zero for polling — the process must stay alive).
- Managed database (PostgreSQL, MongoDB, or Redis) auto-wired via injected connection vars, so a bot that remembers users or queues work has storage with backups.
- Cronjobs for scheduled broadcasts or maintenance tasks.
- Free tier to start: a web service plus a managed DB covers a typical bot.
Honest caveats: for long-polling you must use an always-on paid tier (free-tier scale-to-zero is wrong for pollers). Free-tier DBs are dev/hobby-sized. PandaStack is newer with a growing ecosystem.
Render
Render hosts webhook bots as web services and long-polling bots as background workers, with managed Postgres. Predictable per-instance pricing and a mature platform make it a reliable home for a stateful bot.
Railway
Railway makes spinning up a bot plus a database fast, with great DX and usage-based billing. Convenient for getting a bot online quickly; metered cost suits bursty traffic.
Fly.io
Fly.io runs either model as Machines, with auto-stop/auto-start that pairs nicely with webhook bots (the Machine wakes on an incoming request) and a managed Postgres option. Good for global low latency or fine-grained control.
Serverless (Cloud Run / Cloudflare Workers)
For webhook bots specifically, serverless is a great fit: the function runs only when Telegram sends an update, scaling to zero between messages. Cloud Run (containers) or Cloudflare Workers (edge) both work well. The catch: serverless is unsuitable for long-polling (you need a persistent process), and you'll wire up a database separately.
How to choose
- Webhook bot, want a bundled DB + auto SSL → PandaStack.
- Long-polling bot needing always-on → PandaStack (paid), Render worker, or a small Fly Machine.
- Pure webhook, want scale-to-zero serverless → Cloud Run or Cloudflare Workers.
- Fastest setup + DB → Railway.
- Edge/global control → Fly.io.
The first question is always polling vs webhook. Webhooks unlock cheap, scale-to-zero hosting; polling needs an always-on process. Once you know which, pick the host that matches — and if your bot stores anything, favor a platform with a bundled managed database so you're not running one yourself.
References
- Telegram Bot API: https://core.telegram.org/bots/api
- Webhooks guide: https://core.telegram.org/bots/webhooks
- grammY framework: https://grammy.dev/
- Telegraf framework: https://telegraf.js.org/
- Telegram Bot features: https://core.telegram.org/bots
---
Building a Telegram bot? PandaStack runs webhook bots with automatic SSL, long-polling bots on an always-on tier, and auto-wires a managed database for stateful bots — free to start at https://dashboard.pandastack.io.