Palworld server settings that cut RAM use the most

Palworld server settings decide whether a dedicated world runs smoothly on modest hardware or chokes a powerful machine once a base fills up with Pals. Four settings groups matter most: Pal density per base, overall spawn rates, dropped item limits, and save frequency. Adjust them in PalWorldSettings.ini and the same world footprint uses noticeably less RAM and CPU without feeling empty to players.

What actually drives RAM and CPU load on a Palworld world

Palworld keeps simulating entities even when no player is standing next to them. Every Pal assigned to a base keeps running its work logic, pathfinding, and animation state as long as the base chunk stays loaded. That is different from games that freeze distant areas entirely.

CPU load comes mostly from Pal AI: pathfinding calculations, task assignment at bases, and combat or breeding checks. RAM load comes from loaded entities, dropped items sitting on the ground, and the growing save data kept in memory between writes.

Doubling the number of active Pals does not double CPU use exactly, but it gets close once several guilds run large bases at the same time. That is why the Pal cap per base is the single highest leverage setting available.

If you are setting up the machine itself rather than just the config file, a plan built around Palworld server hosting already ships with enough headroom that most of these tweaks become optional rather than mandatory.

The Palworld server settings with the biggest memory impact

PalWorldSettings.ini lives under Pal/Saved/Config/LinuxServer/ (or WindowsServer on a Windows host). Every option sits on a single line inside the OptionSettings=() block. Editing it requires a full restart to apply.

Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

Six settings consistently show up as the biggest drivers of RAM and CPU on a dedicated world, according to the official dedicated server documentation:

1. BaseCampWorkerMaxNum, the number of Pals allowed to work inside a single base.
2. MaxBuildingLimitNum, the total structures a guild can place.
3. PalSpawnNumRate, the global multiplier for wild Pal spawns across the map.
4. DropItemMaxNum, the cap on items lying on the ground at once.
5. DropItemAliveMaxHours, how long dropped items stay loaded before despawning.
6. AutoSaveSpan, how often the world writes its state to disk.

None of these need to hit zero. The goal is trimming the ceiling, not starving the world of content.

Reading the current values before changing anything

Open the file over SSH or through a WebFTP editor and note the existing numbers before touching them. A rollback is much faster when the original line is saved somewhere.

cat Pal/Saved/Config/LinuxServer/PalWorldSettings.ini | grep -i "BaseCampWorkerMaxNum\|MaxBuildingLimitNum\|PalSpawnNumRate\|DropItemMaxNum\|AutoSaveSpan"

On a Linux VPS this is a plain text edit with nano or vim. Keep a backup copy of the file before saving, since a missing comma or quote breaks the whole config on next launch.

Limiting Pals per base without breaking progression

BaseCampWorkerMaxNum defaults to a value high enough to let late-game bases run with a full roster of working Pals. Each of those Pals keeps a pathing and task-state loop active, which is pure CPU overhead whether or not a player watches the base.

Dropping it from the default down to 10 or 8 still lets most guilds run efficient production lines. Players notice a smaller cap mainly on very large late-game bases, not on starter camps, so the complaint rate stays low relative to the CPU saved.

Setting	Typical default	Lean value	Effect
BaseCampWorkerMaxNum	15	8 to 10	Fewer active Pal AI loops per base
MaxBuildingLimitNum	Unlimited (-1)	100 to 150 per guild	Caps structures kept loaded in memory

MaxBuildingLimitNum works alongside the Pal cap. Unlimited building placement means unlimited furniture, storage boxes, and production machines staying resident in RAM. Setting a reasonable ceiling per guild keeps base sprawl in check without blocking normal building.

Tuning spawn rates and item density across the map

PalSpawnNumRate controls how many wild Pals exist across the entire map at once, independent of what players have captured. A value of 1.0 is the baseline; dropping it toward 0.7 or 0.6 thins out overlapping spawn points in heavily explored zones while keeping rare Pals reachable.

Lower spawn density means fewer active AI entities for the server to track between player sightings, which is a direct CPU saving that scales with map traversal and player count.

DropItemMaxNum and DropItemAliveMaxHours target a different problem: clutter. Combat drops, farming byproducts, and dismantled structures pile up on the ground and each one is a tracked object in memory.

• Lower DropItemMaxNum toward 1500 to 2000 on busy worlds instead of the much higher default.
• Shorten DropItemAliveMaxHours so abandoned drops clear faster, especially near raid sites.
• Consider disabling extra dung or waste item spawns if the community rarely uses them for fertilizer.

Save frequency and world size on disk

AutoSaveSpan sets how often the world writes its full state to disk, in seconds. Frequent saves protect against data loss but also create short CPU and I/O spikes as the engine serializes every base, Pal, and inventory at once.

Stretching the interval from a short default toward 900 seconds (15 minutes) cuts the number of daily save spikes without meaningfully increasing what a crash would cost in lost progress, since most sessions last well under that window anyway.

Automatic snapshots taken outside the game process, separate from AutoSaveSpan, still matter for disaster recovery. Keep both: a longer in-game interval for day to day performance, and scheduled external backups for actual protection against corruption.

A lean PalWorldSettings.ini example

The block below combines the six settings covered above into one coherent example. It is a starting point, not a universal answer: a ten-player community and a solo world should not use identical numbers.

OptionSettings=(
Difficulty=None,
DayTimeSpeedRate=1.000000,
NightTimeSpeedRate=1.000000,
PalSpawnNumRate=0.700000,
DropItemMaxNum=1800,
DropItemAliveMaxHours=2.000000,
BaseCampWorkerMaxNum=9,
MaxBuildingLimitNum=120,
AutoSaveSpan=900.000000,
ServerPlayerMaxNum=16)

Restart the process after saving so the new values load cleanly, and check the server log for parsing errors before inviting players back in.

systemctl restart palworld-server
journalctl -u palworld-server -n 50 --no-pager

Checking that the changes actually worked

Numbers in a config file mean nothing until they show up in actual resource use. On a Linux machine, top or htop gives an immediate read on CPU percentage and resident memory for the game process after a few hours of normal play.

htop
# look for the Palworld server process
# compare %CPU and RES before and after the edit

Most control panels built on Pterodactyl VPS expose the same data as live graphs, which is faster for day to day monitoring than SSHing in every time. Track the trend over a full weekend of play rather than a five minute sample, since base-heavy sessions load the server very differently from early exploration.

Conclusion

Start with BaseCampWorkerMaxNum and AutoSaveSpan: they give the fastest, most visible drop in CPU and RAM with the least player-facing impact. Only touch spawn rates and item caps afterward, in small increments, and recheck resource use after each change instead of adjusting all six settings at once.

FAQ

Will lowering PalSpawnNumRate make rare Pals harder to find?

A moderate reduction, from 1.0 down to around 0.7, mainly removes duplicate spawns in areas players have already cleared. Rare Pal spawn points are usually tied to specific zones rather than pure density, so a small cut rarely makes them noticeably harder to locate, while a drastic cut toward 0.3 or lower will.

Do I need to wipe my save to change these settings?

No. PalWorldSettings.ini is read fresh on every restart and applies to the existing save file. Changing Pal caps, spawn rates, or save intervals does not reset bases, inventories, or captured Pals, since those live in the separate world save data rather than in the settings file itself.

How much more RAM does a heavily modded Palworld world need?

Mods that add new Pals, structures, or recipes increase the baseline memory footprint beyond vanilla, often noticeably once several content mods run together. The settings covered here still apply and often matter more on a modded world, since extra content multiplies the entity count that each setting is designed to cap.