How the numbers are calculated.

Each game below lists the formula the calculator actually runs, the constants it uses, and a confidence rating. The constant tables and the defaults table are read live from assets/js/calculators.js when this page loads, so they cannot drift out of sync with the tool — if the code changes, this page changes with it.

This reference is maintained in English only, like the README. The calculator itself is bilingual. — Diese Referenz wird nur auf Englisch gepflegt, wie das README. Der Rechner selbst ist zweisprachig.

Confidence ratings

• High Primary documentation from the developer, or a figure several independent hosts agree on.
• Medium Community consensus and reported production configurations, no authoritative spec.
• Low Extrapolated from a related title or a small sample. Treat as a starting point and measure.

Memory is rounded to real hardware

Nobody rents 6.3 GB. Every memory figure is rounded up to the next rung of a ladder that matches how machines and hosting plans are actually sold:

This is why small changes sometimes move nothing and one more player occasionally jumps a whole tier — the underlying number is continuous, the ladder is not.

Tick budgets

The headroom meter estimates how long one server tick takes against the time it has. Different engines have wildly different budgets, which is the main reason a Counter-Strike server and a Minecraft server want opposite hardware:

Green is under 55% of budget, amber to 80%, red beyond. The estimate covers the steady state — it does not model chunk-generation bursts, autosave stalls or a mob farm built specifically to hurt you.

Monthly transfer

Peak uplink converted at 40% average utilisation, because the player slider is a peak figure and servers are not full at 04:00:

transferGB = peakMbps × 0.40 × 2,592,000 s ÷ 8 ÷ 1000

Hardware class

The recommendation maps onto something rentable rather than a raw spec. A shared vCPU is fine up to about 8 GB and 3.5 GHz; past that, throttling on shared cores shows up as lag spikes precisely at peak hours, so the calculator asks for dedicated vCPU or bare metal.

Memory is modelled per loaded chunk, not per player. Most calculators multiply a per-player figure by head count, which is how hosting is priced but not how the server works. What the JVM holds is resident chunks — palettes, heightmaps, light data and the entities inside them. Players standing near each other share almost all of those chunks, so memory grows sublinearly with population.

chunksPerPlayer = (2 × viewDistance + 1)²
loadedChunks    = min(worldChunks, chunksPerPlayer × players^0.65)

liveSet = base + loadedChunks × kbPerChunk × (1 + entityFactor)
        + players × perPlayerMb + plugins × 8 MB + mods × 25 MB

heap    = liveSet × (1.7 + players × 0.004)
system  = heap × 1.25 + 1 GB

The 0.65 exponent is the clustering term. The GC multiplier grows with player count because allocation rate does — a JVM held near its live set collects continuously. The × 1.25 + 1 covers off-heap: metaspace, code cache, direct buffers, thread stacks, GC structures, and the OS.

Cores

cores = round(1 + load/40 + players/60 + mods/150)     // serial flavours
load  = players × (simDistance/6)^1.4 × cpuFactor
      × (1 + plugins × 0.008) × (1 + mods × 0.004)
mspt  = 3 + effLoad × 0.28

One thread runs the tick loop, always. Everything above it — GC, netty, chunk-generation workers — scales with actual work, so a single-player world at view distance 3 asks for one core. Folia and Pumpkin are the exceptions:

parallel = 1 + (cores - 1) × 0.45
effLoad  = max(load / parallel, load × 0.25)

That load × 0.25 floor matters more than the divisor. Region sharding is bounded by the busiest region, and players cluster at spawn, shops and events — so no core count drives tick time to zero. Without the floor the model claimed a 300-player Folia server would be comfortable on a 3.0 GHz box, which is nonsense.

Simulation distance is exponential; view distance is not. That asymmetry is the most useful thing this calculator has to say. Raising view distance costs bandwidth and some chunk memory; raising simulation distance costs tick time, and tick time is what players feel.

Disk assumes ~6000 chunks generated per player over the server's life at 70 KB per chunk, capped by the world border, plus backups at 45% compression.

• PaperMC documentation — configuration surfaces, Aikar's flags, tuning guidance
• Folia — region-sharded threading model and its caveats
• Pumpkin and its repository — native memory figures, plugin API, Bedrock support
• Spark profiler — the tool to check these numbers against your own server

Hytale's server runs on the JVM, so it gets the same chunk-residency treatment as Minecraft — but with player spread as a variable rather than a fixed clustering exponent. That comes directly from the PerformanceSaver documentation, which states the load curve outright: a large group in a small area has a relatively small resource footprint, whereas a small number of players each exploring independently causes significant CPU load and RAM consumption.

loadedChunks = (2 × viewRadius + 1)² × players^spread
spread = 0.40 clustered | 0.70 mixed | 0.95 explorers

liveSet = 700 MB + loadedChunks × 70 KB × 1.3 + players × 4 MB + mods × 15 MB
if PerformanceSaver: liveSet × 0.75, gcHeadroom 1.75 → 1.50

