Valheim public test branch on a dedicated server

To run Valheim's public test build on a dedicated server, install the server's public-test beta branch with the password Iron Gate publishes - historically yesimadebackups - into a separate folder, point it at a copy of your world in a separate save directory, and have every tester switch their own game to the same branch in Steam. Test servers and release servers cannot see each other: a player on the test build cannot join a normal server, and the other way round. When the test is over, players opt out in Steam and you simply go back to the untouched release install. The one thing never to do is open your real world on a test build, because a world saved by a newer version may not load on the older one.

This post walks through the whole cycle: what the test branch is for, installing it with SteamCMD, the Steam client, Docker or a panel, setting up a disposable copy of the world, what happens to mods, and getting everyone back to stable without losing anything.

What the public test branch is#

Before a large update, Iron Gate puts it on a Steam beta branch called public-test for players who want to try it early and report bugs. The test can run for days or weeks, and the build on it changes during that time - sometimes several times a week - before the final version goes to everyone.

That matters for a server in three ways:

• Versions must match exactly. The test client only talks to a test server of the same build, so every patch to the test branch means updating both the server and every client.
• Saves may change format. A big update can change how worlds and characters are written. Once a world has been saved by the test build, the release build may refuse it or behave oddly with it until the update reaches release.
• Nothing is final. Content, balance, world generation in new areas and bugs are all subject to change. What you build in the test can be invalidated by the next test patch.

Iron Gate's own advice is in the password: back up first. Test branches are for curiosity and for checking that your group's setup survives the patch - not for playing your main campaign.

Why a server owner bothers

Two good reasons. First, to find out before release whether a big patch breaks anything on your world - a base in a newly changed biome, a portal hub, a heavily terraformed area. Second, and more commonly, to give mod authors' updates a head start: if your group runs mods, the test period is when you learn which ones will break, so that release day is not a surprise. A bad reason is to play the new content early with your whole group on your real world. That is how worlds end up stuck on a version nobody can run.

Before you start: back up the world and characters#

Do this even if you intend to use a copy, because the copy is made from the original and a slip with paths can open the original instead.

1. Stop the release server cleanly so the world on disk is current. Wait for the save line in the log.
2. Copy both world files - Name.db and Name.fwl - out of worlds_local to somewhere outside the server's folders. Include the .old files if you want the previous save too.
3. Take a full backup through your usual method, not just the copy. On a panel, that is an on-demand backup, ideally locked so rotation cannot remove it.
4. Tell every tester to back up their characters. Characters live on each player's machine, not on the server, and the test client writes them in whatever format the test build uses. On Windows they are .fch files under %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\characters_local\, or in Steam Cloud under characters.

The character backup is the one people forget. A world copy protects the world; nothing on the server protects a player's character from being saved by a test client. Where save files live on each platform is in savedir and file locations, and the reasons to have a restore that actually works are in Valheim server backups and world corruption.

Installing the test build of the server#

The dedicated server (896660) has its own beta branches, separate from the game client's. Use a separate install directory so the release install is never touched.

With SteamCMD on Linux:

$ steamcmd +force_install_dir /home/valheim/ptb \    +login anonymous \    +app_update 896660 -beta public-test -betapassword yesimadebackups validate \    +quit

The -beta flag selects the branch, -betapassword unlocks it, and validate checks every file. Re-run the same line to pick up each new test patch. Check the current branch name and password in Iron Gate's announcement for the test before you use them; they have been stable for years, but they are Iron Gate's to change. SteamCMD app IDs and beta branches explains how the beta flags work across games.

On Windows with the Steam client, the dedicated server appears under Tools in the library as "Valheim Dedicated Server". Right-click it, open Properties, then Betas, enter the code, and select public-test. Steam then downloads the test build into the same folder as your release server, which is exactly what you want to avoid. If you go this way, copy the release server folder somewhere first so you have both, or install the test build with SteamCMD into its own folder instead.

With the lloesche/valheim-server Docker image, extra SteamCMD arguments go in an environment variable. Run a second container with its own volumes rather than reconfiguring your main one:

SERVER_NAME=Ravenhold PTBWORLD_NAME=MidgardTestSERVER_PASS=spare-anvil-03SERVER_PUBLIC=falseSTEAMCMD_ARGS=-beta public-test -betapassword yesimadebackups validate

The variable name and its default have changed over the image's life, so confirm it in the image's README. Valheim in Docker covers the volumes.

On a panel host, the clean approach is a second server for the test, not switching your main one. If the panel's Valheim install has a beta or branch variable on the Startup tab, use it there; if not, it may be possible to run the SteamCMD command yourself, but that depends on the host. On RE:NODE, ask support before changing the branch of your main server; a separate, cheap test server keeps your real world entirely out of reach.

Running the test server on a copy of the world#

The test server should be its own island: its own install, its own save directory, its own port, and ideally its own world name.

$ cd /home/valheim/ptb$ ./valheim_server.x86_64 -nographics -batchmode \    -name "Ravenhold PTB" -port 2466 -world "MidgardTest" \    -password 'spare-anvil-03' -public 0 \    -savedir /home/valheim/ptb-saves -logFile /home/valheim/logs/ptb.log

What each choice is protecting against:

