Valheim dedicated server update: protect saves and verify joins

A Valheim dedicated server update should start with a clean stop and a complete, independent copy of the world, then end with checks of the world and your crew’s remote connections. Downloading the patch is the middle step. This checklist is for an existing server, whether you maintain it through Steam, SteamCMD, a container or a hosting panel. Allow about 30 minutes to organize the work, plus whatever time your download, backup and tests need. That is a planning allowance, not a measured outage estimate or a promise that every update can be reversed.

Plan your Valheim dedicated server update#

Identify the installation serving the campaign before changing any files. A second server directory on the same machine can update successfully while the old process keeps serving your friends. The useful question is which executable, launcher and storage location belong to the running instance.

Make a small maintenance record:

Use information from the running service and its configuration, not a folder name you remember. If two directories look plausible, resolve that ambiguity before maintenance. Keep passwords and account credentials out of any record you share with the whole crew.

The dedicated-server route comparison explains the distinction between software distribution, operating system and hosting location. Here, keep the route you already use. A routine patch is a poor moment to also move providers, change operating systems and replace the mod pack: each added change makes a failure harder to isolate.

Your preflight is complete when another authorized operator could use the record to find the same instance. If they would have to guess which world is live, the record needs one more pass.

Set the maintenance window and recovery boundary#

Agree when players leave and who decides that play can resume. Give the crew a start time and a place to see the result; avoid announcing a guaranteed finish before you know the download and verification requirements.

Read the current release notes and the compatibility information for the exact additions you run. Iron Gate’s mod policy treats mods as community software. A successful vanilla update is not evidence that a particular loader or plugin works with it. Record unresolved dependencies before choosing whether to proceed, delay, or test a copy first.

Our recommended operating rule is to have one maintenance owner and one explicit hold point. That owner coordinates any scheduled updater, restart task or service supervisor so it cannot unexpectedly start the world while a copy is being made. Record what was paused so it can be restored deliberately afterward. Do not disable unrelated machine protections to make the patch convenient.

Decide the recovery boundary now: which dated world copy would you use, where could you test it without touching the campaign, and what compatible software could load it? Keeping yesterday’s server executable does not answer the last question for a world saved by today’s version.

For a small friends-only server, this can be a short note rather than a formal runbook. It still needs a clear decision: if the required platform or mod check fails, normal play remains on hold. Otherwise players can create new progress while the operator is still deciding whether to restore an earlier state.

Stop cleanly and copy the complete save tree#

Take the maintenance copy after the game process has exited. The current community container maintainer’s backup documentation describes Valheim 1.0 worlds as directories containing many files and warns about inconsistent live copies. Each world now lives in worlds_local/<WorldName>/ as _main.<N>.fwl2, _main.<N>.db2, _main.<N>.chunks, _main.<N>.ok and many *.chunk files, and automatic backups appear beside it as folders named like <WorldName>_backup_auto-YYYYMMDD-HHMMSS. A recipe that copies only the legacy .db + .fwl pair is insufficient for that format. A world still in the older format is converted on its first 1.0 load, so keep the pre-update copy of the original files.

First resolve the effective data location. Iron Gate’s server manual documents a save-directory override and these defaults for the account running the server.

Windows:

%USERPROFILE%\AppData\LocalLow\IronGate\Valheim

Linux:

~/.config/unity3d/IronGate/Valheim

A service account’s home directory can differ from yours. A container’s persistent mount or a panel’s export location needs its own check; do not substitute your desktop default for the active path.

1. End the session and stop through the existing control

   Ask players to leave. For the foreground server described by Iron Gate, use Ctrl+C and wait for exit. For a managed service, container or panel, use its documented graceful stop and confirm the game process has finished. Closing a window or seeing an empty player list is not that confirmation.

2. Preserve data and the configuration that selects it

   Archive the entire effective save tree, plus the actual launch configuration and any separately stored mod configuration. Keep the custom startup script: the manual warns that Steam updates replace the supplied original. Record the world selection and access lists with the maintenance copy.

3. Check the copy before updating

   Place a dated copy outside the installation being changed. Check that the archive opens, contains the intended directories and has no copy errors. Compare its contents with the stopped source. A successful copy check establishes that files were copied; a separate restoration rehearsal establishes whether your recovery procedure works.

If you cannot explain what the backup contains or which account wrote it, postpone the update. A larger archive of the wrong directory still leaves the campaign unprotected.

Update through the route already running your server#

Apply the update to the installation you identified, with the game process stopped. Preserve its storage and launch identity while changing the game software. The controls differ by route:

For an existing SteamCMD installation

The community project’s actual updater code uses anonymous SteamCMD login and the server app ID. For a clean package install and an explanation of the exact success evidence, see the SteamCMD reference for app 896660. This minimal Linux example is for an existing public-branch installation. Replace the illustrative directory with the one in your maintenance record, and invoke your installed SteamCMD launcher:

