PAL SAVE // LOCAL INSTANCESave Editor
SESSION BROWSER ONLY
Open save
NO REMOTE LINK

Co-op host to dedicated server

Palworld co-op to dedicated server migration without a blind identity swap.

Moving Palworld co-op to a dedicated server requires the world files and a deliberate player identity migration. The target server can load the map while assigning the host or a friend a new GUID, which produces a level 1 character even though the old player file still exists. The current release inventories filenames, sizes, hashes, outer signatures, and player-file candidates. It does not read GUIDs, guilds, bases, Pal ownership, or build a source-to-target identity map.

SOURCECo-op worldHost + client Players files
IDENTITY MAPPlayerUID / GUIDHost handled as a separate row
TARGETDedicated serverExisting target identity evidence
01 / Most fragileCo-op hostHost identity often needs explicit confirmation
02 / Move togetherLevel + PlayersCopying only one side breaks cross-file references
03 / Success checkActual loginStructural validation cannot replace in-game verification
PAL SAVE EDITOR / DIAGNOSTICWorld overview

Open a save to see its world summary

We will identify the files, version clues, completeness, and tasks available for this exact input.

Compatible PlZ Beta worlds can expose named players and Pals; unsupported formats receive diagnostic evidence.
Open this task Select files inside the App so the local session is preserved.

Failure pattern

Why Palworld characters reset after a server transfer

The dedicated server identifies a login differently from the original co-op session. The map, bases, and guild can load correctly while the login selects a newly created Players file. The original progression may still be present under the source GUID, but continuing to play writes new state under the wrong identity.

Stop the server as soon as the reset appears. Preserve the target world with the new player record because that record reveals the identity the server expects. Keep the source world separately so the original character, ownership, and guild references remain available for mapping.

Migration evidence to keep
EvidenceSource worldTarget server
World filesLevel.sav and metadataTarget WorldID folder
Player recordsOriginal Players filesNewly created Players files
IdentitySource PlayerUID / GUIDTarget account GUID
Cross-file linksGuild, base, Pal ownershipExpected target references

Resolve each player explicitly

Build the co-op to dedicated server identity map

List every source Players file, known display name, PlayerUID, GUID, guild membership, Pal ownership, and the account that should own it on the server. Display names help a human confirm the row, but they are not safe rewrite keys.

Mark the co-op host as a separate unresolved case until the target identity is explicit. The dry-run should report how many players map automatically, which records conflict, and which world-side references will change. Friends who are not present during the migration still need a preserved mapping row.

Palworld co-op to dedicated server migration check showing a world opened without its Players folder, with identity mapping still unverified
Opened without its Players folder, the world can be edited but its identities cannot be mapped. A transfer plan starts with the complete file scope and keeps unresolved identities visible instead of guessing.

Migration unit

Move the full Palworld world, not a single save file

A standard source contains Level.sav, Players, LevelMeta.sav, WorldOption.sav, and sometimes other local records. Server versions and hosting layouts vary, but the safest migration unit is the complete matching WorldID folder. Copying only Level.sav can leave player files and cross-file references behind.

The target commonly uses `Pal/Saved/SaveGames/0/<WorldID>/`, though a Docker volume or managed host can mount that path elsewhere. Record the actual target volume and preserve its existing contents before uploading the migrated set.

Level.savPlayers/<id>.savLevelMeta.savWorldOption.savOne coherent WorldID snapshot

Dry-run contract

Run the Palworld co-op to dedicated server migration dry-run

The dry-run should name every source and target file, summarize the identity replacements, count affected players, and list unchanged players, bases, guilds, and Pals. It should block on duplicate identities, missing player files, unsupported container formats, or an unresolved host.

Pal Save Editor currently provides file-set recognition and this migration checklist. It does not read or rewrite the identities shown in the recommended dry-run. Binary host conversion remains locked until current-version round trips are proven.

  1. 01

    Stop source and target

    Prevent either world from creating new state while the migration evidence is collected.

  2. 02

    Back up both complete worlds

    Keep source and target WorldID folders in separate dated locations.

  3. 03

    Create target identities

    Join once only when a tool requires a target Players record, then stop the server immediately.

  4. 04

    Review every mapping

    Confirm host, clients, guild, Pal ownership, and storage-related references before export.

  5. 05

    Validate the migrated copy

    Reparse the package, start the test server, and have each player confirm their character and assets.

Verify each account

Verify the dedicated server after migration

Each player should verify level, inventory, technology, Pals, guild membership, bases, map progress, and fast-travel state. Ask the co-op host and at least one former client to test because their identity paths can differ.

Keep the source and target backups until every important account has logged in successfully. If one character resets, stop the server again; do not continue playing and do not delete either the old or newly created Players file.

Co-op hostFormer clientsGuild + base ownershipInventory + progression

Before you continue

Source and target migration checklist

  1. 01Stop both the co-op game and dedicated server.
  2. 02Back up the complete source world and target slot.
  3. 03Keep newly created target player files as identity evidence.
  4. 04Map every player, with the co-op host handled separately.
  5. 05Verify each migrated account in game before retiring backups.

Specific answers

Questions about co-op migration

Why does the world load but my character starts at level 1?

The server loaded the world but selected a new player identity. Restore the backup and fix the identity mapping before continuing.

Can I migrate only Level.sav?

No. The Players folder and metadata must travel with the matching world state.

Should the co-op host and friends use the same mapping rule?

No. Keep the host as a separately reviewed row because the host's co-op identity and the server's expected identity can follow a different path from client players. Confirm every target account explicitly.

Should players join the target server before the migration is prepared?

Only when the migration procedure needs a target Players record for identity evidence. Use a disposable target, stop it as soon as the record is created, and preserve that new file with the target backup before mapping anything.

What proves that a migration is complete?

Every intended player logs into a test server and confirms their character, inventory, Pals, guild membership, bases, and progression. A successful server start alone does not verify each identity or ownership reference.