עב
עב

Server size calculator

Not running an app from our catalog? Describe the workload, its peak load and its data, and get a vCPU, RAM and disk range with a breakdown. Every number you did not enter is shown, with where it comes from, and you can change it.

Pick the closest one. A server that runs several of these: size each one and add them up.
People using it at the same moment, not visitors a day.
Database, uploads or site files today, in decimal GB.

Running n8n, WordPress, PostgreSQL or another app from our catalog? The Stack Sizer sizes it from the app's own requirements and sources. Size catalog apps with the Stack Sizer

Result

vCPU
1 vCPU to 2 vCPU
RAM
3 GiB to 4 GiB
Disk
30 GB to 50 GB
Peak load
40 req/s
Breakdown
LineValueAssumptions used
Peak load40 req/s
  • Requests per concurrent user (Assumption)
Busy CPU at the target use0.67 vCPU to 2 vCPU
  • Requests per concurrent user (Assumption)
  • CPU per page request, light (web app) (Assumption)
  • CPU per page request, heavy (web app) (Assumption)
  • Target CPU use at peak (Assumption)
Memory: operating system0.5 GiB
  • Operating system memory (Assumption)
Memory: runtime1 GiB
  • Runtime memory (web app) (Assumption)
Memory: load at peak0.63 GiB
  • Requests per concurrent user (Assumption)
  • Memory per page request a second (web app) (Assumption)
Memory: headroom (high end)1.06 GiB
  • Memory headroom (high end) (Assumption)
Disk: operating system and images10 GB
  • Operating system and images (Assumption)
Disk: data20 GB to 40 GB
  • Data growth (high end) (Assumption)

Calculator server-size 1.0.0 · engine @anaroq/calc 1.4.0 · data snapshot 2026.10.4 · How the calculators work

Assumptions

Every number the result uses that you didn't enter. Change any of them to match your case.

  • Assumption
    req/s

    One request every five seconds per active user: people read and type between clicks.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption
    %

    Room above the peak for bursts, deploys and backups, so the server is not at 100% when it matters.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption
    GiB

    A minimal Linux server with SSH, logging and a container runtime.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption

    The high end multiplies the memory need by this: page cache, spikes, a second copy during a deploy.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption
    GB

    The OS, packages, container images and logs before your data.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption

    The high end keeps room for the data to double: growth, local dumps before upload, temporary files.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption
    ms

    The low end of the range. A server-rendered page with a few database calls: tens of milliseconds of CPU, a runtime of about 1 GiB.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption
    ms

    The high end of the range. A server-rendered page with a few database calls: tens of milliseconds of CPU, a runtime of about 1 GiB.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption
    GiB

    What the running service holds before any load: the runtime, the code, connection pools.

    No source: this is our own assumption. Change it if you know your case.
  • Assumption
    MiB

    Work in flight at peak: requests being served, their buffers and the extra workers that serve them.

    No source: this is our own assumption. Change it if you know your case.

What you enter and the assumptions you change are kept in this page's link, after the #.

Take the result with you

The result as a Markdown file: what you entered, the breakdown, every assumption with its source or its mark, and the link that reproduces it. A Deployment Spec lists catalog apps, so it comes from the Stack Sizer, not from here.

server-size.md
# Server size calculator

An estimate from the assumptions listed below, not a measurement or a guarantee.

No source: this is our own assumption. Change it if you know your case.

## What you entered

- Workload: Web app (server-rendered pages)
- Concurrent users at peak: 200
- Data on the server (GB): 20

## Result

- vCPU: 1 vCPU to 2 vCPU
- RAM: 3 GiB to 4 GiB
- Disk: 30 GB to 50 GB
- Peak load: 40 req/s

## Breakdown

| Line | Value | Assumptions used |
| --- | --- | --- |
| Peak load | 40 req/s | Requests per concurrent user |
| Busy CPU at the target use | 0.67 vCPU to 2 vCPU | Requests per concurrent user, CPU per page request, light (web app), CPU per page request, heavy (web app), Target CPU use at peak |
| Memory: operating system | 0.5 GiB | Operating system memory |
| Memory: runtime | 1 GiB | Runtime memory (web app) |
| Memory: load at peak | 0.63 GiB | Requests per concurrent user, Memory per page request a second (web app) |
| Memory: headroom (high end) | 1.06 GiB | Memory headroom (high end) |
| Disk: operating system and images | 10 GB | Operating system and images |
| Disk: data | 20 GB to 40 GB | Data growth (high end) |

