How Many Discord Bots Can I Run on One Account?

As many as your account quotas and total CPU, RAM, and disk allow — because the number of apps isn't what you're billed for. JustRunMy.App aggregates resources across all your applications and bills per minute. Five bots with the same total CPU, RAM, and disk allocation as one bot have the same resource cost.

Apps aren't the billing unit#

This is the part that differs from platforms where each service is a line item. Here the bill is computed from aggregate usage — total vCPU, total GB of RAM, total GB of disk across everything you run — at $1.90 per vCPU-month, $1.95 per GB RAM-month, and $0.25 per GB disk-month, prorated per minute (pricing).

The practical consequence: splitting one bot into two apps doesn't cost more, as long as the total resources are the same. You're free to organise by what makes operational sense rather than by what's cheapest to bill.

There is a small real cost to splitting, but it's memory, not money — each app is its own container with its own runtime. Two Python processes each load their own interpreter and libraries. That overhead is what actually limits how many you can run.

What genuinely limits you#

Two separate ceilings are easy to confuse:

Your account has resource limits. By default an account can allocate up to 1 vCPU, 2 GB RAM, and 5 GB disk across all applications; higher limits are available by contacting support. These cap what you can allocate — billing is still per-minute on what you actually use.

Your account has an app-count quota. Check the current numbers on the Limits page, which shows CPU, RAM, disk, app count, exposed ports, and Runny AI builds side by side.

Quotas vary per account, so treat that page as the source of truth rather than any number in a blog post — including this one.

So how many bots fit?#

Memory is the binding constraint in practice. A small Discord or Telegram bot — command handling, a few API calls, a SQLite file — is a modest process, but it isn't free: you're paying for a language runtime plus your libraries in every container.

Rather than guess, measure. Deploy one bot, let it run under real load for a day, and read its actual usage on the Limits page. Then divide. That number is far more useful than any generic figure, because a bot with a cache of every message in a busy server behaves nothing like one that answers /ping.

Two things that shift the answer a lot:

• Discord library caching. Gateway libraries cache guilds, channels, and members by default. On a bot in large servers that dominates memory. Turn off intents and cache you don't use.
• Anything that accumulates. A dict that grows per event, an unbounded queue, a log kept in memory — these look fine on day one and OOM on day four.

One app per bot, or one app running several?#

You can also run several bots inside a single process. It's a real trade, not an obvious win:

Separate apps is the better default. Isolation is worth more than the runtime overhead when a bot is something people rely on, and it means you can redeploy one bot without disconnecting the others.

Combining makes sense when the bots share most of their code and data — several small bots for one community, sharing a database and a set of helpers. Then one process with several gateway clients is genuinely simpler.

If you do combine, remember the whole thing dies together: an unhandled exception in one bot's handler exits the process, and the platform restarts all of them. Wrap each bot's entry points so one misbehaving handler doesn't take out the others.

Watch total disk — it stops everything#

This one is worth knowing before it happens. If your total disk usage exceeds the account limit, all applications in the account are stopped and cannot be started again until total volume size drops back below it.

That's an account-wide stop, not a per-app one. So an app with a runaway log file or an unrotated database can take your other bots offline with it — which is a strong argument for keeping an eye on anything that writes without bound.

Two habits that avoid it entirely:

• Rotate or cap anything you write. Logs to disk, cached media, message archives.
• Check disk on the Limits page occasionally, especially after adding a feature that stores things.

Container logs themselves are capped by the platform and rotate on their own — it's what your app writes into volumes that grows unbounded.

FAQ#

Does running more apps cost more?#

No. Billing aggregates CPU, RAM, and disk across all your applications; the app count doesn't affect the price. Five small bots cost the same as one bot using the same total resources.

How are two bots billed?#

Their CPU, RAM, and disk allocations are added together and billed at the published unit rates. There is no separate charge per bot.

What's the real limit on the number of bots?#

Your account's RAM and CPU limits, plus its app-count quota. Defaults are 1 vCPU and 2 GB RAM; support can raise them.

Should I run each bot as its own app?#

Usually yes. Separate apps mean a crash or a redeploy affects only one bot. Combine them only when they share most of their code and data.

What happens if I run out of disk?#

All applications in the account are stopped and can't be restarted until total volume usage drops below the limit. Rotate anything your app writes without bound.

How do I know how much memory my bot actually uses?#

Deploy it, let it run under real load, and read the Limits page. Gateway library caching is usually the biggest variable.

Wrapping up#

"How many can I run?" turns out to be the wrong question, because nothing counts your bots — it counts megabytes. Deploy one, see what it actually consumes, and size from there. Keep them as separate apps so a bad deploy stays contained, and keep an eye on total disk, since that's the one limit that takes everything down at once rather than just the app that crossed it.