Game server requirements: RAM, CPU and disk by game

Most sizing advice for game servers is one number with no context attached, which is why so many people buy 16 GB for a game that is limited by a single CPU core and 1 GB for a game that eats memory for a month after launch. The table below is the honest version: a starting point in RAM, vCPU, disk and ports for every game in the RE:NODE catalogue, followed by the reason each genre needs what it needs, so that you can move up or down from the number instead of guessing at it. If you only read one line, read this one: memory is what gets sold, one fast core is usually what runs out, and disk is the resource that fails quietly during an update at three in the morning.

How to read these numbers#

Four columns, four different kinds of claim, and they are not equally reliable.

RAM is a hard ceiling, not a target. A container given 4 GB is stopped at 4 GB. So the figure in the table is the allocation a server of that game should start with for a normal group on a world that is a few weeks old, with a little headroom above what the process actually uses. Most games will show 60-75% of it in use on the panel's memory graph, and that is correct. A server sitting at 97% of its limit is one busy evening away from being restarted by the kernel.

vCPU is the confusing one, because it is a share rather than a count. On Pterodactyl-based hosting, RE:NODE included, the CPU number is a percentage of one core, so 150 means 1.5 vCPU and it is a hard throttle rather than a promise of one and a half physical cores. It buys you two things: headroom on the main thread when a fight starts, and somewhere for the secondary threads - saving, networking, chunk generation, garbage collection - to run without stealing from the simulation. Almost no game server uses more than one core for the thing you care about, so 2 vCPU is not "twice as fast as 1", it is "one busy core plus room for everything else".

Disk is the allocation to buy, not the size of the download. It has to hold the game, the world and its saves, any mods, the logs, and enough free space for the next update to download before it replaces what is there. Running exactly at the size of the install is how an update fails.

Ports is how many allocations the server needs. A game port is never the whole story: most games want a separate query port so that server browsers can see them, and several want a third for RCON, a web admin panel or a second shard. Game server ports explained is the long version of why a server can run perfectly and be invisible.

Requirements for every game we host#

Every row is a comfortable starting point for a typical group, not a minimum that barely boots and not a number designed to sell you something bigger. Each game name links to its plans and their exact ladders.

Two things are worth noticing about that table before the explanations.

The first is the spread. Counter-Strike 1.6 wants a gigabyte and a fraction of a core; Palworld, Satisfactory and The Front want eight gigabytes and two and a half. That is a factor of eight in memory between games that both describe themselves as multiplayer servers for a handful of friends, and it is entirely explained by how much world the server has to hold in memory at once.

The second is that the RAM column and the vCPU column do not move together. Counter-Strike 2 and Insurgency: Sandstorm are near the bottom on memory and near the top on CPU relative to their memory. The Forest and Abiotic Factor are the reverse. Buying a bigger plan raises both, which is fine, but it means the plan you actually need is set by whichever of the two runs out first - and telling them apart is a thirty-second job covered in CPU or RAM: which one is holding your server back.

Survival and base-building: memory is the constraint#

7 Days to Die, Palworld, Project Zomboid, DayZ, Abiotic Factor, The Forest, Sons of the Forest, The Front, The Isle, Satisfactory and Valheim all behave the same way under the hood, whatever their genre labels say. The server holds a world that is generated as people explore it, and it keeps holding it. Memory use on day one is not memory use in week six, and nothing you do in the config changes that trajectory much.

The mechanism is worth understanding because it tells you when to worry. A survival server's memory is roughly the sum of three things: the chunks or cells currently loaded because somebody is near them, the persistent objects that exist whether or not anyone is nearby, and the engine's own floor. The first grows with how spread out your players are. The second grows forever, because every base, chest, farm, corpse, vehicle and dropped item is a persistent object that the world file now carries.

That gives you three practical rules:

• Size for the map, not the player count. Four players who have each built a base 3,000 metres apart cost far more than eight players in one town. This is the single biggest reason that "it was fine last month" servers stop being fine.
• Expect a climb and plan a restart. A weekly scheduled restart does not fix a memory leak, but it does return the server to its floor rather than its ceiling, and on most of these titles the difference is a gigabyte or more.
• Wipes and prunes are a memory tool. 7 Days to Die's region reset, Project Zomboid's EraseAllModData style clean-ups and DayZ's loot economy settings all exist partly because the alternative is a world file that grows without limit.

