Palworld Server Requirements: RAM and CPU by Player Count

Palworld's server asks more of the hardware than the game's art style suggests, and it asks in a way most games don't. Undersize it and you don't get "slightly laggy" — you get a machine that falls over a month or two in.

This covers where the resources actually go, how to size by group, and how to tell which one ran out when things get slow.

What eats memory

The short answer: not concurrent players. How much stuff exists in the world.

Palworld's bases keep running. A player logs off and their structures remain, their stationed Pals keep working, their production lines keep producing — all simulated in server memory. So usage tracks three things:

1. Total structures — every piece across every base on the server
2. Total Pals — working at bases, kept in pastures, stored in boxes
3. Explored terrain — the chunks that have been generated

The first two dominate, and they only go up. Somebody quits the game; their base doesn't disappear.

Which produces a counterintuitive result: a ten-person server that "usually only has three people on" uses far more than three players' worth. Player count sets your peak load; world size sets your baseline — and it's the baseline that eventually breaks the machine.

What eats CPU

Mostly Pal behavior simulation. Every Pal working at a base independently looks for a job, walks there, performs it, and tracks its own hunger — all server-side.

The key fact: the Palworld server leans on single-core performance, and extra cores help much less. This is the most common sizing mistake — at a given budget people pick many weak cores, then wonder why it stutters once the bases fill up.

The priority is clock speed over core count. Four fast cores beat eight slow ones for this game.

Sizing by group size

Assuming one mid-sized base per person, on a world that's been running a while but hasn't gone wild:

Disk gets overlooked: a save is a few hundred MB, and backups need several times that. Use an SSD — autosave writes those hundreds of MB at once, and on spinning disk the entire server visibly hitches for a second while it does. That happens every few minutes.

Bandwidth isn't the bottleneck. Palworld runs over UDP with modest per-player traffic; any normal cloud instance has enough. Latency matters more than bandwidth — pick a region close to your players.

Once the spec is settled, the full walkthrough from SteamCMD to your first login is the complete setup guide.

Leave room for the world to grow

Week-one usage is not steady-state usage. This is the most common sizing error.

Roughly: the same eight players might use 6 GB in their first week, and three or four times that after three months of everyone running two or three fully staffed bases. And memory does not come back down short of demolishing structures or starting a fresh world.

So size for month three, not for today. The price difference is usually small, while resizing mid-life means a migration and downtime.

Which one ran out

When it gets slow, identify the end first — the symptoms are quite distinct:

The first row is the serious one: when memory runs out the OS kills the process outright, and it may have been mid-save — which is exactly why backups matter more here than elsewhere (backups and restores).

The fourth row gets misdiagnosed as a network problem constantly. The test is simple: if the hitch is rhythmic and lines up with the autosave interval, it's disk, not network.

If you'd rather attack it from the settings side, BaseCampWorkerMaxNum and BaseCampMaxNum are the two most direct levers (every option explained).

Common questions

How much RAM for four players? 8 GB runs it, but gets tight as the world grows. If the group is in it for the long haul, going straight to 16 GB is the simpler choice.

Are more CPU cores better? No. The Palworld server leans on single-core performance; four fast cores beat eight slow ones.

Why does memory keep growing when hardly anyone is online? Memory tracks how much exists in the world — structures, bases, Pals — and all of it stays simulated in memory after players log off. It only goes up.

Not having to guess

Sizing is a guess you live with for months. Too small means everyone lags plus a migration; too large means paying monthly for headroom you never use. And you have to decide it at the moment you know least — on day one, with no idea what everyone will have built by month three.

A dedicated Palworld server from KeepWorlds comes sized to player count on your own machine, never shared with another world, so the performance you're quoted is the performance you get — it doesn't move because of a neighbor.