The PerformanceSaver toggle models what the plugin actually does: caps TPS at a stable 20 (and 5 when empty), shrinks the view radius when it detects low TPS or GC pressure, and forces collection when loaded-chunk counts suggest memory can be freed. With it on, the server degrades gracefully instead of crashing, so you can size for the normal case rather than the worst one. At 32 players that is the difference between a 4 GB and a 6 GB box.

Hytale was cancelled in June 2025, repurchased by its original founder in November 2025, and has been in Early Access since 13 January 2026. The server is still moving fast — re-check after major updates.

• Nitrado PerformanceSaver — the load-curve description this model is built on
• PerformanceSaver source — TPS limiting, dynamic view radius, GC triggering
• hytale.com — patch notes and server configuration surface

RAM = (4 + (mapSize/1000)² × 0.5 + players × 0.04
     + plugins × 0.05 + framework) × wipeFactor
wipeFactor = 0.8 fresh | 1.0 mid | 1.3 late

mapSave = (mapSize/1000)² × 0.035 GB × wipeFactor

Map size dominates: going from 3000 to 4500 costs more RAM than doubling the player count. The wipe factor exists because entity counts grow all wipe long and memory grows with them, which is why a server that was fine on day one starts swapping on day twenty.

Rust serialises the entire map every few minutes, so NVMe is treated as mandatory rather than recommended — on spinning disks the save stall is visible to players. Note the save coefficient is 0.035, not the in-memory figure: a 3500 procedural .sav is a few hundred megabytes, not gigabytes. An earlier version of this calculator got that wrong by roughly 10×.

• Facepunch Rust wiki — server variables, worldsize, save behaviour
• uMod / Oxide — hook model; hooks run on the main thread

RAM  = 3.5 + players × 0.28 + resources × 0.015 + framework
framework = 0 CFX Default | 1.0 ESX | 1.5 QBCore
mspt = 4 + players × 0.2 + resources × 0.025 + framework × 2   (33 ms budget)

This matches the figure hosts converge on independently: roughly 4–6 GB base plus 0.3–0.5 GB per player, with resources and MLOs on top. FiveM runs sync, physics and the Lua runtime dominantly on one thread, so the calculator pushes clock hard and caps cores low — an 8-core at 5.4 GHz beats a 32-core at 2.6 GHz outright.

Above 32 slots you need OneSync and a Cfx.re licence key; the free tier reaches 48, with higher Element Club tiers at 64 and 128. The database is deliberately not included in these figures — give MariaDB its own budget, and move the website and Discord bots off the box.

• Cfx.re server manual — artifacts, server.cfg, OneSync
• OneSync reference — slot tiers and entity routing
• Independent host guidance (Space-Node, GoodLeaf, ElypseCloud, WebsNP, 2026) agreeing on the base-plus-per-player shape and the 33 ms budget at 30 FPS

CS2 has the tightest budget in the calculator. A 64-tick server has 15.6 ms to finish a frame against Minecraft's 50, which is exactly why it asks for clock speed and almost no cores or RAM. CS2 is sub-tick for hit registration, but the server still runs a fixed-rate loop.

CS2   RAM  = 1.2 + players × 0.05 + plugins × 0.04
      mspt = 1.5 + players × 0.12 × modeCost + plugins × 0.06   (15.6 ms)

CS1.6 RAM  = 64 MB + players × 6 MB + plugins × 4 MB
      mspt = 0.4 + players × 0.06 + plugins × 0.04              (10 ms, sys_ticrate 100)

CS 1.6 is from 1999 and fits in the L3 cache of a modern CPU. The smallest VPS any provider sells is already overkill, and the calculator says so rather than inventing a requirement. Use ReHLDS rather than stock HLDS — old builds have known remote-execution holes.

• Valve Developer Community — dedicated server setup, GSLT, rate variables
• AMX Mod X — the plugin layer for 1.6
• ReHLDS — maintained HLDS replacement

RAM = 5 + players × 0.5 + stage        stage = 0 early | 3 mid | 8 late

Memory climbs the longer the process runs, so the figure targets the hours before a scheduled restart rather than the minutes after one. Eight players on an established server lands at 16 GB, which is where the community converged. The 32-player cap is a limit rather than a target — the official server struggles past sixteen on any hardware.

Start with -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS; the difference is large enough to be worth verifying your launcher passes them.

• Palworld technical guide — official dedicated server documentation and settings
• Community reports on memory growth over uptime and restart scheduling

ASA  RAM = 8 + players × 0.12 + stage + mods × 0.25    stage = 0 | 3 | 7
ASE  RAM = 6 + players × 0.10 + stage × 0.8 + mods × 0.2

Every figure is for one map. A cluster runs a separate process per map, so four maps need four times the RAM, cores and disk on the same box. This is the most common way people under-buy for ARK. Structures and tames dominate over player count, which means decay settings do more for your memory bill than a player cap does.

Ascended's install alone is around 70 GB per map; Evolved is markedly lighter — roughly half the memory and a quarter of the disk for the same population. The ASE figures are rated medium confidence: they come from provider guidance and community reports rather than a published specification.

