How Much CPU and RAM Does Your Bot Actually Need?

Start small and move up on evidence. An app's CPU and RAM are chosen from presets on its Performance tab, running from 0.1 vCPU / 0.1 GB at the bottom to 2 vCPU / 2 GB at the top, and most bots and small workers are genuinely happy near the bottom of that range. Two things trip people up: options above your account's limit are greyed out rather than hidden, and a change you make doesn't take effect until the app restarts — so it looks like nothing happened. Both are easy once you know, and over-allocating isn't free, because billing is per-minute on what you allocate.

The preset ladder#

The options are grouped, and the group names are a fair guide to intent:

Your current allocation is shown separately, so you can always see what you're on before changing it.

For a Discord or Telegram bot, a small API, or a feed relay, Home is usually right and Hobby is generous. The Profi tier exists for things that genuinely need it — and if you're reaching for it to fix a crash, read the OOM section below first, because more memory doesn't fix a leak, it delays it.

Why some options are greyed out#

An option you can't select isn't broken — it's above your account limit. Those limits cap what you can allocate across all your apps, and by default that's 1 vCPU, 2 GB RAM, and 5 GB disk, raiseable by contacting support.

Two consequences worth understanding:

• Your other apps consume the same pool. Three apps at 0.5 vCPU leaves little headroom, so a preset that was available yesterday can be unavailable today.
• It's an allocation ceiling, not a bill. Billing is aggregated per-minute across apps, so the limit governs what you can reserve, not what you're charged.

If the option you want is greyed out and you've got apps you're not using, stopping one frees its allocation.

The change is pending until you restart#

This is the part that reads as a bug and isn't. Selecting a new preset stores it as pending — the running container keeps its original limits until it's recreated.

So the sequence is: pick a bigger memory option, watch nothing change, conclude it didn't work. The docs have a page for exactly this: restart the app to apply it.

It's the same mechanism as everything else that changes a container's shape — a quota change requires the container to be recreated, which means a short gap. Worth batching with other configuration changes rather than doing separately.

How to tell you've given it too little#

Memory is the one that fails loudly. Exceed the limit and the kernel kills the process — there's no swap to absorb it. The signature is an exited event with code 137, and because the platform restarts the process automatically, it presents as an app that looks like it's running but keeps restarting.

So: unexplained restarts plus exit code 137 means raise the RAM, or find the leak. Check the event history for whether the exits are seconds apart (too little from the start) or hours apart (something growing).

CPU fails quietly. Too little CPU doesn't kill anything — it just makes everything slower. For a bot that shows up as sluggish command responses, and if it gets bad enough, Discord's 3-second interaction deadline starts being missed. If your bot is timing out on commands that used to work, CPU starvation is a candidate.

Stack-specific notes#

The same preset means different things depending on what you're running:

• Go — the smallest footprint of anything here; a static binary has no runtime resident before your code. Set GOMEMLIMIT below your allocation so the GC knows the ceiling.
• Python / Node — the interpreter plus your dependencies is the baseline. Don't run multiple workers on a small preset; each is a full process with its own heap, not shared memory.
• .NET — reads the container limit and grows toward 75% of it by default. That's fine, but it means .NET will happily use what you give it; lower the heap ceiling rather than assuming a leak.
• Anything with a database — Postgres in its own container wants its own allocation on top of your app's.

Cost, honestly#

Per-minute billing on allocation means over-provisioning is a continuous cost rather than a one-off. At published rates, doubling a small app's RAM is a small amount of money — but it's a small amount every month, for capacity you're not using.

The sensible pattern is the same as everywhere else: start at the smallest preset that works, let it run under real load for a few days, and move up one step when you have a reason. Guessing high "to be safe" is how a cheap project quietly becomes an expensive one.

FAQ#

How much RAM does a Discord bot need?#

Most small bots run comfortably at the Home presets (0.1–0.25 GB). Memory grows with gateway library caching and anything you accumulate per event, so measure rather than guess.

Why can't I select a bigger option?#

It exceeds your account's allocation limit, which is shared across all your apps. Stop an unused app to free capacity, or contact support to raise the limit.

I changed the CPU/RAM and nothing happened.#

The change is pending until the app restarts. Restart it to apply the new values.

What does exit code 137 mean?#

The process was killed for exceeding its memory limit. Raise the RAM allocation or find what's growing.

Does a bigger allocation cost more even if I don't use it?#

Yes. Billing is per-minute on what you allocate, so unused headroom is a recurring cost.

Should I fix slow commands with more CPU?#

Only if you've confirmed CPU starvation. Slow responses more often come from blocking calls in an async handler than from a lack of cores.

Wrapping up#

Right-sizing is one of the few places where the lazy option and the correct option agree: start at the bottom. The platform makes it cheap to be wrong in that direction — an under-provisioned app tells you loudly with exit code 137 and an event history you can read — whereas an over-provisioned one says nothing at all and bills you for the silence.