How many players fit on a server, game by game

Slots are a number in a config file. Typing max-players=100 costs nothing and promises nothing. The real limit is whichever of four things runs out first - memory, tick budget, bandwidth or disk - and which one it is depends on the game and on what those players are doing. A plan advertised as supporting forty players supports forty players doing something specific, and the something is almost never stated. This post is how to work out your own number, with a table of realistic counts per game and the method for testing it rather than trusting anyone's table, including this one.

Slots are a config number#

Every game exposes a maximum player count and it is enforced by the game, not by the hardware. max-players in server.properties, MaxPlayers in Squad's Server.cfg, sv_maxclients in FiveM, maxplayers in Terraria's serverconfig.txt. Set it high and the server accepts that many connections; it does not become able to simulate them.

What happens when you exceed what the hardware can do depends on which resource ran out, and they fail in completely different ways:

• Memory runs out abruptly. The process is killed, or the JVM starts spending more time collecting garbage than running the game. There is no graceful degradation. On RE:NODE, reaching the memory limit stops the container and it restarts clean rather than swapping to disk, which is faster to recover from and means unsaved state is lost - so the save interval matters more than people think.
• Tick budget runs out gradually. The world slows down or updates arrive less often, evenly, for everybody. Nothing crashes. It just gets worse in a way nobody can point at.
• Bandwidth runs out selectively. Players furthest from the server, or on the worst routes, start seeing loss first.
• Disk runs out periodically. The server freezes for a second every time it saves, and the freeze gets longer as the world grows.

Only the first of these is what most hosting is sold on. The second is what most servers actually hit.

What actually runs out first#

Memory is the sum of the world that is loaded, the entities in it, and a per-connection overhead that is usually small. The per-connection part is genuinely minor. The loaded-world part is not, and it scales with where players are, not how many there are.

Tick budget is the 50 ms, 20 ms or 15.6 ms the server has per step. Every player adds work: their movement to simulate, their surroundings to keep ticking, a snapshot to build and send. This is the limit for most shooters and for any Minecraft server with active players, and it is measured, not guessed - see what tick rate actually means for how to read it in each game.

Bandwidth is snapshot size times tick rate times players, both ways. It is rarely the binding constraint on a modern uplink, but it does bite high-tick shooters with large player counts and any game that sends world data on join. Bandwidth and fair use covers what unmetered actually means.

Disk matters at save time. Games that write the whole world in one blocking operation get worse as the world grows, independent of player count - except that more players means more world explored. What NVMe actually changes is about exactly this operation.

Realistic player counts by game#

Caps and defaults move between versions, so read the first column as the shape of the thing and confirm it in your own config. The third column is what a well-configured server holds comfortably on rented hardware without anything feeling wrong.

Three patterns are worth pulling out of that table.

Survival and building games are memory-bound. Palworld, Project Zomboid, 7 Days to Die, the Forest games: every player explores, and exploring loads and keeps world. Memory is what you buy, and the number climbs for weeks after launch even if the player count does not. Palworld server memory is the worked example.

Shooters are CPU-bound. Counter-Strike, Team Fortress 2, Squad and anything Unreal run a fast tick over a small, static map. The world costs nothing to hold and everything to update. Memory is almost irrelevant above a low floor, and clock speed is the whole game - see Squad server hosting for what that looks like at 100 slots.

Minecraft is both, in a ratio you set. view-distance and simulation-distance are the dial that converts CPU pressure into memory pressure and back, which is why how much RAM a Minecraft server needs has to talk about settings rather than just a number of gigabytes.

Memory per player is not constant#

Here is the mistake that causes most bad sizing. People take a total memory figure, divide by a player count, and treat the result as a per-player cost. It is not, because most of what a player costs is the world they cause to be loaded, and that depends entirely on whether they are standing next to each other.

Minecraft makes the arithmetic visible. A player keeps a square of chunks loaded around them, with a side of 2 x view-distance + 1:

view-distance=10  ->  21 x 21  =  441 chunks per playerview-distance=8   ->  17 x 17  =  289 chunks per playerview-distance=6   ->  13 x 13  =  169 chunks per playerview-distance=4   ->   9 x  9  =   81 chunks per player

Ten players standing in one town share almost all of those chunks: the server might hold 600 chunks in total. The same ten players scattered across a 10,000-block map share nothing and the server holds 4,410. Same player count, seven times the loaded world, and the second case is the one you must size for because it is what happens on any server people actually play on.

Dropping view-distance from 10 to 6 removes 62% of the chunks each player keeps loaded. That single change usually does more for a struggling server than doubling its memory, and it costs players a view they mostly were not looking at. In Minecraft 1.18 and later, simulation-distance is separate and is the one that controls how far mobs, crops and redstone actually tick - set it lower than view-distance and you keep the view while cutting the work. The details are in the Paper optimisation guide.

The same principle applies without the tidy maths in every open-world game. Concentrated players are cheap. Scattered players multiply the loaded area. And building players are the expensive kind permanently, because what they build stays loaded-adjacent forever whether they are online or not.

Tick budget per player#

Tick cost per player is not linear either, and it is worse than linear for two reasons.

The first is interaction. Ten players in ten separate places each generate their own work. Ten players in one place generate their own work plus the cost of telling each of them about the other nine, and that part grows with the square of the group. This is why a 60-player server is fine until everyone converges on the same objective, and why the worst frame of the night is always the big fight.

The second is what players bring with them. In most games a player is also a vehicle, a base, a farm, a dozen dropped items and a pet. Those tick whether or not the player is online.

tick cost ~= base world + (players x their own surroundings)                        + (players in view of each other, squared)                        + everything anyone has ever built