./steamcmd.sh +force_install_dir "/absolute/path/to/existing/valheim-server" +login anonymous +app_update 896660 +quit

Do not copy this into a server that intentionally follows another branch without preserving that branch’s documented update procedure. It is not a branch-switching recipe. On Windows, use the existing SteamCMD executable and the actual Windows installation path; do not paste the Linux launcher literally.

Read the completion or error output before starting the game. A download command returning control is not enough if its log reports failure. Updating another directory, or only updating your personal game client, leaves the maintenance goal unfinished.

For containers and panels

The community Valheim container has its own game updater; changing the container image is a separate operation. Its documented configuration mount holds saves, while its server directory holds downloaded software. Preserve the configured persistent mounts when following that project’s replacement procedure. Other images may work differently.

A panel button is equally provider-specific. Confirm whether its operation updates binaries, reinstalls files, or restores data before selecting it. If the documentation is unclear, keep the server stopped and ask the provider which operation preserves the recorded world and configuration. Do not experiment with a reinstall button on the only copy of a campaign.

Check the world and a remote player from each platform#

Reopen access only after the updated instance loads the intended world and representative players can enter it. These are checks for your environment, not claims that we tested your server or mod set.

1. Inspect the process that actually started

   Launch the preserved configuration. Record the running build and inspect startup errors. Iron Gate documents a server-connected readiness message, but readiness alone does not establish that the correct campaign loaded. Confirm the instance and storage location against your record.

2. Identify the campaign in game

   Have a tester inspect a known base, recent construction and the settings your group depends on. Check a recognizable piece of pre-maintenance progress. An unfamiliar empty world is a reason to stop and inspect selection or storage, not to begin rebuilding.

3. Test the crew's actual platforms remotely

   Use a player outside the server network from each required platform or store cohort. Have them use the normal joining route, enter the intended world and confirm it responds. Record platform, displayed build, time and any exact error. One successful Steam connection does not complete a mixed-platform check.

4. Check that a controlled restart preserves the result

   During the test window, make a small agreed change, stop gracefully, and restart the same configuration. Confirm the change persists and the remote testers can reconnect. Keep ordinary campaign progression paused until these checks pass.

Do not reject a crossplay test solely because two devices display different version numbers. Iron Gate’s September 18 patch notes explicitly say crossplay remains functional during its staggered platform rollout. That dated statement does not guarantee your next patch or your particular session. Check the latest notice and the actual result together. If a player still sees an explicit version rejection, use this Valheim incompatible-version checklist to compare the affected build and release branch before rolling back.

If a tester cannot join, preserve the error and logs before restarting repeatedly. Record whether the failure affects everyone or one cohort. That distinction helps separate a general startup problem from a platform, account, networking or mod issue.

Choose reopen, hold or recover from the results#

Make the decision from the acceptance checks, not from how long the server has already been unavailable. The crew is better served by a clear hold than by a premature announcement that sends everyone into a broken session.

Our recovery recommendation is to protect both the original archive and the failed state before changing anything else. The failed state’s logs and files may explain what happened. Work on a duplicate in an isolated test destination, following the current procedure for that distribution or provider.

Avoid merging a partial old save into a newer world directory. Restore the selected complete state through the documented procedure and verify it before replacing the active campaign. If you cannot establish a compatible runtime or a complete copy, keep the campaign on hold while resolving that prerequisite. A guessed downgrade is not a recovery plan.

Restoring the pre-update copy also gives up world progress made after that copy. Tell the crew which timestamp would become the recovery point before authorizing it. Keep character data and world data conceptually separate; restoring the server world is not a promise to rewind every player’s inventory and character history.

Turn the successful run into the next maintenance plan#

Keep the successful maintenance record so the next update starts from evidence. Save the resulting build, launch identity, backup timestamp, testers’ platforms and the checks they completed. Record any workaround that still needs attention rather than letting it become an undocumented permanent requirement.

Restore the schedules you paused only after reviewing what they will do. A task that updates game files while another immediately restarts the server can defeat the careful sequence you just used. Decide which automation may download, which may stop or start, and which still requires an operator’s acceptance.

Retain the pre-update copy according to an explicit policy. Do not let the next automatic backup silently become your only recovery option before the crew has completed a representative session. Add a reminder for the operator to confirm that later backups are actually reaching their independent destination.

Self-hosting remains workable when someone owns this process. If the crew wants less home-machine administration, we recommend Game Hosting’s Valheim hosting with an integrated panel, control over updates and free scheduled backups. Export a recovery copy and verify the updated world; an included backup feature does not replace a restore check.

Finish by telling the crew whether play is open, which checks passed and who owns the next window. Keep the backup and the operating record somewhere the authorized backup operator can actually find them.