Hosting a Telegram Bot on a ₹400 VPS: The Complete Setup

You don't need an expensive server to run a Telegram bot properly. Most of the bots I build for clients through Telezoid run comfortably on a budget Linux VPS in the ₹400-600/month range, and the "cheap hosting" part is almost never where things go wrong — the setup around it is.

The ₹400 number, and what it actually buys

At that price point from most budget providers, you're typically looking at 1 vCPU, around 1GB of RAM, and a modest amount of bandwidth and disk. That sounds small until you check what a Telegram bot actually uses: a basic bot built on grammY (Node.js) or python-telegram-bot idles somewhere around 40-80MB of resident memory. Even with a small SQLite or Postgres database running alongside it, you have real headroom on a 1GB box.

Where the ₹400 tier stops being enough: an AI bot making LLM API calls under real concurrent load, several separate bots crammed onto one box, or anything doing heavy media processing (voice generation, image work) on-server rather than offloading it. At that point you're not paying for more RAM to hold the bot — you're paying for CPU and I/O headroom, and it's worth stepping up a tier rather than fighting the box.

Setting it up

The shape I actually use, stripped to the essentials.

1. A non-root user and basic hardening first. Don't run the bot as root. Create a deploy user, disable password SSH login in favor of keys, and set up ufw to only allow SSH and whatever port your webhook needs (443, usually behind nginx).

2. Webhooks, not polling. Polling means your bot keeps asking Telegram "anything new?" on a loop, which burns CPU and bandwidth for nothing on a box this size. Webhooks mean Telegram pushes updates to your server the moment something happens. You need a valid SSL certificate — Telegram won't deliver to a self-signed one — so I put nginx in front as a reverse proxy and use certbot for the cert, same as any other web service.

3. Run it under systemd, not a screen session. This is the single most common mistake I see in bots people set up themselves: starting the bot with python bot.py & or inside a screen session, then the SSH connection drops or the server reboots and the bot is just gone until someone notices. A minimal systemd unit fixes this:

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

[Service]
Type=simple
User=deploy
WorkingDirectory=/home/deploy/bot
ExecStart=/usr/bin/node /home/deploy/bot/index.js
Restart=always
RestartSec=5
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

systemctl enable --now telegram-bot and it survives reboots, restarts on crash, and you get journalctl -u telegram-bot -f for logs without any extra tooling. For Node bots I sometimes use pm2 instead of raw systemd because it gives cleaner log rotation out of the box, but the principle is identical: the process manager, not you, is responsible for keeping the bot alive.

4. A swap file, if you're on the smallest tier. Some ultra-budget VPS plans give you 512MB-1GB RAM with no swap configured by default. A 1-2GB swap file is a five-minute insurance policy against an unexpected memory spike killing your bot via the OOM killer instead of just slowing down.

What actually eats your resources

Contrary to what people expect, the bot logic itself is rarely the resource hog. The things that actually push a ₹400 VPS to its limits:

The database, if it's unindexed and growing. A subscription bot tracking thousands of members with no index on the lookup column will get progressively slower long before it runs out of RAM — this shows up as timeouts, not crashes, which makes it harder to diagnose if you're just watching a resource graph.

Media handling done synchronously. Downloading a voice note, converting it, and sending a reply all inside the same request-handling code blocks that worker while it happens. For a low-traffic bot this barely matters; for anything with real concurrent users, it's worth moving to a queue even on a small box.

Log files nobody rotates. I've seen a bot's disk fill up silently over months because debug logging was left on and nothing was rotating or truncating the log file. logrotate is one config file and prevents an entirely avoidable outage.

The mistakes that cost people their first month

The failure pattern I see most with self-hosted bots on cheap VPS plans isn't the hosting — it's skipping the operational basics because "it's just a small bot." No systemd or pm2, so a crash means silent downtime until someone complains. No monitoring, so nobody actually knows the bot is down until a paying subscriber does. No database backups, so a bad migration or a disk failure means starting over. None of these cost money to fix — they cost twenty minutes of setup that gets skipped in the rush to ship.

The other one: leaving both polling and a webhook configured at the same time. Telegram allows only one active method per bot, and if you've got an old polling process still running somewhere when you set up a webhook, you'll get a 409 Conflict error — "terminated by other getUpdates request" — until you clean up the leftover process. It's a five-minute fix once you know what it is, and a confusing hour if you don't.

Is ₹400 enough forever?

For a single-purpose bot — a subscription paywall, a command-based support bot, a channel automation tool — yes, largely forever. Traffic growth on a well-built bot doesn't scale resource usage the way people assume; the bottleneck is almost always the database or an unoptimized media pipeline, not raw subscriber count. Where I move clients up a tier is AI-powered bots with real usage, or when a client wants several bots consolidated onto shared infrastructure with headroom to spare.

If you're setting this up yourself and want a second opinion on the architecture, or you'd rather have it built and handed over properly the first time, that's exactly the kind of work I do through Telegram bot development — see also what Telegram bot development actually costs in India for how hosting fits into the bigger pricing picture.