SteamCMD app IDs and beta branches

To install or update a dedicated server with SteamCMD you need two facts: the server's app ID, which is usually not the game's, and the branch you want, which is public unless you say otherwise. The line is always +app_update <server id> -beta <branch> validate, run after +login anonymous or after a login with an account that owns the game. Most broken installs come from one of three mistakes: the game's ID passed where the server's belongs, a branch the clients are not on, or an anonymous login for one of the few servers that refuse it. This post is the reference for all three: a table of IDs, how to read the branches a server actually publishes, and what switching between them does to your files.

If you have never run SteamCMD at all, start with SteamCMD explained, which covers installing it, the order of arguments, scripted updates and the error table. This post assumes that and goes further into the IDs and branches themselves.

Server app IDs and game app IDs#

Steam treats a dedicated server as its own application. It has its own ID, its own depots and its own branches, and it is usually free. The game you play has a different ID. You need both, for different jobs:

• The server app ID goes to app_update. It decides which files land in the install directory.
• The game app ID goes to workshop_download_item, and it is the ID you pick when creating a Steam game server login token, because Workshop content and tokens belong to the game.

Pass the game ID to app_update and one of two things happens. With an anonymous login you get No subscription, because you do not own the game on an anonymous session. With a real account that owns the game, it works, and you have downloaded the full client - textures, sound and all - into a server directory. That second result is the bad one, because it looks like success, uses ten times the disk, and nothing in it starts as a server.

Treat the table as a starting point, not scripture. Publishers occasionally move a server to a new app, split a Windows and Linux build into separate apps, or retire an old one. The authoritative check takes ten seconds, and the next section shows it.

A handful of games in the list do not need SteamCMD at all for their server. Terraria's dedicated server is a zip from the official site, Factorio's headless server is a tarball from factorio.com, and Minecraft's server jar never touched Steam. Searching for their app ID is a dead end; the Terraria and tModLoader server guide and the Factorio headless server guide cover where those come from.

Counter-Strike 1.6 and app 90

HLDS is the oldest thing still served through SteamCMD and it behaves like it. App 90 holds several Half-Life mods, and you choose Counter-Strike with a config line before the update:

$ ./steamcmd.sh +force_install_dir /srv/cs16 +login anonymous \    +app_set_config 90 mod cstrike \    +app_update 90 validate +quit

It is well known for finishing with an error or a partial install the first time. Running the identical command again, sometimes twice more, usually completes it. If you are scripting it, loop until the success line appears rather than trusting one pass. The Counter-Strike 1.6 server guide covers what goes on top of the install.

Finding an app ID and its branches yourself#

SteamCMD can print everything Steam knows about an application, including the list of branches. Run it interactively:

Steam> login anonymousSteam> app_info_update 1Steam> app_info_print 896660

app_info_update 1 refreshes SteamCMD's local cache of app metadata; without it you can get stale or empty output. app_info_print then dumps a large nested block. The part that matters is under depots, then branches:

"branches"{    "public"    {        "buildid"        "19455410"        "timeupdated"    "1758000000"    }    "public-test"    {        "buildid"        "19512002"        "description"    "Public test"        "pwdrequired"    "1"        "timeupdated"    "1758600000"    }}

Each entry is a branch name you can pass to -beta. buildid is the build currently published on it, timeupdated is a Unix timestamp, and pwdrequired set to 1 means you also need -betapassword. The password is never printed; the developer publishes it in patch notes, on their Discord or on the game's wiki. The build IDs above are illustrative - the real numbers change with every update.

SteamDB shows the same data in a browser, with a history of every build, which is the easiest way to answer "when did this branch last change" and "what was the build ID before the patch that broke us". For the server's own ID, searching SteamDB for the game name plus "Dedicated Server" is usually quickest; the result whose type is "Tool" is the one you want.

How branches work#

A branch is a named pointer to a build. The default is public, and it is what everyone gets unless they opt into something else. Developers add branches for three reasons:

1. Testing builds - latest_experimental, experimental, public-test, unstable, staging. Ahead of public, less tested, sometimes save-incompatible.
2. Old versions - a branch kept at a previous release so communities can stay on it while mods catch up.
3. Platform or technical variants - a 64-bit build, a profiling build with extra diagnostics, a build carrying paid DLC content for servers.

The command is the same for all of them:

$ ./steamcmd.sh +force_install_dir /srv/valheim +login anonymous \    +app_update 896660 -beta public-test -betapassword yesimadebackups \    validate +quit

That example is real: Valheim's public test branch has for years used the password yesimadebackups, a joke with a point. Iron Gate change test builds in ways that can break worlds, and they want you to have copied yours first.

Branches you will meet by name

Branch names do change. Project Zomboid's arrangement in particular has moved as Build 42 progressed towards stable, and 7 Days to Die has named its old-version branches differently across eras (alpha numbers, then version numbers after 1.0). Use app_info_print to see the current list rather than copying a name from a two-year-old forum post.

DayZ handles its test builds differently: the experimental server is a separate application, 1042420, rather than a branch of 223350. Experimental clients connect only to experimental servers, so this is a whole parallel install, not a flag.

Matching clients to the server#

A server on a branch only accepts clients on the same build. Players opt in from their Steam library: right-click the game, Properties, Betas, pick the branch from the drop-down, and enter the password if there is one. Steam then downloads the branch's client build.

This is where most branch trouble actually happens, and it rarely announces itself as a branch problem. The client reports "incompatible version", "version mismatch", or simply times out, and the player swears they updated. They did - to public. Three habits avoid an evening of this:

• Name the branch in your server's name or MOTD while you are on it, so nobody has to guess.
• Pin a message with the exact steps and the password before you switch.
• Switch back deliberately. When the test branch is merged into public, both sides need to go back, and players who forget stay on a branch that has just moved on to the next test build.

Test branches also get updated without warning, sometimes several times a day during a busy week. A server that updates on every restart will follow them; clients follow them as soon as Steam notices. The two will briefly be on different builds at some point, so expect the occasional "version mismatch" on test branches and do not treat it as a fault.

What switching does to your files#

SteamCMD treats a branch switch as an update to a different build. It downloads the chunks that differ and replaces the files that changed. A few consequences are worth knowing before you do it on a server people care about.

Your saves are not touched by the switch, but they are touched by the next start. SteamCMD only manages files that belong to the application. World saves, player data and configs that the server generates are outside its manifest. The danger is what the new build does to them on load: many games upgrade a save in place when a newer version opens it, and the upgraded save will not open on the old build again. Copy the save folder before switching, not after - game server save files explained lists where each game keeps them.

Files you edited may be reverted. If you changed a file the application ships, such as a launch script or a default config, the branch switch replaces it if the new build's version differs. validate replaces it even if it does not. Keep your changes in files the server generates, or keep copies.

Files from the old branch can be left behind. Files that existed only in the old build are usually removed, but not always, and a stale DLL or asset from an experimental build can cause strange crashes on public. If a server misbehaves after switching back, a validate pass is the first fix. If that does not help, delete the install (not the saves) and reinstall the branch cleanly.

SteamCMD records the branch. The install's steamapps/appmanifest_<id>.acf holds the installed build ID and, when you are on a beta, the branch name in its user config section. Reading it is the quickest way to confirm what a server is actually on. Do not rely on SteamCMD remembering the branch for later updates: its behaviour here has varied between versions, and an update line without -beta has been known both to keep a server on its branch and to move it back. Always pass -beta explicitly, including -beta public when you mean the default.

Pinning a version and rolling back#

There is no SteamCMD argument for "install build 18000000". Older releases can be reached in three ways, in order of preference:

