Start with how the bot receives events
The most important question is not price. It is whether your bot needs a long-lived connection.
- Webhook bots (Telegram webhooks, Slack Events API over HTTP, WhatsApp Cloud API, Discord interactions over HTTP) only run when a request arrives. They fit request-driven platforms, including serverless.
- Gateway or socket bots (a Discord bot that reads messages through the Gateway, Slack Socket Mode, Telegram long polling) keep a connection open all the time. They need a process that stays up.
If you are unsure which one you are building, read Webhooks vs polling first.
The five families of hosting
| Option | Good fit | Watch out for |
|---|---|---|
| Edge workers (for example Cloudflare Workers) | Webhook bots, low latency, global traffic | CPU time limits per request, no persistent sockets in a normal request |
| Serverless functions (AWS Lambda, Google Cloud Run functions, Azure Functions) | Webhook bots with bursty traffic | Cold starts, execution time limits, platform-specific packaging |
| Container platforms (Cloud Run, Fly.io, Render, Railway) | Most bots, including small gateway bots | Some free plans sleep idle services, which breaks gateway bots |
| A small VPS | Gateway bots, full control, predictable cost | You patch the OS, manage TLS and restarts yourself |
| Self-hosting (home server, Raspberry Pi) | Learning, private bots | Power and network outages, dynamic IPs, exposing ports safely |
Edge workers and serverless
Request-driven platforms are a natural match for webhook bots: you pay (or use free quota) per request, they scale with spikes, and there is no server to patch. The trade-offs are limits. Cloudflare documents per-request CPU time limits and daily request quotas on its free plan, and long work must be pushed to a queue or a background mechanism such as ctx.waitUntil or Cloudflare Queues. AWS Lambda has a maximum execution time of 15 minutes per invocation, which is plenty for a reply but not for a permanent socket.
Rules that keep serverless bots healthy:
- Acknowledge the platform quickly and do slow work afterwards. Slack expects an HTTP response within 3 seconds; Discord expects an initial interaction response within 3 seconds.
- Keep state outside the function: a database, a key-value store or a Durable Object.
- Verify every webhook signature, because the URL is public.
Container platforms
Containers are the most flexible middle ground. You ship a Dockerfile, the platform runs it, and you can choose between "scale to zero" (good for webhook bots) and "always on" (needed for gateway bots). Read the plan details carefully: several platforms put free or hobby services to sleep after a period without HTTP traffic. Render, for example, documents that free web services spin down after 15 minutes without inbound traffic. A sleeping service is fine for a webhook bot that tolerates a slow first reply, and fatal for a Discord gateway bot.
Our hosting config generator produces a hardened Dockerfile, compose file, systemd unit and pm2 config to start from.
A small VPS
For gateway bots a small virtual server is often the simplest reliable answer: one process, supervised by systemd or a container runtime, restarted automatically. A bot that only relays messages usually needs very little memory, so the smallest plans of most providers are enough to start. The cost is your time: OS updates, firewall, TLS certificates if you receive webhooks, backups and monitoring are yours. Common choices include Hetzner Cloud, DigitalOcean and Vultr; compare current prices on their official pages. If you receive webhooks you also need a domain, from any registrar such as Namecheap or Cloudflare.
Self-hosting
Running a bot at home is a good way to learn and perfectly reasonable for a private bot. For anything users depend on, expect outages from power cuts, router restarts and ISP changes. If you receive webhooks at home, use an outbound tunnel (for example Cloudflare Tunnel) instead of opening ports on your router.
How to choose
- Webhook bot with modest traffic: an edge worker or serverless function. Cheapest to run, least to maintain.
- Gateway bot or Socket Mode app: an always-on container or a small VPS.
- Heavy jobs (AI calls, media processing, scraping you are allowed to do): a webhook front end that enqueues work, plus workers on containers or a VPS.
- Strict data residency: pick a region-pinned container or VPS and document it in your privacy notice.
Whatever you pick, add a health check, structured logs and an alert on "no successful updates in N minutes". The deployment guide covers the checklist in depth.
Sources
- Cloudflare Workers limits: developers.cloudflare.com/workers/platform/limits
- AWS Lambda quotas: docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
- Render free instances: render.com/docs/free
- Slack, responding to events: api.slack.com/apis/events-api
- Discord, receiving and responding to interactions: discord.com/developers/docs/interactions/receiving-and-responding
Limits and plans change often. Check the provider's current documentation before you commit.