Server RAM Calculator

Not sure how much RAM to provision for a web or API server? This server RAM calculator takes the number of worker processes, memory per worker, OS/base overhead, an extra reserve for cache/DB, and a safety headroom (%), then computes the recommended memory and rounds it up to the nearest common RAM tier among 1, 2, 4, 8, 16, 32 and 64 GB.

It is handy for picking a VPS or cloud instance size, or for setting a container memory limit. To also weigh the cost as traffic grows, pair it with the bandwidth cost calculator, and to translate an availability target into allowed downtime use the SLA calculator.

How it is calculated

The tool derives the recommended memory in this order.

• Workers total = workers × memory per worker (MB)
• Subtotal = OS overhead + workers total + cache/DB reserve
• With headroom = subtotal × (1 + safety headroom% ÷ 100)
• Recommended tier = round the with-headroom value up to the next tier among 1, 2, 4, 8, 16, 32, 64 GB

Where memory per worker comes from

Memory per worker should come from real application profiling, not a guess. Observe the resident set size (RSS) of your processes under load and add margin on top of the peak. Multi-process models such as PHP-FPM, Gunicorn, or a Node cluster simply add up as workers × memory per worker.

Cache and DB often dominate

When a database or in-memory cache (Redis, Memcached) runs on the same box, it frequently consumes far more memory than the worker total. If you allocate 4 GB to a Redis cache, enter 4096 MB as the cache/DB reserve. If you move the database to a separate server, set this reserve to 0.

Ballpark memory per worker by stack

Profiling is the only real answer, but these are reasonable starting points for resident set size (RSS) per worker. Actual numbers swing widely with your dependencies and app code, so always correct them against production observation.

A worked example

Say you enter 80 MB per worker on PHP-FPM, 8 workers, 512 MB OS overhead, 1024 MB for a Redis instance on the same box, and 25% safety headroom. The workers total is 8 × 80 = 640MB, the subtotal is 512 + 640 + 1024 = 2176MB, and with headroom it is 2176 × 1.25 = 2720MB (about 2.66 GB). That rounds up to the next tier, 4GB, so a 4 GB instance is recommended. Bumping workers from 8 to 16 pushes the with-headroom value to roughly 3.5 GB but still lands on the 4 GB tier, whereas going to 24 workers jumps you to the 8 GB tier — tiers move in steps, not smoothly.

Common pitfall

• Setting worker count to vCPU count 1:1. PHP-FPM pm.max_children and Gunicorn workers are often configured well above the core count, so enter the worker count from your actual config file.
• Double-counting the JVM/Node heap. Memory set via -Xmx or --max-old-space-size already lives inside that process's RSS, so do not add it again as a separate line item.