Palworld Server Memory Leak: Why RAM Climbs, How to Fix It

The typical life of a Palworld dedicated server goes like this: day one is smooth, a week in it stutters now and then, in week two everyone drops at 3am, the drops get more frequent, and one morning the save won't load. That isn't a tuning problem. The server has a known memory leak that has never been fixed: the process's memory only goes up, it creeps toward the physical limit the longer it runs, and eventually the OS kills it.

This covers how it happens, which settings make it worse, why adding RAM doesn't cure it, and how to automate the only thing that actually works — restarting on a schedule. If you first want to check the machine is big enough at all, start with server requirements.

Confirm it is this problem

Three signals together are a near-certain diagnosis:

That last one is the damaging one: the process may be mid-save when the OS kills it, and a half-written Level.sav only reveals itself on the next start. Which is why the leak and backups belong in the same conversation.

Where the memory goes

A Palworld server's memory has four parts, and three of them only grow:

1. Base footprint. Since 1.0 a cold start sits around 4 GB. That's the floor.
2. Players online. View distance and explored area, roughly 1.5 GB per player. Some of it comes back after logout, not all.
3. What has piled up in the world. Bases, structures, working Pals, dropped items — all of it stays simulated in memory after players log off. This is the big slice and it only grows: people who quit don't take their bases with them.
4. Leak residue. What the engine fails to reclaim, growing linearly with uptime. Even a world where nothing happens creeps upward.

The first three decide how much RAM you need. The fourth decides how often you must restart. Keep those two questions apart and the rest of the decisions get easy.

1.0 made this heavier than Early Access: offshore bases brought new pathfinding for swimming and flying Pals, Sky Islands and the World Tree are extra loaded zones, and the revamped raids spawn more entities at once. A world that lived on 8 GB before 1.0 should now be budgeted at 16 GB.

Settings that accelerate the leak

Four options map directly onto leak speed, all inside that one line in PalWorldSettings.ini (how to edit it safely is in every option explained):

The first row deserves a sentence of its own. Turning off bEnableInvaderEnemy only disables the scripted base raids; wild Pals still wander into your base, PvP is untouched. For a group that plays irregularly, raids mostly fire while nobody is online and you come back to rubble — most people don't miss them, and the trade is half your memory headroom back.

Why more RAM doesn't cure it

This is the most common misdiagnosis. Going from 16 GB to 32 GB doesn't get you "it stopped crashing." It gets you "it crashes every six days instead of every three." The leak fills whatever you give it; it's only a matter of time.

What RAM buys is longer gaps between restarts, and that has real value — it's what decides whether the restart can be one 4am event rather than one every four hours. But it doesn't replace the restart.

And a few things not to do:

• Don't disable bIsUseBackupSaveData. Backups aren't the leak; turning them off just removes a way back on the day it crashes.
• Don't set ServerReplicatePawnCullDistance below 5000. That's the official minimum for Pal sync distance; below it players see frozen Pals.
• Don't run two Palworld servers on one machine. Two leaks stacked hit OOM twice as fast.

How often to restart

By machine RAM and whether raids are on — these are the ranges that hold up in practice:

For a regular group, the practical answer is simpler: 16 GB or more, raids off, one restart a day in the small hours. On that combination the leak doesn't reach the danger line within a day, and a 4am restart is invisible to almost everyone. Public servers with people on around the clock are the ones that need it every few hours.

Checking whether your interval is enough is easy: look at memory use right before the restart and see how far it is from the physical limit. Under 20% headroom means shorten the interval, or add RAM to stretch it.

Restarting without losing the save

Just killing the process manufactures a crash every day. A proper restart is four steps: announce → force a save → stop → start, all through the official REST API (RCON is deprecated — don't build new scripts on it).

First enable the API in PalWorldSettings.ini, and only on localhost:

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="a-long-password"

Authentication is HTTP Basic: the username is always admin, the password is AdminPassword. The developers state plainly that this API isn't designed to face the internet, so don't open 8212 in the firewall.

A Linux script you can use as-is:

#!/bin/bash
# /home/palserver/restart.sh — announce, save, restart
PW='a-long-password'
API='http://127.0.0.1:8212/v1/api'

curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Server restarts in 5 minutes for maintenance"}'
sleep 240
curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Saving and restarting in 60 seconds"}'
sleep 60
curl -s -u "admin:$PW" -X POST "$API/save"
sleep 10
sudo systemctl restart palworld

In cron, every day at 4am:

0 4 * * * /home/palserver/restart.sh >> /home/palserver/restart.log 2>&1

This assumes the server runs as a systemd service per the setup guide. Restart=on-failure only handles bringing it back after a crash; it does nothing about memory creep — you need both.

Windows is the same idea: Invoke-RestMethod in PowerShell to hit announce and save, Stop-Process on PalServer-Win64-Shipping, start PalServer.exe again, and hand the script to Task Scheduler for a daily run.

Fold updates into the same restart

When the game updates, a server on the old build locks everyone out. Since you're stopping once a day anyway, checking the version on every start is free:

# add to the [Service] section of palworld.service
ExecStartPre=/usr/games/steamcmd +force_install_dir /home/palserver/palworld +login anonymous +app_update 2394010 validate +quit

Each start validates the install and picks up any patch. It costs a minute or two on startup and buys "the server is already on the new build the morning a patch ships." Keep the backup from before the update — save formats occasionally change with versions.

Common questions

Why does a Palworld server's memory keep growing?

Three things stack: bases, Pals and dropped items stay simulated in memory after players log off and only accumulate; the engine has a known leak it never reclaims; and each base raid leaves behind entities that don't get cleaned up. The first two decide how much RAM you need; the last one you can simply switch off.

What do I lose by turning off raids?

Only the scripted base raids. Wild Pals wandering in, PvP and bosses are all unaffected. In return the same world uses roughly half the memory.

How often should a Palworld server restart?

With 16 GB or more and raids off, once a day in the small hours is enough; on 8 GB or with raids on, every 2–4 hours. The test is how much headroom is left right before the restart — under a fifth means shorten the interval.

Will more RAM stop my Palworld server crashing?

Not on its own. The leak fills any amount of memory; more RAM just spaces the crashes out. Its value is letting you restart once at 4am instead of every few hours, but the restart itself can't be skipped.

On hosting this is a switch

The hard part of everything above isn't any single step. It's that it has to keep running correctly with nobody watching: someone writes the script, someone holds the password, someone checks cron, someone gets up when it crashes. It works the first week; three months later nobody remembers whether it's still there.

On a dedicated Palworld server from KeepWorlds these collapse into a few controls in the Console: Daily scheduled restart is a checkbox and a time — tick Restart automatically every day, pick a quiet hour, done; a crashed process is brought back automatically; the save is backed up on a schedule, with a forced save through the API before each one; and raids, workers per base and the rest are fields in the game config form, no ini involved. What each of those options does is in every option explained.