How to Update a Palworld Dedicated Server

Steam keeps your Palworld client current. Nobody keeps your dedicated server current. So patch day always looks the same: a server that was fine yesterday locks everyone out, the connect attempt hangs longer than usual, and everyone lands back on the title screen. This is how to update a Palworld dedicated server in the order that keeps the save. If the server doesn't exist yet, start with the setup guide.

What a version mismatch actually looks like

It doesn't arrive as a helpful error. That's why the host's first suspicion is usually ports or the firewall, when the real cause is a build number.

That last row is the dividing line. Everyone at once means version, one or two people means something on their end. In the days right after a patch ships, the first case dominates.

Confirming it takes two readings: the version in the corner of the game's main menu, and the version in the server's startup log. If the REST API is on, GET /v1/api/info returns the server's version directly (the REST API guide).

How to know a new build shipped

The dedicated server's App ID is 2394010 — a different number from the game itself (1623730), and it ships separately. The build you have installed is written into the manifest inside the install directory:

grep buildid /home/palserver/palworld/steamapps/appmanifest_2394010.acf

The build Steam is currently serving comes from SteamCMD:

steamcmd +login anonymous +app_info_update 1 +app_info_print 2394010 +quit \
  | grep -A 5 '"public"'

Under branches → public, buildid is what's live right now and timeupdated is when it went out. Two different numbers means there's an update waiting.

You don't have to run that comparison by hand, though. app_update with validate does effectively nothing when you're already current, so you can hand the "is there something new" question to SteamCMD itself and just run it. The comparison earns its keep in one situation: people are online and you want to know whether stopping the server is worth it before you announce anything.

The order: announce, save, stop, update, start

The order is the whole article. Swap any two steps and you lose something.

PW='a-long-password'
API='http://127.0.0.1:8212/v1/api'

# 1. Announce — give the people online some warning
curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Server updates in 5 minutes"}'
sleep 300

# 2. Force a save — flush the in-memory world to disk
curl -s -u "admin:$PW" -X POST "$API/save"
sleep 10

# 3. Stop — wait for the process to be fully down
sudo systemctl stop palworld

# 4. Back up here (next section)

# 5. Update
sudo -u palserver steamcmd +force_install_dir /home/palserver/palworld \
     +login anonymous +app_update 2394010 validate +quit

# 6. Start
sudo systemctl start palworld

If the REST API isn't on yet, set RESTAPIEnabled=True and an AdminPassword in PalWorldSettings.ini first. Authentication is HTTP Basic and the username is always admin — and don't open 8212 in the firewall; the developers have said plainly it isn't designed to face the internet.

Three things worth spelling out:

• Don't run app_update while the server is up. Linux won't stop you from overwriting the files of a running program. The process keeps executing the old binary while the files on disk become the new one, and that mismatch only surfaces at the next restart.
• Always keep validate. It costs a file integrity pass, and it's the only thing that catches the corrupt files a download interrupted halfway leaves behind.
• Nobody can connect while the update runs. A large patch takes minutes, so don't start one with the whole group waiting to play.

The one full backup before you update

Save formats do change with versions sometimes, and a world once opened on a new build can't be taken back to the old one. So this backup is separate from your daily one: one by hand, immediately before the update. You will never need it, right up until the day it decides everything.

Copy the whole world directory, and copy it after the server is stopped:

sudo systemctl stop palworld
sudo -u palserver cp -a \
     /home/palserver/palworld/Pal/Saved/SaveGames/0/<WorldID> \
     /home/palserver/backups/pre-update-$(date +%F)

<WorldID> is the hexadecimal directory the server created on its first start. A backup holding only the Level.sav inside it restores into a world where everyone comes back as a brand new character — the map is there, the bases are there, and their owners are gone. Why Players/ has to come along and what order to restore in: Palworld save location, backup and restore.

When the world won't load after the update

Sort it into one of three cases first; the responses are completely different.

The middle one is the frightening one, and nothing has actually been lost. The original <WorldID> directory is still sitting there; the server just didn't read it. Don't delete it.