Palworld is the extreme case and gets its own treatment in Palworld server memory: the server holds every pal in every base for every player, online or not, and the number that matters is the total number of bases on the map rather than the number of people connected. Valheim's cost driver is terraforming, which is stored per modified patch of ground and never goes away. The Isle and The Front are large Unreal maps where the floor alone is several gigabytes before a single player joins.

Shooters and arena games: one fast core#

Counter-Strike 2, Counter-Strike 1.6, Team Fortress 2, Insurgency: Sandstorm, Killing Floor 2 and SCP: Secret Laboratory are the opposite problem. The map is fixed, small and loaded once, so memory is nearly constant from the first second to the last. What varies is how much work the server does per tick, and there are 64 or 128 of those every second.

A tick has a fixed budget: at 64 tick, the server has 15.6 ms to simulate movement, run hit registration, tick every plugin and build a snapshot for every connected client. Go over it and the tick is late, which players feel as rubber-banding and inconsistent hit registration rather than as "lag". That work happens on one thread, so the only thing that helps is a faster core or less work per tick. Adding memory to a shooter that stutters changes nothing at all. What tick rate actually means covers how to read the number in each engine.

Where the memory in the table goes, for these titles:

• Counter-Strike 1.6 is a twenty-year-old GoldSrc binary. A gigabyte is generous and it will never use it. It is on the list because the plan has to exist, not because the game is demanding.
• Counter-Strike 2 and Team Fortress 2 sit at 1-2 GB with a full server, and the rest of the allocation is headroom for map changes, demo recording and plugins. Metamod and CounterStrikeSharp or SourceMod add a little memory and a meaningful amount of per-tick CPU, which is the part to watch.
• SCP: Secret Laboratory is higher than its player count suggests because the round is a whole facility simulated at once, and because the standard plugin frameworks bring a .NET runtime with them.
• Killing Floor 2 is Unreal 3 with a large install, and its six-player rounds spawn a lot of AI. The CPU cost is in the zed pathing, not in the players.

If you run any of these with plugins, assume the plugins are your CPU budget. A stock Source server with 24 players is nearly idle. The same server with forty SourceMod plugins, a database-backed rank system that queries synchronously, and a map vote running every round is a different machine.

Sandbox, scripted and simulation worlds#

The remaining games are the awkward middle, and they have one thing in common: their requirements are set by what you add rather than by what ships.

Minecraft is both memory-bound and CPU-bound in a ratio you choose. view-distance and simulation-distance in server.properties convert one into the other directly - each player keeps a square of 2 x view-distance + 1 chunks loaded, so dropping from 10 to 6 removes about 62% of the chunks each player holds. 4 GB runs a comfortable twenty-player Paper server on vanilla settings; a heavy modpack wants 8 GB or more and a different Java configuration entirely. How much RAM a Minecraft server needs and the Paper optimisation guide are the detail.

FiveM is a scripting platform with a game attached. The server binary itself is modest; the resources you install are not. A stock server with a handful of resources is happy at 2 GB, and a full roleplay framework with two hundred resources, a database behind it and OneSync enabled is a 6-8 GB machine with a real CPU appetite. The resource list is your requirements document.

Garry's Mod is the same story in Lua. A vanilla sandbox server is tiny. DarkRP with sixty addons and a workshop collection is not, and every addon runs on the same main thread as the game.

Factorio is the purest CPU case on the list. The server runs the simulation in lockstep at 60 updates per second, and a large factory can miss that target on a fast core while using under a gigabyte of memory. If UPS drops, more RAM is not the answer; fewer entities is.

Terraria, Don't Starve Together, RimWorld, Skyrim Together, Euro Truck Simulator 2, Assetto Corsa and BeamMP are all small servers by modern standards, and for all of them the reason to move up a tier is mods rather than players. Don't Starve Together is the odd one because a cluster with caves is two server processes sharing one allocation, so budget for both. BeamMP's cost is physics, and physics is per vehicle rather than per player.

Disk, and the update that fills it#

Disk is where people get caught, and it is the least interesting resource right up until it is the only one that matters.

A game server's disk holds four things, and only the first is the one people think about:

1. The installed game, which for SteamCMD titles is a download that has grown with every update since release.
2. The world, saves and their rotating backups, which for survival games can reach several gigabytes on their own.
3. Mods, workshop content, maps and downloaded assets. On Arma 3, DayZ, Garry's Mod and Killing Floor 2 this routinely exceeds the base install.
4. Free space for the next update.

