Running Multiple Telegram Bots on One Server

Once you’ve built one Telegram bot, a second and third tend to follow: a support bot, a notification bot, a test copy of your main bot. Running each on its own server is simple, but not always necessary. This article covers the three ways to run several bots together and when each makes sense.

Option 1: One process, several bots

Some frameworks can serve multiple bot tokens from a single process. aiogram 3 is a good example: one dispatcher can poll several bots at once.

import asyncio
import os
from aiogram import Bot, Dispatcher
from aiogram.filters import CommandStart
from aiogram.types import Message

dp = Dispatcher()


@dp.message(CommandStart())
async def start(message: Message, bot: Bot):
    me = await bot.me()
    await message.answer(f"Hi from @{me.username}")


async def main():
    tokens = os.environ["BOT_TOKENS"].split(",")
    bots = [Bot(t.strip()) for t in tokens if t.strip()]
    await dp.start_polling(*bots)


asyncio.run(main())

Handlers receive the bot that got the update, so replies go out through the right bot. This pattern is ideal when the bots share the same logic — for example, white-label copies of one bot for different communities, each with its own token.

Pros: lowest memory use, one deploy, one log stream. Cons: a crash takes down every bot; a slow handler in one bot can delay the others; bots with different code don’t fit naturally.

Option 2: Several processes under a process manager

When bots have different code, run each as its own process and let a process manager supervise them. PM2 works for any language:

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: 'support-bot',
      script: 'bot.py',
      interpreter: 'python3',
      cwd: './support-bot',
      env: { BOT_TOKEN: process.env.SUPPORT_BOT_TOKEN },
      max_memory_restart: '300M',
    },
    {
      name: 'alerts-bot',
      script: 'index.js',
      cwd: './alerts-bot',
      env: { BOT_TOKEN: process.env.ALERTS_BOT_TOKEN },
      max_memory_restart: '200M',
    },
  ],
};

pm2 start ecosystem.config.js
pm2 logs            # combined logs
pm2 status          # health of each bot

Each bot restarts independently if it crashes, and max_memory_restart recycles a bot that leaks memory before it starves the others. On a VPS, systemd services achieve the same thing without extra tools — see writing a systemd service for any app and keeping Node.js apps alive with PM2.

Pros: isolation between bots, independent restarts, different languages side by side. Cons: each process carries its own runtime overhead; you manage the process manager.

Option 3: One bot per server

The simplest option is to give each bot its own server. Every bot gets dedicated resources, its own console, its own environment variables and its own restart button. Nothing one bot does can affect another.

This is what we recommend on smaller plans. A single bot on Kerit Cloud’s free plan or Starter plan gets the whole allocation to itself, and a misbehaving bot can’t take a neighbour down with it.

Which option to choose

Resources: budget for the whole set

Several bots on one server share its CPU, memory and disk. Before combining them:

• Measure each bot alone. A typical long-polling Telegram bot idles around 70–100 MB, but media processing, large caches and concurrency push that up.
• Add them up, then add headroom. Keep the combined steady-state memory under about 70% of the plan so one bot’s spike doesn’t get the whole set killed.
• Watch CPU during bursts. A broadcast in one bot competes with every other bot for CPU.

Kerit Cloud’s Ultra Telegram plan is designed for this: 4 GB of RAM, 400% EPYC CPU, 20 GB NVMe, MySQL, PostgreSQL and Redis, explicit support for multiple bots per server, region choice and 24/7 priority support. On smaller plans, one bot per server gives each bot dedicated resources. Compare tiers in choosing a Telegram bot plan.

Keep bots separate where it matters

Even when bots share a server, keep their data and secrets apart:

• One token per bot, in its own environment variable. Never reuse a token across processes — two processes polling one token produce 409 Conflict errors.
• Separate databases or schemas. A bug in one bot shouldn’t be able to overwrite another’s data. With one MySQL or PostgreSQL server, create a database (or schema) and a user per bot.
• Separate working directories. Session files and SQLite databases named bot.session or data.db will collide if bots share a folder.
• Labelled logs. Prefix every log line with the bot’s name, or use your process manager’s per-app logs, so you can tell which bot said what.

Deployment tips

• Keep each bot in its own folder (or repository) with its own dependency file. Mixing requirements for different bots in one file leads to version conflicts.
• Restart bots individually after changes — pm2 restart support-bot rather than restarting everything.
• Stagger heavy scheduled jobs so two bots don’t run their broadcasts at the same minute.
• Document which bot runs where. Six months from now, you’ll be glad you did.

Summary

You can run several Telegram bots on one server by serving multiple tokens from one process (best for identical bots), supervising separate processes with PM2 or systemd (best for different bots), or simply giving each bot its own server (best for isolation). Whatever you choose, budget resources for the whole set, give every bot its own token, data and working directory, and label logs clearly. For several bots under one roof, the Ultra plan provides the room and explicitly supports it.