1. A version branch the developer publishes. If 7 Days to Die or Arma 3 keeps a branch at the previous release, -beta <that name> is the supported route back, and clients can follow you onto it.
2. Your own copy. Before every update, archive the install directory (or let a backup do it). A rollback is restoring that archive and not running app_update until you are ready. This works for any game, and it is the only option when no version branch exists.
3. Depot downloads. SteamCMD has a download_depot command that fetches a specific manifest of a specific depot, using IDs you look up on SteamDB. It works, it is fiddly, it only gets you files rather than a managed install, and it is usually blocked for anonymous logins on paid content. Treat it as a last resort.

The practical consequence is that a server you care about should not update itself unattended on patch day. A popular game patch breaks mods and plugins for hours or days, and the only easy way back is the copy you took before. The full routine for that is in what to do when a mod update breaks, and the mechanics of automating updates safely are in scheduled tasks worth having.

Anonymous login and the servers that refuse it#

Most server tools are free to download anonymously, which is why +login anonymous appears in almost every guide. A minority are tied to game ownership:

• DayZ (223350) and Arma 3 (233780) need an account that owns the game, both for the server and for Workshop downloads. Anonymous gives No subscription.
• Workshop content for many games needs an owning account even when the server itself is anonymous. The rule is per game and has changed over time, so if an anonymous workshop_download_item fails with an access error, that is the reason.
• Download-depot requests for paid apps need an owning account.

Some hosts also ask for a Steam login for games that are anonymous on paper, because their install also pulls Workshop items or a branch that is gated. On RE:NODE, Arma 3, DayZ, Project Zomboid and 7 Days to Die ask for your Steam login: the server is created straight away and the install waits on the Setup tab until you supply it. The credentials are stored as you typed them, so use a spare account that owns the game and nothing else - never the account you buy things with.

Steam Guard needs to be satisfied once, interactively, on the machine doing the install. After that SteamCMD caches a login token in its own config directory and later runs are unattended. That cached token is what makes an unattended update work, and it is also why the account should be one you would not mind losing.

Troubleshooting IDs and branches#

`No subscription` with anonymous login. Either the ID is the game rather than the server, or the server requires an owning account. Check the ID against app_info_print first; it is the cheaper mistake.

`Invalid Password` or the branch silently not applying. The -betapassword is wrong or out of date. Developers rotate them. Check the current one in their announcements.

The update finished but the server is still on the old build. Compare the build ID in appmanifest_<id>.acf with the branch's buildid from app_info_print. If they match, Steam has not published the patch for the server yet; client and server updates are not always released in the same minute, and some publishers push the server an hour or more later.

`Invalid Platform`. The branch or app has no build for your operating system. Several servers are Windows-only; Linux vs Windows game servers lists them, and Wine and Proton for Windows-only servers covers the workaround.

Clients cannot join after you switched branch. Almost always a client still on public. Confirm the build the client shows in its main menu or console against the server's.

A clean `public` install crashes after a stint on experimental. Stale files. Run with validate, and if that fails, reinstall into an empty directory and copy the saves back.

FAQ#

Is the server app ID ever the same as the game's?

Occasionally. Counter-Strike 2 is the main example: the server installs from 730, the game's own ID. For almost everything else the dedicated server is a separate tool with its own number, and using the game's ID either fails or downloads the full client.

Do I need the beta password on the client too?

Yes. The player enters the same password in the game's Betas properties in Steam to unlock the branch. Without it, their client stays on public and cannot join a server on the test build.

Will switching to an experimental branch break my world?

The switch itself does not touch saves. Loading the world on a newer build often upgrades it in place, and an upgraded save may not load on public again. Copy the save folder before switching, and keep that copy until you have returned to public and played on it.

How do I go back from a beta branch to the normal release?

Run the update again with -beta public and validate. Pass public explicitly instead of leaving the flag out, then check the build ID in the app manifest to confirm the switch happened.

Why does my scripted update stay on the old version after a patch?

Either the publisher has not released the server build yet, or the script is pinned to a branch you forgot about. Print the branches with app_info_print and compare their build IDs with the one in your manifest.

Can I run two branches of the same game side by side?

Yes, in two install directories. Each force_install_dir is independent, so a test server on latest_experimental and a live server on public can share a machine, as long as they use different ports and different save folders.