Palworld Server Keeps Crashing: How to Diagnose and Fix It

A Palworld dedicated server that runs fine for two hours and then freezes, rubber-bands and dies is almost never a bad host or a bad plan. It is the dedicated server binary leaking memory until the machine runs out of it. But there are two other failures that are worse, because the server does not crash at all — it keeps running while nobody can play, and every monitoring signal a host can see says it is fine. This guide covers all three: how to tell them apart, what to change so they stop, and what it takes to keep a Palworld server online around the clock.

The short version

Palworld has a long-standing memory leak in its dedicated server build. RAM usage climbs steadily for as long as the server is up, roughly in proportion to how many players are online and how many Pals exist in the world, and it is never released. Eventually the process exhausts the RAM it was given and the operating system kills it. From the outside that looks like a random crash, which is why so many people blame their host first.

Server operators report the shape of it consistently: a four-player world with around 80 Pals typically grows from about 3 GB to over 8 GB inside four hours, and a busy 16-player community server can reach 12 GB in half an hour. Those numbers vary with your world, but the pattern does not. If your crashes arrive on a rough schedule rather than at random, that is the leak.

The two failures that do not look like a crash

A crash is the easy case: the process dies, and anything watching it notices. The two failures that generate the most confused support tickets leave the process alive and every health check passing. We diagnosed both from 22 hours of one-minute samples off a customer's 16GB server, and they look like this:

Neither of these is the memory leak. The world-unload failure happened three times in two hours on a server using under 2.3GB, so it is not the leak and not the RAM limit. What makes them expensive is that the usual health check — is the game process running — passes in both states, so nothing restarts the server and it can sit there dead for hours while you are asleep.

Confirm it is memory before you change anything

Open the resource graph in your dashboard and watch RAM across a session. The memory leak has a signature that is hard to mistake:

• RAM climbs in a near-straight line from the moment the server starts and never drops back after players leave.
• The crash happens when that line reaches the ceiling of your plan, not at a particular in-game event.
• There is no useful crash message. The process simply disappears, because the operating system killed it rather than the game choosing to exit.
• Restarting the server fixes it completely, for another few hours.

If instead your server dies at the same moment every single time, or fails within seconds of starting, skip to the last section. Those are different problems with different fixes.

Fix 1: restart on a schedule

This is the unglamorous answer and it is also the effective one. Because the leak is linear and a restart clears all of it, a scheduled restart resets the clock before the ceiling is ever reached. Experienced operators typically restart every three to six hours on a busy public server, and once or twice a day on a small private one.

A Palworld restart takes about a minute and the world is saved first, so the cost to players is small. Pick a slot when your group is usually offline, announce it in Discord, and the problem stops being a problem. On Flux you can restart from the dashboard in one click, and because a restart also picks up any pending game update it doubles as your patch routine.

One trap worth knowing about if you self-host or use another provider: the scheduled restart script in the standard Palworld server image asks the server to save first, and refuses to shut down if that save fails. On a server that is leaking, frozen or worldless — which is to say, the only kind of server a nightly restart exists for — the save is exactly what fails. So the restart silently does nothing on precisely the nights it was needed, and the logs show it as having run. Check that yours actually restarted rather than assuming it did.

Fix 2: disable Pal invaders

Raids spawn waves of hostile Pals that the server keeps in memory long after the raid is over. Turning them off is the closest thing Palworld has to a community-agreed workaround for the leak, and operators consistently report RAM climbing at roughly half the previous rate afterwards.

In PalWorldSettings.ini set bEnableInvaderEnemy=False and restart. You lose base raids, which some groups will miss and many will not, and in exchange you roughly double the time between restarts. Edit the file from the dashboard config editor; there is no need to open a terminal.

Fix 3: cap the things that grow

The leak scales with how much world there is to hold in memory, so limiting how much your players can create slows it down. Two settings do most of the work:

A guild that has parked 50 working Pals in each of several bases is holding a large amount of persistent simulation in RAM, and every one of those Pals contributes to the leak. Capping worker counts is not just a memory fix either: it is the single biggest lever on server CPU load in Palworld, so it usually improves lag at the same time.

Fix 4: give it headroom