The practical consequence is that capacity falls over the life of a server. The 40 players who were comfortable in week one are not comfortable in month six on the same hardware, because the world has grown underneath them. If your server felt fine at launch and does not now, the player count is probably not what changed.

Bandwidth, and when it is actually the limit#

Outbound traffic is roughly snapshot size times tick rate times players, and it is the one resource where the arithmetic is straightforward:

32 players x 64 ticks/s x 200 bytes  ~=  410 kB/s out, sustained64 players x 20 ticks/s x 500 bytes  ~=  640 kB/s out, sustained

Those numbers are small on any competent connection, which is why bandwidth is rarely the constraint. Where it does bite:

• Join bursts. Games that send world data on connect - Minecraft chunks, Factorio's entire save, mod downloads - spike hard when several people join at once after a restart. A restart at peak time is a bandwidth event.
• Voice. Built-in proximity voice in survival and milsim games can exceed the game traffic itself.
• High tick with high slots. 128 tick and 32 players is a genuinely busy pipe.

Unmetered means you are not billed per gigabyte. It does not mean you can saturate a shared uplink indefinitely, and it does not change what a player on a poor route experiences.

Hard caps you cannot raise#

Some numbers are not sizing decisions at all. Valheim is capped at ten players in code; buying more memory does not change it, and the mods that raise it are raising a limit the game was balanced around. The Forest and Sons of the Forest are eight. Euro Truck Simulator 2 Convoy is eight. Killing Floor 2's standard modes are six. Satisfactory ships with a low default that is configurable but was never tuned for a crowd.

When a game has a hard cap, your sizing question is completely different: you are not asking how many players fit, you are asking how much world and how many hours of building those fixed players will generate. A ten-player Valheim server that has been running for a year needs more than a ten-player Valheim server that started yesterday, and the Valheim guide is explicit about why - terraforming is stored, permanently, per modified patch of ground.

Testing it properly#

Twenty minutes of a real, full server tells you more than any table. The method:

1. Establish the baseline. Restart the server, let it settle for five minutes with nobody on, and write down memory, CPU and tick rate. This is your floor.
2. Fill it with the people you expect. Not bots, not a stress tool - real players doing what they normally do. Bots stand still and cost nothing; players scatter.
3. Watch for twenty minutes. Memory should rise and then flatten. CPU should rise and stay below its limit. Tick rate should hold.
4. Then make them converge. Announce something at one location and get everybody there. This is the worst case and the one that decides your real capacity.
5. Write down the four numbers at the worst moment. Peak memory, peak CPU, lowest tick rate, and the player count at that instant.

What good looks like: memory peaking around 75-80% of the limit, CPU below its ceiling with room to spare, tick rate at or near target. What a full server looks like: memory above 90%, or CPU pinned at the limit, or tick rate visibly below target during the convergence.

A live graph makes this a five-minute job rather than a research project. The RE:NODE panel draws memory, CPU and disk against the limits on the plan, so the peak is a thing you look at rather than something you have to instrument. Reading a server load graph covers what the shapes mean, and when to upgrade your plan covers what to do about them.

Queues, reserved slots and honest advertising#

Once you know your number, the question becomes what to do when more people turn up.

• A queue holds players outside the server until a slot frees. Squad has one built in with PublicQueueLimit; most games do not, and adding one usually means a proxy or a plugin. A queue converts a bad experience into a wait, which is an improvement.
• Reserved slots hold capacity for admins and members. Note that in most implementations - Squad's NumReservedSlots is the clear example - reserved slots come out of the maximum rather than adding to it. A 80-slot server with 4 reserved is a 76-slot public server.
• Advertising a number you cannot hold is the worst option and the most common. A server listed as 100 slots that plays badly above 60 loses players permanently; the ones who tried it at 85 will not come back to find out whether it improved.

The uncomfortable version: capacity is a property of your hardware and your configuration, and lowering the advertised number is free while raising the hardware is not. A 40-slot server that is always good beats a 100-slot server that is sometimes unplayable, every single time.

Plans on RE:NODE are listed by memory, disk, CPU share and the ports they allocate, and moving between them changes the limits on the server you already have rather than building a new one - so a test that says you need more is cheap to act on, and one that says you need less is cheap to act on too.

FAQ#

Can I just set max players to 100 and see what happens?

You can, and on a small plan what happens is a memory kill or a tick rate that halves once the server is genuinely full. The failure arrives at the worst moment, which is the evening you finally got 100 people to show up. Test with a number you can hold, then raise it.

Does each player need a fixed amount of RAM?

No, and the per-player rule of thumb is the most misleading figure in hosting. Most of a player's cost is the world they load around them, which depends on how spread out they are. Ten players in one town can cost a fraction of what ten scattered players cost.

Why does my server handle 30 players in a shooter but only 10 in a survival game?

Different limits. A shooter has a small static map and burns its budget on a fast tick. A survival game has a huge dynamic world and burns memory on holding it. They are sized against different resources and the numbers are not comparable.

My server has spare memory but lags when full. What do I buy?

Nothing yet. Spare memory with lag means the tick budget is the limit, so the fix is doing less work per tick - lower view or simulation distance, fewer entities, fewer scripts on timers - or a faster core, not more gigabytes. CPU or RAM is the triage.

How many players can a 4 GB plan hold?

It depends entirely on the game. 4 GB holds a full ten-player Valheim world, a 20-40 player Minecraft server with a sensible view distance, a busy Counter-Strike server with memory to spare, and roughly nobody at all on a modded Palworld or 7 Days to Die world. Find your game in the table above rather than the memory figure.

Does a bigger plan raise my player cap?

Only where the cap was a resource limit. If the game hard-codes the maximum, as Valheim does at ten, no plan changes it. Where the cap is yours to set, a bigger plan raises the number you can actually hold, which is a different thing from the number in the config file.