How much RAM and CPU does my app need?

There is no universal amount of RAM for an application. A bot that only answers commands, an API with an in-memory cache and a server-rendered website use very different amounts, and the same app changes as it gains users. That is why sizing starts with measuring, not with a guess or a table from the internet.

Buying too little takes your app down. Buying far too much means paying every month for idle memory.

What is the difference between RAM and CPU when sizing?#

RAM is a hard limit. When an app tries to use more memory than its container allows, the system kills the process. There is no gradual slowdown: it works, then the process suddenly dies.

CPU is a soft limit. With too little CPU the app gets slower, responses take longer and queues grow, but it stays up. That is why RAM is usually the first resource to size, and CPU is the second step, to check whether something is saturated.

How do I measure the RAM my app really uses?#

Record the peak while the app runs under conditions close to production: the same number of servers for a bot, the same data, the same traffic. Usage right after startup is misleading, because caches and connections have not filled yet.

In Node.js, process.memoryUsage() returns values in bytes. The rss field is the whole process memory, which is what counts against a container limit:

// measure.js: prints memory usage every 10 seconds
const mb = (n) => (n / 1024 / 1024).toFixed(0);

setInterval(() => {
  const m = process.memoryUsage();
  console.log(`rss=${mb(m.rss)} MB heapUsed=${mb(m.heapUsed)} MB`);
}, 10_000);

In Python, the resource module reports the process's peak memory. On Linux, ru_maxrss is in KiB:

import resource

def peak_mb() -> float:
    # Linux: ru_maxrss is in KiB (on macOS it is in bytes)
    return resource.getrusage(resource.RUSAGE_SELF).ru_maxrss / 1024

print(f"peak memory: {peak_mb():.0f} MB")

In Java, the JVM uses memory beyond the heap (metaspace, threads, buffers), so the container limit has to cover the whole process, not only -Xmx. On Linux, the JVM detects the container limit by default.

Leave the measurement running for hours or days and note the highest rss. That is your peak.

How much headroom should I add to the peak?#

A simple rule of thumb: measured peak times 1.3, rounded up to the next available size.

Headroom covers rare spikes such as a large data batch, a mass reconnect or a delayed garbage collection. If usage swings a lot between measurements, raise the headroom to 50%.

How do I tell if I am running out of RAM?#

The most common signs:

• The app stops or restarts by itself, with no stack trace from a code error.
• The log stops abruptly, with no shutdown message.
• The memory graph climbs like a staircase and never comes down.
• In Node.js, you see FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory.

The last two usually point to a leak: an unbounded cache, a global array that only grows, listeners that are never removed. Adding RAM only delays the crash. Fix first, size afterwards. See how to read your app logs to find the exact moment of the crash.

In Node.js, you set the V8 heap limit with --max-old-space-size=SIZE, in MiB (documented in the Node.js CLI docs). If you bought more memory and the heap still overflows, that flag is the suspect.

How do I tell if I am running out of CPU?#

Saturated CPU shows up as slowness, not as crashes: bot commands that take seconds, requests that hit timeouts, latency that rises with traffic. Compare CPU usage with response time. If both climb together and CPU sits near its ceiling, you need more CPU.

Before paying for more, understand the kind of load:

• Node.js runs your JavaScript on one thread. More cores only help with workers or several processes.
• Python with regular threads does not run pure CPU code in parallel because of the GIL (in the standard CPython build; the optional free-threaded build of 3.13+ removes it). Use processes or native libraries.
• Heavy tasks (images, video, AI, cryptography) really consume CPU and justify more resources.

For a bot that answers commands or an API that reads and writes a database, the bottleneck is almost always the network or the database, not CPU. To turn these numbers into a budget, see how much website hosting costs.

What changes as the app grows?#

Usage grows with the number of users, servers or cached items. Revisit your sizing when:

1. The number of users or servers doubles.
2. You add a large library or an in-memory cache.
3. Restarts show up that were not there before.

If one process is not enough, horizontal scaling spreads the load across several instances behind the same domain. Each instance still needs its own RAM, so the total cost is their sum. For Discord bots there is a dedicated reference in how much RAM a Discord bot needs.

How to do this on Square Cloud#

On Square Cloud, the number you measured becomes the application's RAM, chosen at deploy time and changed later in the settings or through the API. The dashboard shows CPU, RAM and network metrics with 24 hours of history, so you can measure the peak in production and check whether your 30% headroom holds. If memory is left over, scale down; if it runs short, scale up. There is no autoscaling: the adjustment is your call, based on those metrics.

The plan's RAM is a pool shared across your applications, with a minimum of 256 MB per background application, such as a bot, and 512 MB per web application. On the 1 GB Hobby plan, for example, a 256 MB bot and a 512 MB API fit side by side. The plan's vCPU is a ceiling for each environment, calculated from the allocated RAM, and does not add up across applications. Hobby plans start at R$12.49 per month.

If the application runs out of memory, it stops and stays stopped: raise its RAM and start it again. Automatic restart, on by default for dashboard deploys, only brings back a process that exits with an error.

Compare plans on pricing and see what each application lets you adjust in features.