The way back is not "downgrade the build" — it's restore the pre-update backup onto the new build. Two reasons. Clients have already moved to the new version, so nobody could connect to an old-build server anyway; and most worlds that fail to load didn't hit a format change, they hit a half-written save left by an unclean stop. SteamCMD can fetch a specific build with download_depot, but you have to dig out the depot ID and manifest ID yourself, and for the reasons above it buys almost nothing.

The restore order: stop the server, move the current <WorldID> directory aside under another name (don't delete it), put the backup back under the original name, start. Once the world opens, give it a few days before you clean up what you moved aside.

Windows and Linux

Only the commands and tools differ. The order is identical.

Windows has one extra trap. If you installed the server through the Steam client's tools list, Steam can update it underneath a running server whenever it feels like it — which is exactly how you manufacture a half-written save. Change that app's automatic update setting, or manage the server only through SteamCMD.

Fold the update into the daily restart

You have to stop the server once a day regardless: Palworld's server has an unfixed memory leak, which makes a scheduled restart mandatory rather than optional (memory leak and scheduled restarts). Since it's stopping anyway, checking the version on every start costs essentially nothing:

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

The 4am restart becomes the version check. The morning a patch ships, the server is already on it; on every other day it still adds a minute or two, because validate checks every file. Don't drop TimeoutStartSec: with Type=simple, systemd's default 90-second start timeout covers ExecStartPre too, so a large patch that takes longer than that gets killed mid-download and the server never starts. Setting that daily stop up in the first place — along with start-on-boot and coming back from a crash — is in keeping a Palworld server running 24/7.

One thing that line does not do: it doesn't back up before it updates. So it belongs next to a backup that runs just before the restart, not on its own. Unattended updating without a backup is the arrangement that works for months and then loses a lot at once.

Common questions

How do I update a Palworld dedicated server?

The order is the whole answer: announce in game, force a save through the REST API, stop the server process, copy the entire world directory somewhere safe, run sudo -u palserver steamcmd +force_install_dir /home/palserver/palworld +login anonymous +app_update 2394010 validate +quit, and start it again. +force_install_dir has to point at your install and come before +login; leave it out and SteamCMD downloads a second copy elsewhere while the server stays on the old build. Never update over a running server, and the backup goes before the update, not after.

Does updating a Palworld server wipe the save?

Not by itself. The update replaces the server's program files and doesn't touch anything under Pal/Saved/SaveGames/. The risk isn't the update, it's killing the process mid-write. Keep to force save → stop → update, and take one full copy of the world directory immediately before.

Why can't anyone connect after I updated the server?

If everyone is locked out at once it is almost always a version gap. Either the server is still on the old build, or the server updated and someone's Steam hasn't updated their client yet. Compare the version in the server's startup log against the one in the corner of the game's main menu to see which side is behind. If only one or two people are stuck, it's the address or the ports, not the version.

Does a Palworld dedicated server update itself?

Not by default. Steam updates the client and leaves the server exactly where it was. You can put one SteamCMD line in a systemd unit's ExecStartPre so every start validates the install (with TimeoutStartSec raised so a big download isn't killed), but that alone gives you an update with no backup in front of it. If it's going to run unattended, the backup has to be part of the same routine.

On hosting, an update is one click

No single step above is hard. What's hard is that someone has to notice every time a patch ships. Palworld patches often, usually on a weekday afternoon, and the person who built the server is usually at work or at school when it lands. So it gets discovered in the evening, at the moment everyone wanted to play — and from there it's another stretch of backing up and updating before anyone gets in.

On a dedicated Palworld server from KeepWorlds, the noticing is done for you. Version guard detects a new build automatically and flags it on the server page in the Console. One click on Update Now runs the rest in order: the save is backed up first, then the server updates and comes back online. You pick the moment, so nobody gets cut off mid-session. Before it stops, an in-game announcement goes out, a countdown runs and a forced save completes, so anyone still online loses nothing. The backups pile up by timestamp under My servers in the Console, and you can restore any point you want to go back to.