How Much RAM Does a Discord Bot Need? Real Numbers by Bot Type
Measured memory usage for moderation, utility, economy, music and sharded Discord bots — plus how to measure your own bot and pick the right plan.
On this page
“How much RAM do I need?” is the most common question we get from people choosing a plan. The honest answer is “it depends on what your bot does” — but that isn’t very useful, so this article gives real numbers, explains what drives memory use, and shows you how to measure your own bot.
Typical memory use by bot type
These are idle-to-light-load figures for bots running on a single process. Busy bots will sit higher, and memory grows with the number of servers and cached objects.
| Bot type | Library example | Typical usage | Suggested starting plan |
|---|---|---|---|
| Moderation bot, ~10 servers | discord.js | ~95 MB | Free (256 MB) |
| Utility bot with slash commands | discord.py | ~110 MB | Free (256 MB) |
| Economy / levels bot with MySQL | Node.js + MySQL | ~140 MB | Free or Basic (512 MB) |
| Public bot, 50+ servers, database | Any | 300–700 MB | Basic (512 MB) or Pro (1 GB) |
| Music bot with a Lavalink client | Any | 300 MB+ | Extreme (3 GB) |
| Large sharded bot | Any | Several GB | Ultimate (6 GB) and up |
The first four rows come from bots measured on our free tier. The pattern is clear: a single-purpose bot in a handful of servers rarely needs more than 150 MB.
What actually uses the memory
The runtime itself
Node.js starts at roughly 30–50 MB before your code loads anything. Python is similar. Java (JDA) starts higher because the JVM reserves heap up front — expect 150 MB or more even for a small bot, and read hosting a JDA bot for heap flags.
The cache
This is the big one. Discord libraries cache guilds, channels, roles, members and messages so they don’t have to ask the API every time. In a bot with thousands of servers, the member and message caches can dwarf everything else.
You control this. discord.js lets you limit caches with makeCache and sweepers:
const { Client, GatewayIntentBits, Options } = require('discord.js');
const client = new Client({
intents: [GatewayIntentBits.Guilds, GatewayIntentBits.GuildMessages],
makeCache: Options.cacheWithLimits({
...Options.DefaultMakeCacheSettings,
MessageManager: 50, // keep 50 messages per channel
PresenceManager: 0, // don't cache presences
}),
sweepers: {
...Options.DefaultSweeperSettings,
messages: { interval: 3600, lifetime: 1800 },
},
});
discord.py has max_messages on the client and member cache flags. We cover both libraries in detail in reducing memory usage in discord.js bots and in Python bots.
Intents
Every intent you request means more events arriving and, often, more objects cached. The presence intent is the worst offender: in large servers it floods the bot with status updates. If you don’t use presences, don’t request the intent.
Your own data
Arrays of user data, in-memory leaderboards and unbounded Maps grow forever unless you prune them. Move persistent data into a database rather than holding it all in memory.
Audio
Music bots that decode audio in-process use far more memory and CPU than text bots. Offloading playback to a Lavalink node keeps the bot process small.
How to measure your own bot
Guessing is unnecessary — measure. Run the bot under realistic load for a day and look at the numbers.
On Kerit Cloud, the panel shows live memory and CPU graphs for your server. Watch the steady-state figure after the cache has warmed up, not the first minute after start.
In code, log memory periodically. In Node.js:
setInterval(() => {
const { rss, heapUsed } = process.memoryUsage();
console.log(`rss=${(rss / 1e6).toFixed(0)}MB heap=${(heapUsed / 1e6).toFixed(0)}MB`);
}, 5 * 60 * 1000);
In Python, resource.getrusage(resource.RUSAGE_SELF).ru_maxrss reports peak resident memory (in kilobytes on Linux).
Tip: If memory climbs steadily and never levels off, you probably have a leak — an event listener added on every command, or a collection that only ever grows. More RAM just delays the crash.
Leave headroom
Size for your peak, not your average. Memory spikes during startup (when every guild is loaded), during large command bursts, and when a big server joins. A good rule is to keep steady-state usage under about 70% of your plan’s limit. If your bot sits at 200 MB on a 256 MB plan, it will eventually hit the ceiling and be killed.
Matching usage to a plan
Kerit Cloud’s Discord bot plans scale in clear steps, all on AMD EPYC with NVMe storage:
| Plan | RAM | CPU | Storage |
|---|---|---|---|
| Free | 256 MB | 30% | 2 GB |
| Basic | 512 MB | 75% | 5 GB |
| Pro | 1 GB | 100% | 10 GB |
| Extreme | 3 GB | 200% | 20 GB |
| Ultimate | 6 GB | 300% | 30 GB |
| Supreme | 8 GB | 400% | 50 GB |
| Elite | 12 GB | 600% | 80 GB |
CPU percentages are shares of a core — 200% means up to two full cores. Upgrades resize in place, so you can start small and move up without redeploying; files, database and environment variables stay put. For help picking a tier, see choosing the right Discord bot plan.
Don’t forget CPU
RAM is the limit people notice because running out of it kills the process. CPU shortages are quieter: commands get slow, heartbeats arrive late, and in bad cases Discord closes the gateway connection because the bot didn’t respond in time.
Text bots are usually light on CPU. The exceptions are worth knowing:
- Image generation — welcome cards, rank cards and memes rendered with canvas or Pillow can use a full core for a second or more per image.
- Large startups — a bot in thousands of servers processes a burst of guild data when it connects.
- Heavy loops — recalculating a leaderboard over every user on every message is an easy way to pin a core.
- Audio — decoding and encoding in-process, which is why music bots should hand playback to Lavalink.
If your graphs show CPU sitting near your plan’s limit while RAM is fine, a plan with a bigger CPU share (Pro’s 100% or Extreme’s 200%) will help more than extra memory.
Common memory mistakes
A few patterns account for most of the “my bot keeps running out of memory” tickets we see:
- Registering listeners inside commands. Adding
client.on(...)inside a command handler attaches a new listener every time the command runs. Node.js warns about this with aMaxListenersExceededWarning— don’t ignore it. - Caching every message forever. Keeping full message history for logging or snipe commands grows without bound. Cap it, or write to a database.
- Fetching all members on start. Calling a full member fetch for every guild at startup loads everything into memory at once. Fetch on demand instead.
- Loading large files into memory. Read big JSON files once, or better, move the data into SQLite or MySQL.
- Running two copies. A second instance started by accident doubles memory and makes the bot answer every command twice. Check for duplicate processes before blaming your code.
Frequently asked questions
Will 256 MB really run a bot? For a single-purpose bot in a modest number of servers, yes — our measured moderation, utility and Telegram bots all sit well below 150 MB.
Does Python use more memory than Node.js? They’re in the same range for typical bots. Library choice and cache settings matter far more than language.
What happens when my bot hits the limit? The process is stopped by the system and the watchdog restarts it. If it keeps happening, the console log will show repeated restarts — a clear sign to trim memory or upgrade.
Summary
Most small bots need 100–150 MB and fit comfortably on a free plan. Memory grows with server count, cache size, intents and audio. Trim caches, drop intents you don’t use, keep data in a database, and measure real usage before paying for more. When you do upgrade, leave around 30% headroom so spikes don’t take the bot down.