Palworld server performance and base limits

A Palworld server gets slower as its bases grow, not as its player count grows. Every working pal in every base camp is simulated all the time, whether anyone is nearby or not, and each one pathfinds, works, eats, sleeps and occasionally gets stuck. The levers that matter are in PalWorldSettings.ini: BaseCampMaxNumInGuild and BaseCampWorkerMaxNum (how many pals are working), BaseCampMaxNum (the server-wide camp total), PalSpawnNumRate (wild pals), and DropItemMaxNum (loose items). Measure before you change anything - the REST API reports the server's frame rate - and restart daily, because a long-running Palworld server degrades on its own. That is the summary. Below is the reasoning, the numbers, and the lag that settings will not fix.

The memory side of the same story - how many gigabytes a given world needs - is in Palworld server memory. This post is about the server feeling slow: pals rubber-banding, actions arriving late, bases that stall.

What lag on a Palworld server actually is#

Players say "lag" for three different problems, and only one of them is the server.

The server runs a simulation loop. Each pass through the loop - a frame - it updates every active pal, every player, every projectile and every base task, then sends the results to clients. When there is more work than fits in a frame, frames take longer and the server's frame rate drops. Clients receive updates less often and have to guess in between, which is the teleporting and rubber-banding everyone notices. That is server lag in the proper sense, and it is almost always caused by the amount of world being simulated, not by the network.

One player's bad connection looks similar from their side but is invisible to everyone else. Latency, jitter and packet loss is the guide to telling them apart; if only one person complains, start there.

Measuring the server's frame rate#

Do not tune by feel. The REST API has a metrics endpoint that returns the server's current frame rate and frame time alongside the player count and uptime:

$ curl -s -u admin:YOUR_ADMIN_PASSWORD http://203.0.113.10:8212/v1/api/metrics

{  "serverfps": 58,  "currentplayernum": 7,  "serverframetime": 17.2,  "maxplayernum": 16,  "uptime": 41820}

The fields you care about are serverfps and serverframetime (in milliseconds). Later builds have added more fields; the core ones have been stable. The REST API has to be enabled with RESTAPIEnabled=True and listens on RESTAPIPort, 8212 by default - Palworld admin commands and RCON covers turning it on and keeping it private.

What matters is not the absolute number but how it moves. Note the frame rate on a quiet evening with a fresh world, then again when everyone is on, then a week later at the same time. A server that holds its usual rate with the full group on is healthy. One whose rate falls every week as bases grow is telling you exactly where the problem is. A frame rate that drops sharply when people gather at one base and recovers when they leave points at that base.

Combine this with the CPU graph. A server at its CPU limit while the frame rate drops is CPU-bound; more CPU or less simulation will help. A server with spare CPU and a low frame rate is limited by its main thread, which is the more common case - most of the loop is single-threaded, so a faster core helps and more cores do not. CPU vs RAM for game servers and reading a server load graph explain how to read that.

Base camps and workers: the main cost#

A base camp is an area with a palbox. Pals assigned to it work - mining, logging, crafting, carrying, farming - and that work is simulated constantly. Three settings set how much of it exists.

Defaults have changed between versions, and the maximum allowed for BaseCampWorkerMaxNum has risen over time. DefaultPalWorldSettings.ini in your own install is the authoritative list.

The arithmetic is the whole argument. The number of working pals on a server is roughly guilds times camps per guild times workers per camp:

A server with 600 working pals is doing an enormous amount of work every frame regardless of how many people are online. The quickest improvement for a public server is usually BaseCampMaxNumInGuild=3 and BaseCampWorkerMaxNum=12: almost nobody notices, and the simulated pal count drops by more than a third.

Raising BaseCampWorkerMaxNum is the request you will get most often, and on a small private server it is fine - one guild with 20 or 25 workers per camp is well within what a server handles. On a public server, every guild gets the same allowance, so think in totals, not per guild.

Why some bases cost more than others#

Two bases with the same number of pals can have very different costs. Pals in Palworld path to their work, and the cost of pathfinding depends on the shape of the base.

• Multi-storey bases with stairs, ramps and narrow corridors make pathing expensive and make stuck pals common. A stuck pal tries again, and again, every frame.
• Work stations spread far apart inside the camp radius mean long walks with many path recalculations.
• Bases on uneven ground produce pals that fall off ledges and struggle to return.
• Overlapping or crowded camps where pals from different bases get in each other's way.

If the frame rate drops when players gather at one particular base, that base is a candidate. Ask its owner to simplify the layout: work stations on one level where possible, wide paths, stairs replaced with ramps, and the palbox near the centre. It is a better fix than any setting, and players are usually happy to do it once they understand why their pals keep getting stuck too.

Wild pals, items and the rest of the world#

Bases are the biggest cost on an established server, but not the only one.

Wild pal spawns. PalSpawnNumRate scales how many wild pals the world spawns; the default is 1.0. Lowering it to 0.8 or so reduces the number of pals the server simulates in active areas. Raising it makes the world feel busier and costs proportionally. It also affects capture and farming, so tell players before you change it.