• ARK Wiki — dedicated server setup, GameUserSettings, decay and structure limits
• Hosting-provider specifications for ASA versus ASE per map

RAM = 1.8 + players × 0.28 + stage + mods × 0.08   stage = 0 | 1.4 | 3.2

Valheim keeps a ZDO for every placed piece, dropped item and tamed animal, permanently. Build count drives memory far harder than head count, which is why the stage selector moves the numbers more than the player slider. Ten players is the built-in cap.

Rated low confidence: this is fitted from provider figures and community reports rather than a published server specification, and the ZDO growth curve in particular is a rough approximation. If you run a long-lived Valheim world, your measurements would genuinely improve this model.

• Valheim — dedicated server tooling and the 10-player cap
• lloesche/valheim-server — the reference container and its documentation

heap = 2 + players × 0.45 + mods × 0.02
mspt = 6 + players × 0.5 × populationMultiplier + mods × 0.05

This follows the project's own guidance of roughly 2 GB plus half a gigabyte per player. Zomboid runs on the JVM, so the calculator reports a heap — and that heap is set in ProjectZomboid64.json, not on the command line. Giving the container more memory without editing that file achieves nothing, which is a common and expensive misunderstanding.

Zombie population multiplies the cost of every tick; doubling it costs more than doubling your players. Above roughly 32 players, map streaming rather than simulation becomes the bottleneck and disk speed starts to matter as much as clock.

• PZ Wiki — dedicated server — memory guidance, sandbox variables, JSON heap configuration

RAM = 5 + stage + players × 0.7 + mods × 0.15
stage = 0 early | 2.5 mid | 6 late | 12 megabase

A four-player mid-game server lands on 12 GB, matching Coffee Stain's own recommendation for a dedicated server. The factory simulation runs on one thread: clock speed sets your tick rate and extra cores only help autosaves and networking. Autosave spikes can briefly double resident memory, so the recommendation keeps headroom above the steady state.

• Satisfactory Wiki — dedicated servers — official requirements and configuration

Reforger RAM = 3 + players × 0.12 + scenario + mods × 0.15
Arma 4   RAM = same × 1.5              scenario = 0 GM | 1.4 Conflict | 2.2 modded

On Enfusion the AI count drives CPU, not the player count, which is why the scenario selector moves the numbers more than the player slider. Conflict spawns AI continuously across the whole map and is the usual reason a Reforger server stutters. The networkViewDistance setting is the other big lever — it decides how many entities the server replicates per player.

Arma 4 has not been released. Bohemia Interactive targets 2027 and no dedicated server has ever run. Those figures are Arma Reforger scaled by 1.5 for a larger Enfusion title. They are a planning placeholder, not a specification, and should be re-checked at launch.

• Bohemia Interactive — Reforger server hosting — SteamCMD setup, startup parameters, BattlEye
• Reforger server config reference — every config.json field, scenario IDs, networkViewDistance
• Host guidance converging on 8 GB and 4 cores at 32 players, 16 GB at 64 — which is what this model reproduces
• Bohemia Interactive — Arma 4 — confirms 2027 target and Enfusion engine, nothing more

Voice servers are the odd shape here, and that is the point of including them: not every server is CPU-bound. A voice server is a packet mirror, not a simulation. Each talker's stream is duplicated to every listener, so uplink grows with talkers × listeners while CPU and RAM stay nearly flat.

talkers = users × talkRatio        0.08 quiet | 0.20 mixed | 0.40 busy
uplink  = talkers × (users - 1) × bitrate × 1.35   (1.35 = packet overhead)

TeamSpeak bitrate  25 / 45 / 77 kbit/s      base 60 MB + 1.2 MB per user
Mumble    bitrate  24 / 40 / 72 kbit/s      base 25 MB + 1.2 MB per user

Bandwidth is quadratic in one big channel and near-linear across several small ones, which is the single most useful thing to know when running one. Murmur idles under 50 MB and has no slot licence; a free TeamSpeak licence caps a virtual server at 32 slots, with the free non-profit licence raising that to 512 across up to 10 virtual servers.

The tick budget is 20 ms, the Opus frame interval — every packet has to be mirrored within one frame. Rated medium: the bitrates are documented, the talk-ratio presets are a modelling choice rather than a measurement.

• Mumble documentation — bandwidth is a per-client ceiling in bits/s, Opus settings
• TeamSpeak support — licensing tiers and slot limits
• Opus codec — frame sizes and bitrate ranges

Being explicit about the gaps is more useful than pretending there aren't any. The calculator does not account for:

• Chunk-generation bursts when players first explore, which can briefly dwarf the steady state
• Geyser and Bedrock clients, world pregeneration jobs, and dynmap-style renderers
• Redstone contraptions and mob farms built specifically to hurt you
• Hosting-provider CPU throttling and noisy neighbours on shared cores
• Databases, web panels, Discord bots and voice servers running on the same box
• Any plugin, mod or resource that is simply written badly — usually the real answer

Measure once you are live. Spark for Minecraft and Zomboid, resmon or txAdmin for FiveM, server.fps and perf 2 for Rust, docker stats or htop for anything else.