Updating your Palworld server to 1.0 safely

Update your Palworld server to 1.0 without losing your world. What carries over, the one step modded servers must not skip, the version-mismatch fix, and the launch-day save crash.

Palworld 1.0 is a big update, but updating a Hostd server to it is genuinely one restart, because our image pulls the latest server build from Steam every time the container boots. The care is not in the mechanics, it is in a couple of things worth knowing before you press the button, especially if anyone in your group ran mods.

What carries over, and what quietly changes

Your world is fine. It loads on 1.0 with your bases, your Pals and your levels. Pocketpair confirmed there is no forced wipe; their publishing lead's exact line was that you do not need to wipe, though he suggested a fresh character shows off the reworked early game better. That part is your group's call.

A few things do adjust themselves when an old world loads, and it saves a panic if you know in advance:

  • Main and side mission progress is reset. Tower-boss missions you have already beaten are auto-completed from your history, so you are not made to refight them.
  • Placement data for the random-Pal-spawn mode from the old version is not carried over.
  • Accumulated experience is rebalanced to 1.0's new levelling table. Your player level is not reduced.

None of that touches your bases or the Pals in your boxes.

The one step modded servers must not skip

If you or anyone hosting brought a modded save across, read this twice. Old mods do not just misbehave on 1.0, they crash servers and can corrupt saves, and Pocketpair were unusually direct about it: turning mods off is not enough. Leftover mod loaders still get pulled in at startup even when "disabled". You have to delete the files. On a self-hosted install that means unsubscribing the Steam Workshop items and deleting the mod folders (Pal/Binaries/Win64 and Pal/Content/Paks) before you update, then verifying the game files. On Hostd our managed Palworld image does not run third-party mods in the first place, so a Hostd server has nothing to strip; this matters mainly if you are importing a save from a machine where you ran them.

The update routine

  1. Take a backup. Hit Manual backup on the dashboard and let it finish. It is your restore point, and it costs about ten seconds. Full steps: Manual backups.
  2. Save, then stop cleanly. Use the dashboard Save action so the latest state is written to disk, then stop the server rather than letting it patch mid-session. If you back up a self-hosted world by hand, copy the whole save folder including WorldOption.sav; that file overrides PalWorldSettings.ini entirely, and people lose settings by leaving it behind.
  3. Restart to 1.0 and watch it boot. On Hostd the restart pulls the 1.0 build. Let it come fully up and confirm your world, bases and Pals loaded before you invite anyone back.
  4. Everyone updates their game. A 1.0 server will not accept a client still on the old version, and vice versa. Make sure the group updates through Steam or their console before they try to join.

The two things people hit on launch day

"Connection timed out" or "running an incompatible version". This is almost always a version gap. Steam auto-updates the game the moment 1.0 drops, so clients jump to 1.0 while a server that has not restarted is still on the old build, and the two cannot talk. The fix is to get the server onto 1.0 (on Hostd, one restart) and have everyone confirm their own game finished updating. If a self-hosted server still reports the old version after a SteamCMD update, the depot occasionally lags or the update wrote to the wrong install path; re-run app_update 2394010 validate and check it landed in the folder the server actually launches from.

"Failed to save, failed copy from backup" with players getting dropped. A lot of servers hit this in the first hours of 1.0, across managed hosts and self-hosted boxes alike. It is the server failing to write its save. On Hostd, restart the server once and it clears. If you run your own box, it is a permissions problem: the server process needs write access to its save folder (run it as the right user rather than as root on Linux, or with the correct permissions on Windows). As a stopgap while you sort it, widening the autosave interval reduces how often it trips.

If a save genuinely breaks

  • Restart once first. A clean restart resolves a surprising share of first-boot hiccups.
  • If the world is actually damaged, restore the backup you took in step 1. This is the entire reason step 1 exists.
  • Still wrong? Open a ticket from your dashboard with the server name and roughly when it started, and we will read the logs from our side.

There is no prize for being first

Nothing rewards updating in the opening hour while launch-day issues are still shaking out. If your group plays this evening, update an hour beforehand with a backup in hand, and you will walk into a night that works.

Next steps

Last updated 2026-07-10. Notice a mistake? Tell us.

Cookies