Update the dedicated-server installation while it is stopped, with a complete pre-update copy of its data and launch configuration. Then verify the selected world, player access and a save followed by a restart before treating the maintenance as finished. Downloading new files alone does not prove that the right server is running them.
This walkthrough is for an existing PC dedicated server. It includes a direct SteamCMD example for the normal public branch. A panel, container or LinuxGSM installation should use its own update workflow, with the same preservation checks; do not run two updaters against the same directory.
Identify the instance and branch you intend to update#
Record the running executable's installation directory, its service or startup script, the operating-system account, selected world and effective save directory. Include launch arguments, crossplay choice, mods and loader versions, and current client/server versions. Keep passwords out of shared records.
Confirm which branch the players use. A successful update of a retained test branch can still leave normal clients incompatible. The dedicated-server Steam tool is 896660; 892970 identifies the game client. Updating the client's library entry does not update a separately installed server.
Before changing a working script, retain its contents and permissions outside the Steam-managed installation. Preserve its working directory and library environment too. Iron Gate warns that the supplied startup script can be replaced by updates. Afterward, compare the newly supplied script for required changes rather than restoring an old script blindly or launching the default copy with different world settings.
Stop the writer and protect the complete save tree#
Announce downtime and prevent this instance's automatic restart or update job from racing the maintenance. Use its normal graceful stop. For a foreground server, Iron Gate specifies Ctrl+C. For a managed service, confirm how its stop action reaches the game. Wait for shutdown and save-related log messages and confirm that the game process has exited; a force-kill is not evidence of a completed save.
With the writer stopped, archive the entire effective save directory, including world data, backup folders and access-list files. Also preserve the custom launcher, service configuration, mod environment and a recoverable copy or release artifact of the old server installation. Keep an off-host copy and verify extraction into a separate directory.
Valheim 1.0 shipped a chunk-based world save system. Older worlds may appear as a .db/.fwl pair, while current worlds use folders containing multiple pieces. A backup rule matching only those two old extensions can miss the current world. Do not select individual chunks or combine files from different save generations. Back up the complete stopped tree instead.
If you cannot identify where the running instance writes, resolve that first. An unused administrator profile or empty container mount is not the intended world.
Update the intended Steam tool#
For a direct installation, launch your installed SteamCMD as the account that owns the server files. The following lines are interactive SteamCMD input, not Bash commands. Replace the example installation path with the verified existing directory:
force_install_dir /srv/valheim/server
login anonymous
app_update 896660 -beta public
quit
This explicitly selects the normal public branch. Use it only when that is the agreed target; a test-branch server needs the developer's current branch/access instructions and matching clients. Check SteamCMD's completion result and retain the log before starting the game. Current files do not prove the right branch and installation were selected.
The example omits validate. File validation can replace customized files distributed with the application; use it for a specific integrity problem after protecting local changes, not as an unexplained step in every update. Ordinary updates can also replace supplied scripts, so the independent launcher copy remains necessary.
For the Steam desktop tool, update Valheim Dedicated Server in the Tools library, then use the intended custom launcher. Do not assume the Steam shortcut points to your renamed script.
Verify on a copy before reopening normal play#
Where practical, first load a copied save tree with the updated executable in an isolated test instance. Give it its own save path and endpoint, keep normal players out, and ensure it cannot write to production data. Preserve the intended mods; do not save the only world without content mods to make an update appear successful.
Check the startup log for the expected world and version. Join with a matching client, inspect a known build and recent progress, then make a harmless recognizable change. Confirm a save completes, restart cleanly and verify that the change remains. Also check administrator and permitted-player access: successful world loading does not verify the lists.
If a fresh empty world appears, stop and inspect the selected world and data path before allowing another save. Do not “repair” the situation by copying files over an actively writing instance.
Recover the executable and data together#
If acceptance fails, retain the failed update's logs and data separately. Restore the previous executable environment and the pre-update data copy into the intended stopped instance. New code may already have converted a save; downgrading binaries alone does not reverse that conversion. Players also need a compatible client, so do not promise a rollback if their platform cannot select one.
After recovery, repeat join, save and restart checks before releasing the server. Record the chosen branch and backup location for the next maintenance. For organizing services on your own Linux VPS, Nexardo provides an infrastructure management workflow; keep the game's world and recovery checks part of that routine.
