When and How to Shard Your Discord Bot

Sharding is one of those topics that sounds more complicated than it is. For most of a bot’s life you don’t need to think about it. Then your bot grows past a certain size, Discord refuses to let it connect, and suddenly it’s urgent. This article explains what sharding is, when it becomes necessary, and how to do it well.

What a shard is

A shard is one gateway connection that handles a subset of your bot’s servers. An unsharded bot has a single connection receiving events for every server. A sharded bot opens several connections, and Discord routes each server’s events to exactly one of them.

Which shard a server belongs to is deterministic:

shard_id = (guild_id >> 22) % shard_count

So with four shards, every server is permanently assigned to shard 0, 1, 2 or 3 based on its ID. Direct messages always go to shard 0.

When you have to shard

Discord requires sharding once a bot is in 2,500 servers. Beyond that, a single connection is refused, and each shard can handle at most 2,500 servers. In practice you should shard earlier: Discord’s /gateway/bot endpoint returns a recommended shard count, typically around one shard per 1,000 servers, and libraries use it when you let them choose automatically.

Sharding before it’s mandatory has real benefits:

• Faster startup. Several connections load their servers in parallel.
• Smaller blast radius. If one shard disconnects, only its servers are affected.
• Easier growth. You won’t hit the 2,500 wall unexpectedly during a growth spurt.

Internal sharding vs a sharding manager

There are two ways to run shards.

Internal sharding runs every shard inside one process. It’s the simplest option: one process, one memory space, and your code can see every server directly. It works well up to several thousand servers, limited by how much memory and CPU a single process can use.

A sharding manager spawns a separate process (or worker) per shard or group of shards. Each process is smaller and independent, and a crash in one doesn’t take down the others — but processes can’t see each other’s data directly, so cross-shard information needs extra work.

Sharding with discord.js

For internal sharding, tell the client to use Discord’s recommended count:

const client = new Client({
  intents: [GatewayIntentBits.Guilds],
  shards: 'auto',
});

For process-based sharding, use ShardingManager in a separate entry file that launches your bot file once per shard:

// shard.js — make this your start command
const { ShardingManager } = require('discord.js');

const manager = new ShardingManager('./bot.js', {
  token: process.env.DISCORD_TOKEN,
  totalShards: 'auto',
});

manager.on('shardCreate', (shard) => console.log(`Launched shard ${shard.id}`));
manager.spawn();

Cross-shard data then goes through the manager. For example, total server count:

const counts = await client.shard.fetchClientValues('guilds.cache.size');
const total = counts.reduce((a, b) => a + b, 0);

client.shard.broadcastEval() runs a function on every shard and collects the results — useful for “find this guild wherever it lives” lookups.

Sharding with discord.py

discord.py’s AutoShardedBot (or AutoShardedClient) is internal sharding with the recommended count, and it’s a drop-in replacement:

from discord.ext import commands

bot = commands.AutoShardedBot(
    command_prefix=commands.when_mentioned,
    intents=discord.Intents.default(),
)

Everything else stays the same. bot.latencies returns a list of (shard_id, latency) pairs, and bot.get_shard(id) gives per-shard status. For very large bots, run several processes, each with its own shard_ids range and the same shard_count.

Planning memory and CPU

Sharding doesn’t reduce the total work — the same number of servers still send the same events. It divides the work across connections and, with a manager, across processes. Plan resources for the whole bot:

• Memory scales with the number of servers and what you cache. A large bot’s member and message caches dominate. Trim them before throwing hardware at the problem — see how much RAM a Discord bot needs.
• Startup is CPU-heavy, because every shard processes a burst of guild data when it connects.
• Each process in a manager setup carries its own runtime overhead, so ten processes use more total memory than one process handling the same servers.

For a bot at the sharding stage, Kerit Cloud’s Extreme (3 GB, 200% CPU) or Ultimate (6 GB, 300% CPU) Discord bot plans are a sensible start, with Supreme and Elite adding a dedicated IP and up to 600% CPU for large sharded bots. Upgrades happen in place, so you can grow without migrating.

Identify limits

Every time a shard connects, it sends an identify. Discord limits how many identifies a bot can send per day (the session_start_limit returned by /gateway/bot) and how many can happen concurrently (max_concurrency). Libraries respect these automatically, but a crash loop that reconnects all shards over and over can burn through the daily allowance. That’s another reason to fix crash loops quickly — see auto-restart and crash recovery.

Shared state belongs in a database

With a sharding manager, each process has its own memory. Anything that must be consistent across shards — economy balances, global settings, cooldowns — should live in a shared database or cache rather than in-process variables. A MySQL or PostgreSQL database handles durable data, and Redis works well for fast shared counters and cooldowns. See Redis vs SQL for caching.

Summary

A shard is a gateway connection handling part of your bot’s servers. Discord requires sharding at 2,500 servers, but sharding earlier with the recommended count gives faster startups and fewer surprises. Start with internal sharding (shards: 'auto' or AutoShardedBot), move to a sharding manager when one process gets too big, plan memory for the whole bot, and keep shared state in a database.