## Assumptions

- Requests per concurrent user: 0.2 req/s. One request every five seconds per active user: people read and type between clicks. **Assumption**
- Target CPU use at peak: 60%. Room above the peak for bursts, deploys and backups, so the server is not at 100% when it matters. **Assumption**
- Operating system memory: 0.5 GiB. A minimal Linux server with SSH, logging and a container runtime. **Assumption**
- Memory headroom (high end): 1.5. The high end multiplies the memory need by this: page cache, spikes, a second copy during a deploy. **Assumption**
- Operating system and images: 10 GB. The OS, packages, container images and logs before your data. **Assumption**
- Data growth (high end): 2. The high end keeps room for the data to double: growth, local dumps before upload, temporary files. **Assumption**
- CPU per page request, light (web app): 10 ms. The low end of the range. A server-rendered page with a few database calls: tens of milliseconds of CPU, a runtime of about 1 GiB. **Assumption**
- CPU per page request, heavy (web app): 30 ms. The high end of the range. A server-rendered page with a few database calls: tens of milliseconds of CPU, a runtime of about 1 GiB. **Assumption**
- Runtime memory (web app): 1 GiB. What the running service holds before any load: the runtime, the code, connection pools. **Assumption**
- Memory per page request a second (web app): 16 MiB. Work in flight at peak: requests being served, their buffers and the extra workers that serve them. **Assumption**

Calculator server-size 1.0.0 · engine @anaroq/calc 1.4.0 · data snapshot 2026.10.4

Open this calculation: https://anaroq.com/tools/server-size-calculator#k=eyJhc3N1bXB0aW9ucyI6e30sImNhbGMiOiJzZXJ2ZXItc2l6ZSIsImlucHV0Ijp7ImNvbmN1cnJlbnRVc2VycyI6MjAwLCJkYXRhR2IiOjIwLCJsb2FkQmFzaXMiOiJ1c2VycyIsInBlYWtScHMiOjUwLCJ3b3JrbG9hZCI6IndlYi1hcHAifSwidiI6MX0
How the calculators work: https://anaroq.com/methodology#calculators

What it does

It turns a workload you describe (what kind, how much load at peak, how much data) into a range of vCPU, RAM and disk for one server, and shows how each part of the range was reached. It is for software that is not in our catalog: your own app, an API, a database, a queue worker or a static site.

How it works

  1. Load: the requests a second you enter, or concurrent users × requests per user (an assumption you can change).
  2. CPU: busy cores = load × CPU time per request, for a light and a heavy request of that workload, divided by the CPU use you aim for at peak. Rounded up to whole vCPU, at least 1.
  3. RAM: the operating system, the runtime's own memory and memory per request a second at peak; for a database also the share of the data it keeps in memory. The high end adds headroom. Rounded up to whole GiB, at least 1.
  4. Disk: the operating system and images plus your data, and at the high end room for the data to double. Rounded up to whole GB.
  5. Every number you did not enter is listed under Assumptions with why we chose it. None of these defaults has a published source, so each one carries the Assumption mark: change it when you know your case.

Example

A web app with 200 concurrent users at peak and 20 GB of data, with every assumption at its default:

Web app · 200 concurrent users · 20 GB

vCPU
1 vCPU to 2 vCPU
RAM
3 GiB to 4 GiB
Disk
30 GB to 50 GB
Peak load
40 req/s

Limits

  • An estimate, not a measurement. The CPU time per request of your own code can be ten times lighter or heavier than the default: measure it (an APM, or request timings under load) and enter it.
  • One server, one workload. A database and an app on the same server: size each and add them up; a cluster or replicas are not modelled.
  • No GPU, no video encoding, no in-memory analytics: those are sized by other tools.
  • No price. To compare plans for the size you get, use a dated price list.

Methodology: how the numbers are worked out

Sources

  1. ANAROQ calculator methodology: assumptions, units and rounding

Updated

Next step

Bandwidth and monthly traffic calculator

A free public tool by ANAROQ, a company building compute infrastructure. What ANAROQ is building