That fourth line is the one that breaks servers. SteamCMD downloads into the same volume it is updating, so an update needs roughly the size of the changed files free on top of the existing install before it can swap them in. A disk that is exactly the size of the game is a disk whose next update fails, usually with a misleading error about a missing app manifest. Leave 20-30% free and the problem never happens. SteamCMD explained covers validate, betas and what a failed update leaves behind.

Two more disk facts worth having:

• Logs grow. A busy Source server with verbose logging, or a Minecraft server with a chatty plugin, will write hundreds of megabytes a week. Rotate them or delete them on a schedule. Logs worth keeping is about which ones are worth the space.
• Backups stored next to the world are not backups. Every game with built-in backup rotation writes into the same directory on the same disk. They protect against a corrupt save, not against a deleted server. They also count against your disk allocation.

Disk speed is a separate question from disk size, and it matters for exactly one operation on a game server: the save. A game that writes the whole world in one blocking pass, which is most survival titles, freezes for the duration. What NVMe actually changes works through which operations feel it and which do not.

Ports and protocols#

The port count in the big table is how many allocations to budget for. Here are the actual defaults for the games where they are stable and worth knowing:

The pattern across almost all of them: the game itself speaks UDP, the query protocol usually speaks UDP on a different number, and anything administrative - RCON, telnet, a web panel - speaks TCP. A firewall rule that opens only TCP is the single most common reason a server runs and cannot be found, and TCP vs UDP for game servers explains why the split exists at all.

Where a table like this goes wrong#

Four ways, and it is worth being honest about all of them.

Mods invalidate everything. Every number above is for a stock server. A Minecraft modpack, an Arma 3 mod list, a FiveM resource folder or a Project Zomboid workshop collection can double or triple both memory and CPU, and there is no table in the world that can predict by how much. The only method that works is to install what you intend to run, load it with real players for an evening, and read the graphs.

Age changes the answer. Sizing is not a one-time decision on a persistent-world game. The correct plan for month six is not the correct plan for launch week, which is why when to upgrade your plan is about symptoms rather than about thresholds.

Player count is the weakest predictor. Ten players standing together cost a fraction of ten players scattered across a map. How many players fit on a server goes through the arithmetic per game and why a slot number in a config file promises nothing.

Versions move. Every figure here is for the current build of each game as of writing. Major updates change memory profiles, sometimes by a lot, and a game that was comfortable at 4 GB before a large content patch may not be after it. Check the graphs after any update that changes the world format.

None of this means the table is useless. It means it is a starting point that you should expect to correct once with real data, in one direction or the other, which is a far better position than starting from a number somebody invented for a pricing page.

FAQ#

Is more RAM always better for a game server?

No. Memory above what the process uses does nothing at all, and on a JVM game such as Minecraft an oversized heap actively hurts by making garbage collection pauses longer. Buy the memory the server needs plus headroom for the busiest hour, then spend the rest of the budget on CPU if anything still stutters.

What does 1.5 vCPU actually mean?

A hard limit of 150% of one core. The server can use one full core and half of another simultaneously, and it is throttled above that rather than being allowed to borrow. Because almost all game servers run their simulation on a single thread, the practical effect is one busy core plus room for saving, networking and garbage collection to happen without interrupting it.

How much disk should I leave free?

Roughly 20-30% of the allocation. Most of that is for updates, which download alongside the existing install before replacing it, and the rest is for logs and backup rotation. A server running at 95% disk will fail its next update with an error that does not mention disk space.

Why does my server need two or three ports for one game?

One for the game traffic, one for the query protocol that server browsers and tracking sites read, and sometimes a third for RCON, a web admin interface or a second world shard. The game works with only the first one open; it is simply invisible to anyone browsing for it.

My server was fine and now it is not. What changed?

Usually the world, not the plan. Persistent-world games accumulate structures, items and explored terrain, and all of it has to be held or ticked. Check whether memory at idle has risen over weeks, and whether your players have spread out across the map. Both are common and neither shows up as a change you made.

Can I start small and move up later?

Yes, and it is the right approach for anything except a launch you have advertised. Start one tier below what you think you need, watch the graphs for a fortnight, and move if the numbers say so. On RE:NODE, changing plan raises the limits on the server you already have rather than rebuilding it, so the world, the config and the address all stay where they are.