08/23/2026

Palworld Server Crashing? Memory Leak, RAM & 1.0 (2026)

• Palworld
• Guides

The server runs perfectly for two hours, starts stuttering, then dies. Everyone's first thought is a memory leak. Most of the time it isn't — and since Palworld hit full release 1.0, one of the most common causes is advice you'll find in almost every older guide. Here's how to tell the real problem from guesswork, in order.

Measure first, guess later

The Palworld server has a REST API with a /metrics endpoint that returns serverfps, serverframetime, currentplayernum, uptime and basecampnum. That's the difference between "I think memory is leaking" and "I know what's happening".

How to read it:

• serverframetime climbs as uptime climbs while the player count stays flat — that's load growing over time. This is what people call a memory leak.
• serverframetime only spikes when the group logs in or someone builds a fifth base — that's not a leak, that's plain load. The fix is in the settings, not in a restart.
• basecampnum keeps growing — every base costs you permanently, even with nobody in it. This is the most common silent cause.

Without this step everything else is guessing. Take two or three readings across a day and you have your answer.

The three startup flags you should delete in 2026

This is the part most guides still get wrong, which is why it goes first.

Up to version 0.7.3, the official docs said this about -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS, word for word: "Improves performance in multi-threaded CPU environments", along with a whole section on tuning thread counts.

In the 1.0 docs that section is gone, and the table now reads: "In v1.0 and later, leaving this parameter unset may improve performance." Same flags, reversed recommendation.

If you set your server up before July 2026 — or followed any guide older than that — you're probably still carrying them. Take them out and let the server run for a day or two before you change anything else.

• Windows: PalServer.exe -port=8211
• Linux: ./PalServer.sh -port=8211

The same goes for -NumberOfWorkerThreadsServer: that flag leaned on a section that no longer exists. If you don't know exactly why you need it, you don't need it.

RAM: what Pocketpair actually says

The official requirements are blunt: 16 GB is the minimum, more than 32 GB is recommended, and on 8 GB the server is bootable but that "increases the possibility of server crashes due to out of memory".

That explains a large share of memory-leak reports: a server that runs out of memory and dies looks identical to one that leaks. If you're on 8 GB you don't have a leak — you're short on RAM. How much you actually need for your group, I broke down in a separate post.

My own experience, honestly: I ran my own 16 GB server playing solo, three to four days without a restart, no trouble. I didn't measure how many GB it held, so I won't claim it. But if there were a hard leak hitting everyone, that server wouldn't have lasted a single day.

The settings that actually create load

In the configuration docs Pocketpair itself notes which settings raise load. Those are the first place to look when serverframetime rises with player and base count:

• BaseCampMaxNumInGuild — bases per guild, default 4, maximum 10. The docs say explicitly that raising it increases processing load. This is the one people push straight to 10, then wonder why the server stutters.
• BaseCampWorkerMaxNum — Pals per base, max 50. Every Pal in a base is doing something, and it's computed continuously.
• ServerReplicatePawnCullDistance — the distance at which Pals sync to players, from 5000 to 15000. A smaller value means less work per tick.
• bIsUseBackupSaveData — world backups. Worth having, but the docs note it increases disk load.

The rest of the settings — rates, difficulty, PvP — have nothing to do with this problem; I went through those in the server settings post.

The scheduled restart — and how not to do it

A daily restart is the cheapest cure for load that grows over time. Mine run once a day around 5am — nobody gets kicked at that hour, here or in the Balkans. If serverframetime climbs before 24 hours are up, move to 12. That ties the decision to a measurement instead of a ritual.

More important than when is how. The correct order, per the official commands:

• /Save — save the world first. Over REST that's POST /save.
• /Shutdown [seconds] [message] — shuts down with a countdown and a message to players. Over REST that's POST /shutdown with waittime and message.
• Never /DoExit for a scheduled restart — that's a force stop.

A cron job that simply kills the process is how "my server is slow" becomes "my world is gone". Pocketpair separately warns that slow storage can corrupt save data — and a hard kill mid-save is exactly that scenario.

Is it even a memory leak?

Honestly: Pocketpair has never confirmed a memory leak in any patch note. What they have shipped, in the five weeks since 1.0: versions 1.0.1, 1.0.2, 1.0.2.101103 and 1.0.3 — carrying a long run of fixes aimed squarely at dedicated servers, including crashes and mass disconnects during boss fights, Pals vibrating on the client, and fast travel triggering on its own.

So: servers really were unstable after 1.0, patches really are landing fast, but "memory leak" is a name the community gave a cluster of symptoms, not an officially acknowledged bug. Which is why you measure first, strip the old flags second, then check RAM and settings. In that order. Nine times out of ten you'll stop before the end of the list.

Where to run all this

Everything above you can do yourself — that's why it's written down here. But if you'd rather not babysit startup flags, restarts and versions: on mcbalkan the Palworld servers start at 16 GB, which is exactly what Pocketpair asks for, with an automatic daily restart and backups already set up. And when something breaks you talk directly to me — no ticket queue, no bot. See the Palworld hosting.