Move Your Palworld Save to a Dedicated Server Without Losing It

At some point, local co-op stops working for your group. Not because Palworld broke anything - because the model itself has limits. This guide walks through exactly how to move your world off a local machine and onto a dedicated server without losing saves, including the GUID rebind problem that most migration guides skip entirely.

Why Local Hosting Hits a Wall

Local co-op is fine for testing Palworld with one or two friends on a weekend. By month two, most groups have found at least one of these friction points.

The 4-player cap is hard. Palworld’s co-op mode is capped at 4 players by Pocketpair - that’s a fixed limit, not a hardware constraint. A dedicated server raises that ceiling to 32. If your group has grown past four, co-op simply can’t accommodate everyone.

The world only exists when the host’s PC is on. Palworld worlds run as long as the host’s PC is awake. The minute Windows reboots for an update at 3 AM, your friends are looking at a connection error and a dead Steam invite. That’s not a Palworld bug. That’s the model.

Save corruption is real and documented. Palworld has a known pattern of save corruption on unexpected shutdowns - crashes, power loss, the host force-closing the game. The Steam community threads on this are not short. One thread from early access is titled “my save is gone.” Another is titled “You WILL lose your progress.” This isn’t a rare edge case.

Port forwarding is friction. UDP 8211 needs to be open, your external IP needs to be static or handled by dynamic DNS, and carrier-grade NAT on some ISPs makes forwarding impossible regardless. Every time the router reboots, someone is troubleshooting connectivity again.

The host machine takes a performance hit. Running the dedicated server and the game client on the same PC splits resources between both. It’s workable on high-end hardware, but it’s never optimal.

None of this means local hosting is a bad choice for getting started. It means there’s a point where the trade-offs stop being worth it.

Two Starting Points: Co-op Host vs SteamCMD Self-Host

Before you start copying files, figure out which migration path you’re on. The steps differ.

Co-op host (most common): You’ve been hosting via Palworld’s built-in “co-op” button. Your save lives in your Steam user folder on your PC. This path requires the GUID fix covered in section 4 if the host wants to keep their character.

SteamCMD self-host: You’ve been running a local Palworld dedicated server via SteamCMD on your own machine, your friends connect to your IP directly, and you’ve been managing it yourself. This is technically already a dedicated server setup - you’re migrating to managed hosting, not changing the server type. The GUID problem doesn’t apply here.

If you’re not sure which you are: if your friends joined through the “Join Co-op” invite in Steam, you’re a co-op host.

Where Palworld Saves Actually Live

Co-op host save location

On Windows, your world save is at:

%LOCALAPPDATA%\Pal\Saved\SaveGames\<your-steamid>\<world-guid>\

To get there: press Win+R, type %LOCALAPPDATA%\Pal\Saved\SaveGames\, press Enter. You’ll see a folder named with your Steam ID. Inside that is one or more folders named with a long alphanumeric string - each one is a saved world.

SteamCMD self-hosted save location

<server-root>\Pal\Saved\SaveGames\0\<world-guid>\

The 0 in the path is literal - dedicated servers use 0 in place of a Steam ID.

What each file does

Every file in the world folder has a specific role. Don’t skip any of them.

Xbox Game Pass saves

Xbox Game Pass saves use an encrypted .wgs container format that can’t be copied directly onto a Steam dedicated server. Converting them is possible with community tools, but it’s fiddly and version-dependent, so it’s outside the scope of this guide. The Steam co-op and SteamCMD paths below are the reliable routes.

The GUID Problem (and Why a Copy-Paste Isn’t Enough)

This is the part most migration guides skip, and it’s the part that actually bites people.

When you host a co-op session, Palworld assigns your character a GUID tied to your local session identity. That GUID is embedded in the world save. When you move that save to a dedicated server, the server has its own new host identity with a different GUID. The game sees the mismatch and doesn’t know which character belongs to the “host” on the new server.

The result: everyone else’s character comes back exactly as they left it (their files are in Players/, named by an internal PlayerUID that the server matches automatically). The co-op host’s character doesn’t match anything on the new server, so the game treats the host as a new player.

You have two options:

Option A - Accept a fresh host character. Everyone else’s saves survive intact. The former co-op host starts a new character on the dedicated server. Simple, no tools required. If the host was mostly managing the server rather than playing, this is fine.

Option B - Remap the host character using palworld-host-save-fix. The tool xNul/palworld-host-save-fix and the alternative MoistOverflow/Palworld-Save-Fix can remap the host’s character UID from the old co-op GUID to the new dedicated server UID.