None of the above stops the leak, they only slow it. The remaining variable is how much room the server has before it hits the ceiling, and that is your plan size. If you are running 16 players on 8 GB you are asking the leak to kill you inside an hour no matter how well you configure the world.

Those tiers already assume a leaking server rather than a theoretical idle one. If you are crashing on the tier that matches your player count, the usual cause is a very built-up world, and the two settings above will do more for you than the next plan up. If you are one tier below your player count, move up. Scaling RAM on Flux does not touch your world save.

How to keep a Palworld server online 24/7

Everything above slows the failures down. None of it makes a server that has already failed come back, and that is the difference between a server that is up most of the time and one that is up all of the time. Something has to notice and act while you are asleep.

That is the gap our Palworld server image closes, and it is why we build our own rather than shipping the standard one. It checks the server every minute, from inside the container, on the things a player would actually notice: whether the network socket is draining, whether the admin API answers, whether the world is loaded and ticking, and whether the save file is still on disk. If the answer is no it restarts the server. There is nothing to enable and no setting to find.

The restraint matters as much as the trigger, because a monitor that restarts healthy servers is worse than none:

• It needs the same verdict three times in a row, a minute apart, before it acts — one bad sample is not a fault.
• It never acts on a server it has not yet seen working, and never during the first minutes after boot. Loading a large world takes time, and a restart loop does not help a server that came up broken.
• It announces the restart in game and counts down 60 seconds, with reminders at 30 and 10 seconds, then takes one last sample. A server that recovered during the countdown is left alone and the countdown is called off out loud.
• It never saves. In every state that gets it this far the world in memory is already gone or frozen, and asking a broken server to save risks writing that emptiness over your last good save. What a restart costs you is the minutes since the last autosave — which were already lost when the fault happened.

The nightly restart on this image is fixed too. It warns your players, saves only if the world is still loaded and actually ticking, asks the server to shut down, and then stops asking — after a grace period it ends the process, and a fresh server is up seconds later. It never silently skips.

One thing worth doing yourself: set an admin password in the Server Settings tab. The socket and save-file checks work regardless, but the checks that catch an unloaded world talk to the server's admin API, and a server with no password set refuses those calls. We deliberately never treat a rejected call as a dead server — doing so would restart healthy worlds every few minutes — so the effect of leaving it blank is quieter protection, not louder.

When it is not the memory leak

It crashes seconds after starting, right after a game update

Pocketpair ships client and server updates together, and a server still on the previous build will refuse connections or fall over as soon as an updated client joins. Update the server as soon as the client patch lands rather than waiting for a report from your players. On Flux a restart pulls the current image, so this is one click.

It crashes at the same point every time

A crash that reproduces exactly, for instance whenever a specific player logs in or whenever the world reaches a particular area, points at a corrupted save rather than at memory. Restore the most recent backup taken before the behaviour started. Keep backups on a schedule for exactly this reason: a save you cannot roll back is a save you can lose.

It never starts at all

If the server has never come up, this is a configuration or port problem and not a crash. Check that UDP 8211 is the port your players are dialling and that PalWorldSettings.ini is valid, since one malformed line will stop the file being read. The setup guide walks through both.

A checklist you can work through

1. Work out which failure you have. A straight climb in RAM to the ceiling is the leak. Online but unjoinable is a stall. Joinable but no world is an unloaded world. They need different answers.
2. Set bEnableInvaderEnemy=False in PalWorldSettings.ini and restart.
3. Cap BaseCampWorkerMaxNum to something sane for your group, and cap BaseCampMaxNum to your player count.
4. Schedule a restart every three to six hours on a busy server, or daily on a private one.
5. Confirm your plan RAM matches your player count, and move up a tier if it does not.
6. Keep automatic backups on, so a corrupted save is an inconvenience and not the end of the world.
7. Set an admin password, so the checks that catch an unloaded world can reach your server.
8. Make sure something restarts the server when it stops responding, not only when it dies. On Flux that is built into the server image.

Work through it in that order and the great majority of Palworld crash reports stop. What remains is a game engine limitation nobody can patch for you — so the question stops being how to prevent every failure and becomes how quickly the server comes back from one.