Palworld 1.0 Server Requirements: RAM and CPU

Palworld's server asks more of the hardware than the game's art style suggests, it asks in a way most games don't, and 1.0 raised the bar again. 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, what 1.0 changed, what to plan for, 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. Broken down, usage has four parts:

The first three decide how much RAM a world needs. The last decides how often a restart pays off: on a busy server we run that restarts daily, a typical day added 0.5–1.5 GB and the daily peak stayed between 3.3 and 4.5 GB. That part is covered in keeping a Palworld server running 24/7.

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.

Why 1.0 is heavier

Almost everything 1.0 added is computation that lives on the server: offshore bases brought new pathfinding for swimming and flying Pals, Sky Islands and the World Tree are additional loaded zones, the revamped raids spawn more entities at once, and automated defenses like drone barriers run logic whether anyone is watching or not.

The upshot: the same world needs noticeably more memory on 1.0 than it did in Early Access. For a machine you set up yourself, the official dedicated server requirements are the reference: they list 16 GB and recommend 32 GB or more. Where a particular world actually lands depends far more on what has been built in it than on how many people are online, which is why there's no RAM-per-headcount table below. If you'd rather put numbers on your own world, the Palworld server RAM calculator asks what's in it — bases, working Pals, how long it's been going — and tells you which of those two official figures you're sizing against.

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 on the server's main thread.

The key fact: the Palworld server leans on single-core performance, and extra cores help much less. Physics, pathfinding, combat resolution and state sync all sit on the main thread; extra cores only offload networking and async loading. 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 cores at 3.5 GHz or better beat eight at 2.5 GHz; for a large server, what matters is whether boost clocks reach 4.0 GHz.

What to plan for

For a machine you set up yourself, in the order people get it wrong:

• Memory: start from the official figures above, then size for the world you'll have in month three, not the one you have today — see the next section.
• CPU: clock speed first. More players and more bases all land on the same main thread.
• Disk: an SSD, with room for more than the server itself.
• Bandwidth: rarely the limit. Latency is.

Disk gets overlooked: the server itself is about 5 GB (4.6 GB installed as of v1.0.5), a save is a few hundred MB, and backup history needs several times that. Use an SSD — autosave writes every few dozen seconds, and on spinning disk the entire server visibly hitches while it does. That never stops happening.

Bandwidth isn't the bottleneck. Palworld runs over UDP with modest per-player traffic: 10 Mbps of upload covers four players, 20–50 Mbps covers sixteen. Latency matters more than bandwidth — pick a region close to your players.

Once the machine 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.

The same eight players use a good deal more memory three months in, once everyone runs two or three fully staffed bases, than they did in their first week. And that baseline does not come back down short of demolishing structures or starting a fresh world; a restart only clears what built up since the last one.

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 second row is the one most often misread as "the machine is too small." If a restart makes it good again and the peak still leaves room, it isn't a sizing problem: a regular restart is the fix, covered in keeping a Palworld server running 24/7. If the peak is pressing against the limit, more RAM is.

The fifth 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, bEnableInvaderEnemy, BaseCampWorkerMaxNum and BaseCampMaxNum are the three most direct levers (every option explained). And if it isn't settled yet that the server is the problem at all, start one step earlier with server lag: find the cause first.

Common questions

How much RAM does a Palworld 1.0 server need?

For a machine you set up yourself, the official requirements are the reference: they list 16 GB and recommend 32 GB or more. What a given world really uses depends on how much has been built in it — bases, working Pals, raids — more than on how many people are online, and it keeps climbing until a restart. 1.0 is a step heavier than Early Access, so rules of thumb from before 1.0 no longer hold.

Are more CPU cores better?

No. Physics, pathfinding and state sync all run on the server's main thread, so single-core performance is what counts. Four fast cores beat eight slow ones; for a large server, look at whether boost clocks reach 4.0 GHz.

Why does memory keep growing when hardly anyone is online?

Mostly because memory tracks how much exists in the world — structures, bases, Pals — and all of it stays simulated after players log off. What players load while they're on adds to it, and a restart puts that part back: on a busy server we run, a quiet day stayed flat while a busy one added 0.5–1.5 GB.

How much bandwidth does a Palworld server need?

It isn't the bottleneck. Palworld runs over UDP with modest per-player traffic: 10 Mbps upload covers four players, 20–50 Mbps covers sixteen, and any normal VPS has that. Latency matters more — pick a region near your players.

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.

With Palworld server hosting from KeepWorlds, you pick the plan by how many players are online at once, and the server runs on a machine of its own, never shared with another world. The memory creep is handled by the daily scheduled restart in the Console rather than a script you maintain, and raids and the other settings that drive memory are fields in the game settings form.