Palworld Player Limits: Why 32 Is Not Always 32

"Palworld dedicated servers support 32 players" usually gets read as "buy a server and 32 people can play." There are several layers between those two statements, and each one can leave you with far fewer usable slots than the number in your config.

This covers what actually decides that number, what else you collide with when you raise it, and how to pick a value your group won't regret. Setting the server up in the first place is the complete setup guide.

The number you can set

The option is ServerPlayerMaxNum, inside that one long line in PalWorldSettings.ini:

OptionSettings=(...,ServerPlayerMaxNum=32,...)

32 is both the default and the officially supported ceiling. People have pushed it higher; that's outside what the developers expose, with no stability guarantees and no shared experience to fall back on when something breaks.

Changing it requires a server restart, like every other option (all of them explained here).

So far, simple. The complicated part is next.

The number the machine will actually hold

ServerPlayerMaxNum is a promise, not a capability. It tells the server how many connections to allow; whether they can be served is up to the machine underneath. Set 32 on hardware good for 8, and player nine doesn't get turned away — everybody lags instead.

Palworld's server memory behaves differently from most games in one important way: it tracks world size, not concurrent players.

• Somebody logs in, memory rises a little
• Somebody logs out and their base keeps running — structures, stationed Pals, production lines, all still simulated in memory

So a ten-person server that "usually only has three people on" uses far more than three players' worth. What eats memory is how much those ten people have built in total.

A rough starting point, assuming each person runs one mid-sized base:

These are starting points, not endpoints. The same eight players, three months in with three fully staffed bases each, will use several times what they did at launch. Memory that only goes up is normal here.

What else moves when the cap goes up

Take ServerPlayerMaxNum from 8 to 20 and you think you changed one option. You actually collided with three more:

That middle row is where groups get caught: the base limit is per guild, not per player. One 20-person guild gets four bases — 0.2 each. Players assume more people means more bases; the game's rule is the exact opposite.

So raise the cap and read all three. Two configurations that work:

• One big guild: raise BaseCampMaxNumInGuild (the engine allows up to 10) and share bases
• One guild each: leave it at the default, but check BaseCampMaxNum has enough to go around

Symptoms of a cap set too high

Running out of memory and running out of CPU look different, and telling them apart is how you know what to add:

Out of memory — the server process disappears entirely. Players see everyone dropped at once and the server gone from the list. On Linux that's the OOM killer; dmesg has the record. This is the bad one, because a save being written when the process died can be corrupted along with it (see backups and restores).

Out of CPU — you rubber-band while running, Pals freeze mid-task at base, gathering registers a beat late. Nothing disconnects; it just plays badly. Pal behavior simulation leans on single-core performance, so more cores helps far less than a faster core.

Enough of both, but the world is huge — long load times on join, save files well past a few hundred MB. That's not a config problem; that's a hint to start a fresh world.

Picking a number

Size it to who will actually be online at once, not to your friends list.

A practical approach: count the peak on a Saturday night, add two to four, and pick the machine for that. The cap can be raised any time you're willing to restart; a machine that's too small is everyone lagging at once. Prefer a lower cap on roomier hardware.

One more thing people miss: the cap is also a door. Setting it to 32 means anyone who learns your address can take a slot. Pair it with ServerPassword rather than relying on the number to keep people out.

Common questions

Can the player cap go above 32? 32 is the officially supported ceiling. Larger values are outside what the developers expose — no stability guarantees, and no shared experience to fall back on when it breaks.

I changed ServerPlayerMaxNum and nothing happened. Why? Like every other option it's read once at startup, so the server needs a restart. Also check you edited the file under Pal/Saved/Config/, not DefaultPalWorldSettings.ini, which the server never reads.

How much RAM for eight players? With one mid-sized base each, 16 GB is the comfortable band. Memory tracks world size and only goes up, so size for month three rather than week one.

Where the ceiling really is

The number in the config file is a promise the machine underneath has to keep. When the two disagree, it's the machine that gives, not the number.

Plans at KeepWorlds for a dedicated Palworld server bind the two together: each plan's player count comes with the machine that holds it, on your own hardware, never shared with someone else's world — so the number you set and the number you can serve can't drift apart.