To use a copy of your real world, rename the copied pair to match the test world name - Midgard.db becomes MidgardTest.db, Midgard.fwl becomes MidgardTest.fwl - and put them in worlds_local inside the test save directory. Then start the test server and look for Load world: MidgardTest in the log. If it says it is generating a new world, the file names did not match. Renaming the pair works because the world name in -world is matched to the file name; if your version also stores a name inside the .fwl and complains, create the test world from scratch with the same seed instead.

Two servers on one machine need separate ports and separate save directories, and on a crossplay setup each gets its own join code. The longer version is in several worlds on one host, and the port arithmetic - each server uses its port and the one above - is in Valheim ports 2456-2458.

Copy the admin list across if you want admin rights on the test server: adminlist.txt, bannedlist.txt and permittedlist.txt live in the save directory, so a new -savedir starts with none.

Getting testers onto the test build#

Every tester switches their own game. In Steam: right-click Valheim, Properties, Betas, enter the code, select public-test. Steam downloads the test build, and from then on the game starts on it until they switch back.

Things testers should know before they do it:

• They cannot join the normal server while on the test build. Pick a test evening, rather than switching back and forth.
• They must stay current. When the test branch updates, Steam updates the client, and the server needs updating too. The log's version-mismatch line prints both numbers and tells you which side is behind.
• Console and Game Pass players usually cannot join. Public tests have historically been on Steam. Expect a test server to be Steam-only even if your main server runs crossplay, and check the announcement for the test you are running.
• Characters should be backed up first, or a fresh character used.

If a tester gets "Incompatible version", one of the two is on the wrong branch or a patch behind. Updating the server and version mismatch covers the error in general.

Mods on the test branch#

BepInEx itself usually survives a game patch; many of the mods on top of it do not. A public test is the best early warning you will get.

1. Install the mods on the test server and on test clients exactly as on the release setup. If your group uses an r2modman profile, export it and import a copy for the test, so the release profile is untouched - see Thunderstore and r2modman for groups.
2. Start the server and read the BepInEx output. Plugins that fail to load usually say so at start-up. Note which ones.
3. Play the parts the mods touch. A mod can load cleanly and still break when its feature is used - crafting, a custom creature, a portal rule.
4. Check the mod pages and issue trackers. Authors often post test-branch status, and some publish updates that target the test build before release.

The output of this is a list: which mods work, which break, which have a fix pending. On release day that list tells you whether to update the release server immediately or hold it on the old version until the broken mods catch up. What to do when a mod update breaks is the general playbook.

Rolling back to stable#

If you followed the separate-install advice, there is almost nothing to roll back. The release server was never changed; stop the test server, and the testers opt out in Steam - Properties, Betas, select "None" or the default branch - and Steam downloads the release build. Then they can join the release server as before.

If you switched an install in place, move it back to the default branch with SteamCMD:

$ steamcmd +force_install_dir /home/valheim/server \    +login anonymous \    +app_update 896660 -beta public validate \    +quit

-beta public names the default branch. SteamCMD's handling of switching back has varied over the years; if after this the server's version line still shows the test build, delete the install folder (not the save directory) and install fresh without any -beta flag. The install is about 2 GB and takes a few minutes; the world is not in it.

The world is the harder question. Rolling back the binary does not roll back the save:

• If the real world was never opened on the test build, nothing to do.
• If it was, the release build may refuse to load it, or load it with problems. Restore the backup taken before the test. Progress made during the test is lost; that is the cost.
• If you want the test world's progress, you have to wait until the update reaches release, then load that world on the updated release server. Keep the test world files safe until then.

Characters work the same way. A character saved by the test client may only be usable again once the release build catches up. That is why testers restore their character backups when they leave the test, or use a test-only character from the start.

When the test ends#

When the update goes to release, the test branch typically follows it to the same version, and test clients can usually rejoin normal servers once both are updated. Do not assume a test world can simply replace your main one: the test may have generated new areas under early rules, and test patches may have left objects in states the release version handles differently. Keep the main world, update the release server, and archive the test world - or keep it running for a while as a sandbox if anyone liked it.

On RE:NODE a second, small Valheim server makes a reasonable test bench: backups are on every plan and restore with a button, a locked backup is safe from rotation during the test, and the test server's console shows the version line, BepInEx output and join code without needing shell access. Delete it when you are done, remembering that deleting a server deletes its backups too.

FAQ#

What is the Valheim public test password?

Historically yesimadebackups, for the public-test branch, on both the game and the dedicated server. Iron Gate publishes it with each test announcement; check the current one before using it, since it is theirs to change.

Can players on the release version join a public test server?

No. The client and server must be on the same build, and the test build is a different version. Players have to switch their game to the public-test branch in Steam to join, and switch back to join normal servers.

Will testing break my world?

Only if you open the real world on the test build. A world saved by a newer version may not load on the older release build. Test on a copy in a separate save directory and the real world is never touched.

Can Xbox players test with us?

Public tests have historically been Steam-only, so a test server is usually PC-only even if your main server runs crossplay. Check the announcement for the specific test.

How do I go back to stable after testing?

Testers select the default branch in Steam's Betas tab. On the server, either switch back to the untouched release install or run app_update 896660 -beta public validate. Then restore the pre-test world backup if the real world was opened on the test build.