Updating the server
What Update and start actually does, where steamcmd comes from, what the progress bar is telling you, and every way an update can fail.
The question that leads here, and the three prompts that raise it, are on Server updates and the launch guard.
Before anything else: from the moment an update starts rewriting the install, every way of starting the server is refused, with one sentence.
An update is running for this install. Wait for it to finish.
That covers Start and Restart on the Dashboard, the button in the header strip, both entries in the command palette, and the automatic paths: a scheduled restart, an empty server restart and a crash relaunch. It is held on the app's side and again by the server host, so a second window or a reloaded page cannot get around it.
The reason is timing. Steam only flags the manifest a good half minute into a run, so before that the launch guard has nothing to see and would happily start the server out of a folder steamcmd is halfway through replacing. And Start anyway on the guard is an explicit override, which would have started it even after the flag appeared.
Update and start does three things in order: copies every world in this profile's save folder aside, runs the update, then starts the server.
The copy aside comes first and it is not optional. Each world is copied as {world}_backup_preupdate-{stamp}, a sibling of the world it came from, and it shows in the Barrow as PRE-UPDATE SNAPSHOT. A chunked world is copied as a folder holding only the last committed generation, and the .ok marker is checked before and after the copy. If a live save landed in the middle, the half copy is deleted and the snapshot fails rather than keeping a mixture.
If nothing gets copied and there was something to copy, the update does not run: "No worlds were copied aside, so the update was not started." That check is new in 1.0.1. Before it, a backup that quietly copied nothing let the start through.
Two things are deliberately not failures. A world that has been created but has never finished a save has nothing in it to preserve, so it is named as skipped and left out of the count rather than failing the pass. And a rolling save, a file pair the game names {world}_{stamp}, is left where it is and named the same way: "Grimhold_20260711-060000 (the game files this under 'Grimhold' as a rolling save, so it is left where it is.)" A world that does have a finished save and cannot be copied is still a hard failure that stops the update.
For a Steam library install, BakaLoader asks the Steam client to do the work, with steam://validate/896660, falling back to steam://install/896660. Then it watches the manifest every 3 seconds, reporting bytes done against bytes total, until the install reads as whole with nothing queued. It gives up after 30 minutes total, or after 5 minutes with no change in the byte count. BakaLoader never runs steamcmd against a Steam library.
For a standalone install, BakaLoader runs its own copy of steamcmd:
+force_install_dir "<install>" +login anonymous +app_update 896660 validate +quit
The output is streamed into the log as it goes.
BakaLoader downloads it once, from Valve's own address, https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip, and keeps it at %LocalAppData%\ValheimBakaLoader\steamcmd\steamcmd.exe. It is BakaLoader's copy. Nothing is ever written into your server install by the download step.
Valve does not publish a checksum for that zip, so two checks stand in for one. The zip must contain exactly one entry and that entry must be named steamcmd.exe. Then the extracted file has to pass Windows itself: BakaLoader asks the operating system to verify the Authenticode signature, and separately checks that the signer's subject contains "Valve". Reading the certificate alone was not enough, because a tampered file can carry a real certificate table and still fail verification. If either check fails the file is deleted and the update refuses with "the downloaded steamcmd is not signed by Valve; refusing it."
steamcmd is run from its own folder, not from BakaLoader's. Its bootstrapper unpacks a copy of the Steam client beside itself on first run, and with no working directory set that landed in whatever folder BakaLoader happened to be started from, which fails outright if that folder is not writable.
One quirk is handled quietly: a freshly unpacked steamcmd updates itself and exits before running the script it was given. BakaLoader notices that (exit code 0, no update lines, no failure) and runs it a second time rather than reporting a success that did nothing.
The condition bar shows the phase and the progress.
Backing up worlds while the copy aside runs, with an indeterminate bar.
Asking Steam to download the update, then Steam is downloading: 412 of 848 MB with a real percentage.
Running steamcmd for a standalone install, with steamcmd's own output going to the log.
Verifying the install, then Update finished. or Update finished. Starting the server.
Hide hides the row. It does not cancel anything.
Stop waiting appears only while BakaLoader is waiting on the Steam client, in the asking and downloading phases. It stops the watching, not the download: "Stop watching for the download. Steam carries on with it." In every other phase the button is disabled and reads Updating. That is not only the interface being careful: the service itself refuses a stop outside those two phases, so a steamcmd run, a worlds backup and the verify pass cannot be called off at all. A half written install is worse than a slow one.
Stopping the wait is a quiet ending, not a failure. The row goes back to whatever notice stood before the update, untouched, and you get one toast:
Update stopped. Steam keeps downloading on its own.
No red row, because nothing went wrong.
The server is not started. The bar goes back to the held start with the reason written across it:
The update did not finish: steamcmd exited with code 8: no subscription. The server was not started. Steam has a Valheim server update waiting (848 MB). Starting now runs the old build, and players who already updated cannot join.
The reasons you can actually get:
"steamcmd could not be set up, so the update did not run." The download failed, or the zip or the signature check did not pass.
"steamcmd stopped with exit code 8." Or whatever code it gave, plus its own last line where there is one.
"Steam did not finish the update in 30 minutes. Open Steam to check." Or "Steam stopped downloading part way through", or "Steam has not started the download", for a library install. The five minute stall clock only starts once bytes have actually moved, so a download Steam has queued but not begun is given the full thirty minutes rather than being failed while Steam works through its own queue.
"An update is already running for this install." One update at a time per install folder, so two profiles pointing at the same server folder cannot both drive steamcmd.
"BakaLoader cannot tell how this server was installed, so it cannot update it for you." Either there is no Steam manifest, so the install was copied here by hand, or the manifest sits somewhere the app does not recognise.
"This is an isolated copy BakaLoader made from "Valheim dedicated server". Update that install, then provision this one again." An isolated profile shares the game files with the install it was made from, so the update belongs there, not here. See Multiple servers.
Closing BakaLoader is refused while an update is running:
An update is running. BakaLoader will close when it finishes.
It closes by itself when the update completes. A second close click within ten seconds insists and closes anyway, unless steamcmd is actually writing files, which is the one phase that will not be interrupted.
Separately, steamcmd is deliberately started outside the job object that ties the server process to the app. So if BakaLoader crashes or is killed from Task Manager mid update, steamcmd keeps running and finishes the install, instead of leaving you with half of one build and half of another.
Update server in the command palette, and the Update available pill on the Dashboard, both go through a shorter question. Title Update the server, body "Back up the worlds before the update?", buttons Back up and update, Update without a backup, Cancel.
The pill is disabled while the server is running, with the tooltip "Stop the server to update". An update needs the server stopped.
Only if event posts are on in the Discord screen.
A held automatic start posts Start Held in amber: "Final Sunset was not started automatically." plus the reason. A start you pressed does not post.
A finished update posts Server Updated in green with the new build id, or Server Update Failed in red with the reason and "The server was not started."
Steam has a 848 MB update for a server installed by steamcmd at D:\vhserver. You press Start.
The prompt says an update is waiting and offers Update and start. You press it.
The bar reads Backing up worlds. Two worlds are copied as Midgard_backup_preupdate-20260910-144012 and Trialgrounds_backup_preupdate-20260910-144013.
The bar reads Running steamcmd, and steamcmd's progress lines appear in the log. When it finishes the toast says "Update finished. Starting the server." and the log records the new build id.
The server starts. The guard does not ask again, because the update already answered the backup question and the profile's recorded build is now the one on disk. In 1.0.0 you were asked twice.