Updating a Palworld Server Without Losing Anything

Why this isn't automatic

If you set up your dedicated server the way most guides walk through (including ours), the startup script that launches the game every time it boots doesn't touch the actual game files at all — it just writes the config and launches the binary that's already sitting there. Updating means running SteamCMD's update command against that install directory directly, whether that's through your panel's "reinstall" button or by hand.

That's actually a good thing once you know it — it means an update is a deliberate, controllable action instead of something that silently happens on a random restart while people are playing.

The actual command

Palworld's dedicated server has its own Steam App ID, separate from the game client. The update command, wherever you run it from:

steamcmd.sh +force_install_dir <your-install-dir> +login anonymous +app_update 2394010 +quit

Anonymous login is enough — this isn't a purchased game tied to an account, the dedicated server binary is free to download for anyone.

Two gotchas that'll cost you an hour if you don't know them

Don't add validate as a reflex

Every guide (including the official docs) shows the update command with a trailing validate flag — it forces SteamCMD to checksum every file, which is the textbook-correct thing to do for a from-scratch install. On our box, adding it hit a well-documented SteamCMD bug three times in a row: it would fully re-download SteamCMD itself, then hang on Update state (0x0): Timed out waiting for update to start, bailing during the extra validation pass specifically. Dropping validate entirely succeeded on the very next attempt.

"Already up to date" isn't always true

We hit this the same day Palworld shipped a patch that was already live for every player's game client — SteamCMD reported the dedicated server as fully up to date, and the server kept reporting its old version after a restart. Turns out Pocketpair's dedicated-server depot can lag the client patch by anywhere from a few hours to over a day. It's a known, recurring pattern for this game specifically.

The safe procedure

• Confirm nobody's currently online (your REST API's players endpoint, or whatever your panel shows)
• Stop the server fully
• Snapshot the whole install directory (see below — this is the part most guides skip)
• Run the update, no validate
• Start the server back up
• Verify it actually boots — not just "the process didn't immediately die," check for the real boot log line
• Confirm the new version via the REST API, cross-checked against real patch notes

The rollback snapshot (the part that costs almost nothing)

Steam doesn't let you cleanly roll back to an arbitrary past dedicated-server build — old versions aren't kept around for anonymous download. That's fine, because that's not actually what you need for safety here.

What you actually want is: if the update or the restart afterward goes wrong, get back to exactly where you were a minute ago — world save and all. On Linux, that's a hardlink clone of the whole install directory, taken right before you touch anything:

cp -al palworld palworld.pre-update-snapshot

Because it's hardlinked, this costs almost no extra disk — only files that actually change during the update end up genuinely duplicated. If anything goes wrong, delete the failed live directory, move the snapshot back into its place, and start the server. From the outside, it should look like the update attempt never happened.

Only delete the snapshot once you're actually confident the new version is stable — ideally after someone's logged in and played for a bit, not immediately after the boot check passes.