OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
▥

Server Resource Sizer

Estimate a sensible baseline
3vCPU
8GB RAM
60GB SSD

Planning estimate — benchmark your real workload before purchase.

Introduction

The Server Resource Sizer turns three simple questions — how many containers, how many concurrent users, and how heavy the workload — into a starting estimate of vCPU, RAM and SSD.

It exists to replace the two extremes of capacity planning: buying blind, and guessing from a single number. The estimate includes headroom for bursts, but the final word is always your own benchmark.

Objective

  • Produce a transparent, explainable baseline for CPU, RAM and disk.
  • Adjust the estimate by workload profile: light, balanced or compute-heavy.
  • State clearly that the result is a planning estimate with approximately 25% headroom, not a performance guarantee.

Inputs

  • Number of containers (or services) you plan to run.
  • Number of concurrent users the platform must serve.
  • Workload profile: light (mostly idle), balanced, or compute-intensive.

How it works

Each input contributes to the three outputs through simple linear formulas: containers dominate the CPU and RAM terms, users add to all three, and a base of 2 vCPU, 4 GB RAM and 20 GB disk is always reserved.

The workload profile scales the whole result: light multiplies by 0.65, balanced by 1.0 and heavy by 1.65, which models the difference between an idle API and a render farm.

Every figure is rounded up, and the formulas are published on this page so the estimate can be audited and adjusted.

Testable example

Try it — the analysis runs locally in your browser.

Example

Containers: 8 · Users: 50 · Workload: balanced

Expected output

CPU: 3 vCPU
RAM: 8 GB
Disk: 60 GB
Planning baseline with approximately 25% headroom.

Reading the output

  • Treat the numbers as the minimum starting point, not the target: small services grow faster than they shrink.
  • If your workload is batch-heavy, verify with a real load test before committing to a shape.
  • For bursty traffic, prefer more RAM and CPU credits to sustained CPU — the formula leans that way already.

Risks

  • Under-sizing leads to OOM kills and slow responses during peak load.
  • Over-sizing wastes budget on idle capacity.
  • The estimate ignores workload-specific factors such as database size, storage IOPS and network throughput.

Limitations

  • The formulas are generic heuristics written by one author — they are not derived from your workload.
  • No cloud provider is referenced, because pricing and shapes differ; the outputs are unitless vCPU/RAM/GB.
  • It is a starting point. Load-test before purchasing.

Official references

FAQ

Why 25% headroom?

Headroom absorbs bursts, GC pauses and temporary load spikes without immediate OOM kills. You can raise or lower it by changing the workload profile.

Is this based on real benchmarks?

No. The formulas are transparent heuristics published on this page. Real benchmarks of your workload are the only way to validate the estimate.

Does it consider the database?

Indirectly, as part of the container count and users. A serious database deserves its own sizing exercise.