Build Your Own Palworld Server, Part 6: Updating the Server on Patch Day
When a Palworld patch ships, Steam updates your game automatically. Your server, however, stays put - so the day a friend says "I cannot join the server", it is almost always a version mismatch: new game, old server. A server that does not update itself is not broken; it is a configuration choice. This part covers the two approaches and the actual update procedure.
Approach 1 - Update on Restart
The community image from Part 1 (thijsvanloef/palworld-server-docker) downloads fresh server files from Steam every time the container starts (UPDATE_ON_BOOT defaults to on). On patch day your only job is "save and restart", which is convenient. The cost: every restart lands on the newest build no matter what, you cannot pick the moment, a broken patch gets applied like any other, and going back to the previous version is hard.
Approach 2 - Pin a Version Tag (What I Run)
I run the official Pocketpair server image pinned to a version tag (the version label after the image name). I decide exactly when and to which version the server moves, and if something breaks, rolling back means putting the old tag back. The price is updating by hand on patch day - and it is not rare: five tags shipped in the first month after release (v1.0.0 to v1.0.2). Checking for a new version takes two commands.
# List version tags of the official server image (read-only token, then tag list)
TOKEN=$(curl -s "https://ghcr.io/token?scope=repository:pocketpairjp/palserver:pull" \
| sed 's/.*"token":"\([^"]*\)".*/\1/')
curl -s -H "Authorization: Bearer $TOKEN" \
"https://ghcr.io/v2/pocketpairjp/palserver/tags/list"
# Sample output (later entries are newer):
# ..."v1.0.1.100619","v1.0.2.100933","v1.0.2.101103"]The Procedure - Backup, Save, Swap the Tag
Order matters. If you just stop a Palworld server, everything since the last save is lost (the trap from Part 2 - the shutdown signal never reaches the game process). So always back up the world and save first, then stop. After that, change one line in the compose file, pull the new image, and start it again.
cd ~/palworld
./backup.sh # 1) world backup (the script from Part 2)
# 2) Save FIRST, then stop (a plain stop discards unsaved progress)
curl -s -u admin:ADMIN_PASSWORD -X POST http://127.0.0.1:8212/v1/api/save
docker stop palworld-server
# 3) Swap the image tag in compose.yaml to the new version
# image: ghcr.io/pocketpairjp/palserver:v1.0.2.101103 <- this line
# 4) Pull the new image and start again
docker compose pull palworld-server
docker compose up -d palworld-server
# 5) Watch the boot log, then test-join from the game
docker logs -f palworld-serverRolling back is the same procedure: put the previous tag back, pull, up. One caveat - once the world has been saved by the newer version, that save file may not match the older build, so restore the backup from step 1 when you roll back. And if you run approach 1 (update on restart), steps 1 and 2 still apply unchanged: whatever the setup, "back up, save, stop" is the whole ritual.