Dropped items. DropItemMaxNum caps how many items lie on the ground at once, and DropItemAliveMaxHours sets how long each one lasts. On a busy server, dropped items accumulate quickly - from deaths, from full inventories, from pals - and each one is an object. Halving the cap rarely affects anyone and is close to free performance.

Raids. bEnableInvaderEnemy turns base raids on or off. A raid spawns a group of enemies at a base and is a short burst of extra simulation. On a server where several bases are raided at once, it shows up as a dip. Most groups keep raids on because they are part of the game; turning them off is an option if a server is struggling.

View distance. Later builds added ServerReplicatePawnCullDistance, which controls how far away the server sends other players and pals to each client. Lowering it reduces network and replication work; raising it makes far-off things visible earlier. Check whether your version has it before you add it.

Structure counts. Recent builds have a setting to cap structures (look for MaxBuildingLimitNum in your version's defaults). Every wall, floor and chest is an object in the save and in memory; a cap is the bluntest way to keep a public world from becoming a mega-base contest.

Restarts and slow degradation#

A Palworld server that is restarted daily performs better than one left up for a week, even with the same world. Over long uptimes memory grows, small simulation problems accumulate (pals stuck in walls, items that never despawned), and the frame rate drifts down. A restart clears all of that; the world reloads from its last save and everything starts fresh.

A daily restart at an hour nobody plays is normal practice for Palworld. Warn players first with Broadcast, save with Save, then restart. On RE:NODE, the Schedules tab runs that sequence on a cron expression - a broadcast, a wait, the save, a backup, and a restart - as ordered tasks, so nobody has to remember. Restart schedules that help covers the timing, and Palworld backups and world reset covers putting the backup in the same schedule.

If a server needs restarting more than once a day to stay playable, the world is too big for the server. That is a decision between more resources and less world, not a reason to restart every six hours.

Autosave hitches#

AutoSaveSpan sets how often the world is written to Level.sav, in seconds. Writing a large save takes time, and on a mature world it causes a visible hitch. The default is short - thirty seconds - which caps how much is lost in a crash but means frequent hitches on a big world. Raising it to 180 or 300 smooths play; the trade is up to that many seconds lost if the server stops uncleanly. On a stable server, the longer interval is usually the better trade.

Fast storage shortens the hitch but does not remove it, because the cost is partly serialising the world, not only writing it. RE:NODE runs on NVMe throughout, which helps the write half.

A tuning order that works#

When a server is slow, change things in this order and measure after each:

1. Restart it. If performance returns to normal and degrades again over days, add a daily restart and stop there.
2. Check memory. A server near its limit behaves badly before it runs out. If memory is the issue, read Palworld server memory.
3. Count bases and workers. Ask how many camps and workers exist. If it is in the hundreds, lower BaseCampMaxNumInGuild and BaseCampWorkerMaxNum.
4. Find the expensive base. Watch the frame rate as players move around. Simplify the base that drags it down.
5. Trim the world. DropItemMaxNum, PalSpawnNumRate, AutoResetGuildNoOnlinePlayers for abandoned guilds.
6. Then look at resources. If the server is consistently at its CPU limit after all of that, it needs more CPU. On RE:NODE, changing plan raises the limit on the same server without rebuilding it - see when to upgrade your plan.

Troubleshooting#

Pals teleport and doors open late for everyone. Server frame rate. Check the metrics endpoint and the CPU graph, then work through the tuning order.

Performance was fine for weeks and slowly got worse. World growth. More bases, more workers, a larger save. Restart daily and trim limits.

One base is unplayable, the rest of the world is fine. That base's layout. Simplify it, and check for stuck pals.

A hitch every thirty seconds. AutoSaveSpan at its default on a large world. Raise it.

The server is fast after a restart and slow by evening. Uptime degradation. Daily restarts, and check memory growth across the day.

Lowering limits did nothing. Existing camps and workers above the new limits remain until they are removed. The effect builds up as old bases go.

FAQ#

How many base camps can a Palworld server handle?

It depends on the workers per camp and the server's CPU. Think in total working pals rather than camps: a hundred or two is comfortable on a mid-sized server, several hundred is where frame rates start to suffer.

Does lowering BaseCampWorkerMaxNum remove existing pals?

No. Pals already working stay; nobody can assign new ones beyond the limit. The full effect appears as bases are rebuilt or abandoned.

Why does my Palworld server lag with only a few players?

Because the cost is the world, not the players. A few players with many large bases can load a server more than a full server of new players.

Will more CPU cores make a Palworld server faster?

Only up to a point. Most of the simulation runs on one main thread, so a faster core helps more than extra cores. The multithreading launch flags help use what extra cores there are.

How often should I restart a Palworld server?

Daily is normal. It clears accumulated problems and memory growth. If the server needs restarting more often to stay playable, it is undersized for the world.