If you go with Option B, run the tool on a copy of your save files, not the originals. Keep the originals untouched until you’ve verified the migration worked.

Step-by-Step: Migrating a Co-op Save to a Dedicated Server

Before you start

• Close Palworld completely on the source machine. The game keeps save files open while running.
• If the destination is a brand-new server, start it once and then stop it. Palworld only creates the SaveGames/0/ folder and the config files on first launch, and they need to exist before you upload a world or edit GameUserSettings.ini.
• Stop the dedicated server on the destination before copying. Do not copy files to a running server.
• Make a backup copy of the entire world folder before touching anything.

1. Locate your world folder

Navigate to %LOCALAPPDATA%\Pal\Saved\SaveGames\<steamid>\ and identify the correct world folder. If you have multiple, the modification date on Level.sav is the easiest way to confirm which world is current.

2. Back up the source folder

Copy the entire world folder somewhere safe - a separate drive, cloud storage, anywhere. Do not proceed without this. You’ll want it if something goes wrong on the new server.

3. Upload the world folder to the dedicated server

Copy the entire world folder to:

<server-root>/Pal/Saved/SaveGames/0/<world-guid>/

For large save folders, use SFTP rather than a web-based file manager. File managers in browser panels can time out or corrupt files during large uploads.

4. Set DedicatedServerName in GameUserSettings.ini

Open Pal/Saved/Config/WindowsServer/GameUserSettings.ini (or LinuxServer on Linux hosts) on the dedicated server. Find the DedicatedServerName= line and set it to the world folder name you uploaded, the alphanumeric string you see under Pal/Saved/SaveGames/0/ on the server. That value is what tells the server which world to load.

5. Carry over your world settings, then delete WorldOption.sav

A co-op or singleplayer world keeps its rate settings (XP, capture, day/night length, difficulty) in WorldOption.sav, not in an INI. A dedicated server reads those from PalWorldSettings.ini instead, but as long as WorldOption.sav is in the world folder it overrides the INI, so anything you set there is ignored.

First, note the settings you had configured for the world in-game. Then delete WorldOption.sav from the uploaded world folder:

<server-root>/Pal/Saved/SaveGames/0/<world-guid>/WorldOption.sav

With it gone, set those same values in the server’s PalWorldSettings.ini, through your host’s control panel or by editing Pal/Saved/Config/WindowsServer/PalWorldSettings.ini (or LinuxServer on Linux hosts, including WinterNode) directly. Check the WinterNode Palworld configuration guide for the current schema. Do not paste an entire INI from a guide that predates recent patches, the schema has changed and stale keys cause parse errors.

6. Start the server, then fix the host character (Option B only)

Start the dedicated server and connect via Direct Connect using the IP and port from your host’s control panel (8211 is the default if it hasn’t been changed). Do not use the in-game server browser for this, it only shows the first 200 servers and yours may not appear yet (see known issues). Have a non-host player connect first to confirm the world loaded with bases and progress intact.

If you chose Option A (fresh host character), you’re done. The host creates a new character and keeps playing.

For Option B (preserve the host’s character), the remap needs the host’s new server-side UID, which only exists once the host has logged in:

1. Have the co-op host connect once and create a character. This generates a new file in Pal/Saved/SaveGames/0/<world-guid>/Players/ whose name is the host’s new UID.
2. Stop the server and copy the world folder to a local machine.
3. Run palworld-host-save-fix with the old co-op host GUID (00000000000000000000000000000001) as the source and that new filename (without .sav) as the target. Follow the tool’s README.
4. Copy the fixed world folder back to the server and restart.

Step-by-Step: Migrating a SteamCMD Self-Host to Managed Dedicated

This path is simpler because you’re already running a proper dedicated server. No GUID surgery needed - every player including you has always connected as a regular player, not as a co-op host.

1. Stop your local SteamCMD server

Shut it down cleanly. Don’t kill the process.

2. Locate your world folder

It’s at <server-root>\Pal\Saved\SaveGames\0\<world-guid>\ on Windows or the equivalent path on Linux.

3. Back up

Same rule: copy the folder somewhere safe before moving it.

4. Upload to the managed server

Upload the entire world folder to the same relative path on the new host:

Pal/Saved/SaveGames/0/<world-guid>/

Use SFTP for anything larger than a few hundred MB.

