Discord Bot Hosting: Free Tier, $4 VPS or a Bot Host?
Discord bot hosting has two documented limits that decide almost everything, and one of them isn’t about size at all.
The two limits from Discord’s own docs
Sharding, at 2,500 guilds:
“Each shard can only support a maximum of 2500 guilds, and apps that are in 2500+ guilds must enable sharding.”
That’s not a performance suggestion. Above 2,500 guilds your bot will not work as a single connection, and your process architecture has to change.
Session starts, at 1,000 per day:
A standard bot gets 1,000 session starts per day with a max_concurrency of 1 — meaning one identify per five seconds. Large bots above 150,000 guilds get max(2000, (guild_count / 1000) * 5) per day.
That second limit is the one that catches people, and it’s a hosting problem. Every time your bot reconnects to the gateway it consumes a session start. A bot in a crash loop — restarting, identifying, crashing, restarting — burns through a thousand identifies faster than you’d think, and then it cannot connect at all until the budget resets.
So an aggressive restart policy, which sounds like good practice, can take your bot offline more completely than no restart policy at all.
The fix is a backoff, not a faster restart. In systemd terms: Restart=on-failure with a RestartSec delay of at least 15–30 seconds, and StartLimitBurst/StartLimitIntervalSec set so a genuinely broken bot stops rather than hammering the gateway. In Docker, restart: on-failure with a bounded retry count rather than always.
The three scale bands
Under ~100 guilds. Anything works. A free tier, the cheapest VPS, a Raspberry Pi in a cupboard. The bot’s memory is dominated by your runtime, not by cached state.
100 to 2,500 guilds. Still one shard, but cached guild and member state starts to matter and the process needs to stay up. This is where free tiers stop being viable — for reasons below that have nothing to do with resources.
Above 2,500 guilds. Sharding is mandatory. Each shard is a separate gateway connection with its own state, so memory scales with shard count, and you’re now running multiple processes that need supervising, coordinating and deploying together. That’s a genuine infrastructure step, not a bigger plan.
The shards value from Discord’s Get Gateway Bot endpoint is the recommended count — and the docs are explicit that it “is not guaranteed to remain static and should not be cached long-term.” Read it at startup rather than hardcoding it.
Why free tiers fail, and it isn’t resources
The number one complaint about free bot hosting is that the bot goes offline silently, and the cause is almost always idle or sleep policy rather than CPU or memory.
Free tiers are designed for request-driven workloads: something arrives, the container wakes, it responds, it sleeps. A Discord bot is the opposite shape. It holds an outbound WebSocket to the gateway and must stay resident to receive events. There is no inbound request to wake it.
So the failure mode is: the platform sees no HTTP traffic, decides the service is idle, and stops it. Your bot disappears from Discord with no error, and you find out when someone in your server asks.
Two consequences worth internalising:
- A bot is a daemon, not a web service. Any platform whose free tier sleeps on inactivity is structurally wrong for it, regardless of the resource limits.
- Keep-alive hacks are a bad fix. Pinging your own service to look busy works until the platform notices, and it wastes the free allowance you were trying to conserve.
If you want free, the honest options are a machine you already own or a platform that explicitly supports always-on workloads — not a sleeping container with a heartbeat bolted on.
What to actually buy
The resource requirement is modest, which is why this is a cheap category. The specs that matter are staying resident and not being restarted stupidly.
| Scale | RAM | Shape |
|---|---|---|
| Under 100 guilds | 512MB–1GB | one process |
| 100–2,500 guilds | 1–2GB | one process, cached state grows |
| 2,500+ guilds | 2–4GB+ | multiple shard processes |
Hostinger is the cheapest capable option — 4GB at $6.49 promotional and $11.99 at renewal, with one-click Docker templates. More than a small bot needs; the right size once you’re sharding.
Cloudzy is the best fit for a first bot: $4.17/month for 1GB, billed monthly with no term. A hobby bot is exactly the project you might stop running, and nothing is stranded when you do.
DigitalOcean is the choice if you want documentation and a clean API — $6 for 1GB, which is correctly sized for a single-shard bot. Its tracked link isn’t working on our end, so we’ve named it without linking.
Hetzner has the best hardware per euro when its cost-optimized tier is in stock — check, because it has been showing as unavailable and the CPX line is €11.99 for 2GB after its June 2026 repricing.
Railway deploys a bot from a repo with no server to manage, which is genuinely convenient. The caveat is specific to this workload: it bills for residency, and a bot holding a gateway connection is resident by definition. Memory works out at roughly $10/GB/month held around the clock — so a 1GB bot is about $10 of usage against $4.17 for a whole VPS. Convenience has a price here, and it’s a real one.
Whatever you pick, do these three things:
- Set a backoff on restarts, not an aggressive retry — see the session limit above
- Read the recommended shard count at startup rather than hardcoding it
- Alert on your bot going quiet, not just on errors. A heartbeat that pages you when the bot stops reporting catches the silent death that error logs miss
How we checked this
The Discord limits are quoted from Discord’s own developer documentation, read in August 2026: that “each shard can only support a maximum of 2500 guilds, and apps that are in 2500+ guilds must enable sharding”; that standard bots get 1,000 session starts per day with a max_concurrency of 1; that bots above 150,000 guilds get max(2000, (guild_count / 1000) * 5) per day; and that the recommended shards value “is not guaranteed to remain static and should not be cached long-term.”
The connection between crash-looping and the session limit is our inference from those two documented facts — that reconnecting consumes a session start, and that the daily budget is finite — rather than something we reproduced. It follows directly, and it’s why the restart-backoff advice leads the article, but we have not deliberately exhausted a session budget to confirm the failure mode.
What this article’s brief asked for and doesn’t contain: measured RAM and CPU profiles for discord.js versus discord.py bots at each scale tier, and 30-day uptime figures for free tiers, dedicated bot hosts and a VPS. We measured none of it. We don’t operate bots at 2,500+ guilds and we haven’t run comparative uptime tests. The RAM brackets above are conventional guidance scaled by what sharding does to state, not observations — and the library comparison, which would genuinely be useful, isn’t something we can honestly supply.
On free tier sleep policies: we’ve described the structural mismatch — a bot is a resident daemon with no inbound requests to wake it — rather than naming and testing specific platforms’ idle timers, which change frequently and vary by plan.
VPS pricing is each provider’s published figures read in August 2026 across this series. Railway’s roughly $10/GB/month for always-on memory is our conversion of its published per-second rate, covered in our Heroku migration guide.
The host links above are affiliate links. The three closing recommendations — restart backoff, dynamic shard count, alert on silence — cost nothing and earn us nothing.
FAQ
How much RAM does a Discord bot need?
512MB to 1GB under 100 guilds, 1–2GB up to the sharding threshold, and 2–4GB or more once you’re running multiple shard processes, because each shard holds its own cached state.
At how many servers does a Discord bot need sharding?
2,500. Discord’s documentation states each shard supports a maximum of 2,500 guilds and that apps in 2,500+ guilds must enable sharding — it’s a requirement, not an optimisation.
Why does my Discord bot keep going offline on free hosting?
Almost always an idle or sleep policy. Free tiers stop services with no inbound traffic, and a bot holds an outbound WebSocket with nothing to wake it — so it disappears silently.
Can a crash loop get my bot rate limited?
Yes. Standard bots get 1,000 session starts a day, and every gateway reconnect consumes one. A bot restarting in a tight loop can exhaust that and then be unable to connect at all.
What restart policy should I use for a Discord bot?
A backoff rather than an aggressive retry — Restart=on-failure with a 15–30 second delay and a start limit, so a genuinely broken bot stops instead of burning your daily session budget.
Is Railway good for hosting a Discord bot?
It’s convenient and it bills for residency, which a bot always has. At roughly $10/GB/month for always-on memory, a 1GB bot costs about $10 against $4.17 for a whole VPS.
What’s the cheapest way to host a Discord bot properly?
Around $4.17/month for 1GB billed monthly with no term. The specs are modest; what matters is that the process stays resident and isn’t restarted aggressively.