5. Transfer config values

Copy over your PalWorldSettings.ini gameplay values (rates, difficulty, player cap). Don’t copy the file wholesale: it can carry environment-specific fields like PublicIP, PublicPort, and RCON settings from the old server, which break server listing or remote admin on the new host. Bring the gameplay multipliers across and leave the network and port fields as the new host’s control panel or generated config sets them.

Set DedicatedServerName= in GameUserSettings.ini to your world GUID, same as the co-op path above.

6. Start and verify

Start the server, connect via Direct Connect, confirm the world state.

Verifying the Migration Before Inviting Friends Back

Take 10 minutes to verify the migration before your group reconnects. Rolling back to the source is easy now and nearly impossible after everyone has played for an hour on a partially-broken save.

Check these things on your first solo login:

• World loads to the same map state. Your base should be there. Objects, chests, crafting stations - all present.
• Your character is correct. If you used Option B (the remapping tool), you should have your Pals, inventory, and level. If you used Option A, you’ll have a new character - expected.
• INI multipliers match what you had. XP rate, capture rate, and other settings should be what you set them to, not defaults.

Then check the Players/ folder on the server and confirm there’s a .sav file for each expected player. Each file is named with a UID. If a file is missing, that player will be forced to create a new character when they log in.

After a player connects for the first time, confirm their character came back correctly before anyone plays for an extended session.

Day-of-Migration Player Checklist

Pass this to your group when you’re ready to bring them back.

• Server address: your server’s IP and port (default port is 8211 UDP)
• Password: if you set one in PalWorldSettings.ini
• How to connect: In Palworld, select “Join Multiplayer Game” and use Direct Connect with the IP:port. Do not use the server browser - it may not show your server.
• What to expect on login: Your character should appear as you left it. If the co-op host used Option B and their character was remapped, they may see a brief character-select screen before their character loads - this is normal.
• If your character is gone: Do not create a new character yet. Message the server admin immediately. The Players/ file for your UID may have been missed during migration and can still be restored if you catch it before the new-character save overwrites anything.

What a Dedicated Server Gives You That Local Can’t

Once you’re on a dedicated server, the friction that defined month two is gone.

The server is online whether you’re playing or not. Your friends can log in at 2 AM when you’re asleep. The world doesn’t disappear when your PC reboots.

WinterNode runs platform backups every 12 hours with 45-day retention, and also takes a local backup on every server restart (kept for 24 hours). If a save corrupts, you have a restore path, documented in the backups help article. That’s the difference between “my save is gone” and “my save is 4 hours old.”

No port forwarding. No dynamic DNS. No carrier-grade NAT problems. You get an IP and a port and it works.

The 32-player cap gives your group room to grow. And the performance hit disappears from the host’s machine - they’re playing Palworld as a regular player now, not as a player who’s also running a server.

WinterNode’s Palworld server hosting starts at 6GB for $1.99/GB/mo, no CPU limits.

Recovering If Migration Goes Wrong

Keep the source folder untouched. This is the only rule that matters if something breaks.

If the world doesn’t load on the new server, if saves are missing, if the world loads in a broken state - your source folder on the original machine is the recovery path. Do not delete it, do not overwrite it, do not play on it until you’ve verified the new server is working correctly for at least one full session.

If a player’s character is missing, check the Players/ folder on the new server for their UID file. If it’s not there, it didn’t get copied. Pull it from the source folder backup and add it before that player creates a new character.

If the world loads but settings are wrong, re-check PalWorldSettings.ini on the new server. Missing or mismatched multipliers are an INI copy problem, not a save problem.

After You’ve Migrated

The save migration is done. The ongoing work is keeping the server running correctly across Pocketpair patches.

Palworld updates have a documented pattern of resetting INI files, and some patches change the save schema in ways that require attention before you restart. The Breaking Patches guide covers that operational side: what to check before every update, how to roll back if a patch breaks your world, and how to set up a pre-update routine that protects what you just spent time migrating.

A few things worth doing this week while it’s fresh:

• Verify the backup schedule is running. Check the backups article to confirm auto-backups are active and the retention window is what you expect.
• Set a restart schedule. Palworld dedicated servers benefit from periodic restarts for memory management - see the server performance guide for a reasonable cadence.
• Check the best server settings guide if your group wants to tune XP rates, capture rates, or difficulty now that you have a proper INI to work with.

The server is running. Your group is online. The next step is keeping it that way.

Get your Palworld server →