Automating game server updates safely

Automate updates on vanilla servers and do them by hand on modded ones. A vanilla Steam game server can safely update itself on every restart, because the server must match the clients and the clients update themselves the moment a patch lands; leaving the server behind just locks everyone out. A modded server is the opposite case: a game patch routinely breaks mods, and an automatic update at four in the morning means a server that will not start when people arrive after work. Between those two sit the details - when to run validate, how to schedule the update so it does not land mid-session, how to know it worked - and that is what the rest of this post covers.

What SteamCMD itself is and how its arguments work is in SteamCMD explained. This post assumes you know the install line and are deciding how often to run it, and with what safeguards.

Why game servers need updating at all#

A dedicated server has to run exactly the same game version as the clients connecting to it. For most Steam games that is enforced: the client sends its build number when it connects and the server refuses anything else, usually with an unhelpful message like "Incompatible version" or "Server is running a different version". When the developer pushes a patch, every player's Steam client downloads it within hours, and from that moment the old server cannot be joined.

So for most games the question is not whether to update but how quickly. The exceptions are worth knowing:

• Minecraft Java does not update anything automatically, and players choose their client version in the launcher. A server on 1.21.1 stays joinable by 1.21.1 clients indefinitely, and plugins such as ViaVersion let newer clients connect to an older server.
• Factorio lets players pick an older game version in Steam's betas tab and does not force updates on anyone, so a server can stay on a version as long as the group agrees.
• FiveM separates the server build (the "artifact") from the game. Clients connect to whatever the server runs, within the range of builds the platform still supports.
• Terraria clients update through Steam, but the dedicated server is a separate download, so somebody has to fetch the new one by hand.

Everything else - Valheim, Rust, Palworld, Project Zomboid, 7 Days to Die, Counter-Strike 2, Unturned, Satisfactory, DayZ, Arma 3 - needs the server on the same build as the clients, and a delay of a day means a day with nobody able to join.

Update on restart: the default for vanilla servers#

The simplest automation is to run the update every time the server starts. On your own machine, that means the start script calls SteamCMD before launching the game:

#!/bin/shset -e/home/steam/steamcmd/steamcmd.sh +force_install_dir /srv/valheim \    +login anonymous +app_update 896660 +quitcd /srv/valheimexec ./valheim_server.x86_64 -nographics -batchmode \    -name "Longship Crew" -port 2456 -world "Midgard" -password "$PASS"

On a panel built on Pterodactyl, most Steam game eggs offer the same behaviour as a startup variable - commonly a switch called something like auto-update - that runs SteamCMD before every boot. The name and default differ between eggs, so check the Startup tab on your own server rather than assuming.

Update on restart works well for vanilla servers for three reasons. SteamCMD only downloads changed chunks, so a restart with no update available adds a few seconds. The update happens at a moment the server is already down, so it costs no extra interruption. And a nightly restart, which many servers already have, becomes a nightly update check as a side effect.

Its weakness is that it is unconditional. It runs on a crash restart at three in the afternoon just as readily as on the scheduled one at five in the morning, so a patch released at noon is applied the next time the server happens to stop - which may be mid-raid. For most vanilla servers that is fine, because the alternative is a server nobody can join anyway.

When not to update automatically#

Turn automatic updates off when any of these is true:

1. The server runs mods or plugins that hook game code. BepInEx on Valheim, Oxide or Carbon on Rust, UE4SS on Palworld, Harmony mods on 7 Days to Die and Rimworld, DayZ script mods, Unturned's RocketMod. These patch the game's own code at runtime, and a patch to the game moves the code they are patching. The mod either fails to load or, worse, loads and corrupts something.
2. The server is on a pinned or beta branch on purpose. An automatic update with the wrong branch argument switches you back to public.
3. The world format changes with the update. Major updates sometimes convert the save on first load. Once converted, it rarely loads in the old version. You want a backup taken by hand the minute before that happens.
4. A competitive event is running. A tournament weekend is not the time to discover a patch changed a cvar default.

For these servers, the procedure is the one in the update day checklist: read the patch notes, wait for the mod authors, take a locked backup, update a test copy first, then the real server.

Validate: what it fixes and why not to run it every time#

validate makes SteamCMD hash every file in the installation and replace anything that does not match the published manifest. It is the right tool after:

• an update that was interrupted - the disk filled, the container was killed, the connection dropped;
• a crash at startup with errors about missing or corrupt game files;
• a developer instruction to verify files after a botched patch.

It is the wrong tool on every restart, for two reasons. On a large install - Arma 3, DayZ and Rust each run to tens of gigabytes with their content - hashing everything reads the whole install from disk and can add minutes to every boot. And validate reverts any file the application shipped that you have edited: a launch script, a default config file in the install directory, a modified .json the game ships and you tuned. The edit is silently replaced with the original.

The pattern that works is plain update on every restart, and validate only when something is wrong:

app_update 896660            # normal: changed files onlyapp_update 896660 validate   # repair: hash and replace everything

Where your edits live matters here. Most games write their own config files on first start, into a save or config folder outside the install - those are safe from validate. A few expect you to edit a file inside the install directory; keep a copy of those somewhere validate does not reach, or re-apply them after a repair.

Scheduling the update so it does not land mid-session#

The better pattern for an active community is to make updates happen at a time you choose. On RE:NODE that means the Schedules tab: a cron expression and an ordered list of tasks with delays - console command, backup, power action. A nightly update-and-restart for a vanilla server with update on restart enabled looks like this:

Cron     0 5 * * *Task 1   command  say Restarting for updates in 5 minutes      (delay 0)Task 2   command  say Restarting in 1 minute                   (delay 240 s)Task 3   command  save                                         (delay 60 s)Task 4   backup                                                (delay 30 s)Task 5   power    restart                                      (delay 60 s)

The restart triggers the update, the backup before it means a bad patch can be undone, and the warnings mean nobody is surprised. Substitute the right save and broadcast commands for your game; scheduled tasks worth having lists them, and cron expressions explained covers the cron syntax and time zones.

Two refinements are worth adding on a busy server:

• Check before you restart. If you run your own machine, compare the installed build with the latest one and skip the restart when they match. The installed build is in steamapps/appmanifest_<appid>.acf as "buildid"; the latest is printed by +app_info_update 1 +app_info_print <appid> under branches then public. The output format of app_info_print is not a stable interface, so treat a script that parses it as something to check after each SteamCMD update.
• Do not fight the restart policy. A schedule that restarts every night and a plugin that also restarts the server on a timer will overlap sooner or later. Pick one.

Knowing that an update worked#

An update that failed silently looks exactly like one that succeeded: the server starts, on the old version, and players get a version mismatch. Three checks catch this.

1. SteamCMD's success line. A completed update prints Success! App '<appid>' fully installed.. Errors such as Error! App '<appid>' state is 0x202 after update job. (commonly disk space) or 0x6 / 0x602 (a stalled download) mean it did not. If you script updates, look for the success line rather than trusting the exit code, which has not always been reliable.
2. The game's own version line. Nearly every server prints its version early in the startup log. Valheim prints a Valheim version: line, Minecraft prints Starting minecraft server version, Source games print a build number in response to version. After an update, check it changed.
3. One real join. A client joining is the only check that proves client and server agree.

$ grep -E "Success! App|Error! App" steamcmd-update.logSuccess! App '896660' fully installed.

When an update fails on a panel server, the first thing to look at is disk space. SteamCMD stages new files on the same volume before swapping them in, so it needs free space roughly equal to the changed content on top of the installed game. A disk at 95% is a disk whose next big patch fails - see game server disk space full for what to clear.

Games that do not use SteamCMD#

A fair number of popular servers have their own update path, and an update-on-restart switch for SteamCMD does nothing for them.

For Minecraft, a Paper build update within the same Minecraft version is usually a bug fix and safe to apply on a schedule - though the occasional build changes behaviour plugins rely on. A move between Minecraft versions, 1.21.4 to 1.21.5 for example, converts the world on first load and can break half your plugins. That is always a manual, backed-up operation, covered in Minecraft version upgrades. For FiveM, the safe update path is in FiveM server updates and artifacts.

Workshop content updates too#

Steam Workshop mods update on their own schedule, independently of the game, and a server that downloads Workshop items on start will pick up a new mod version at the next restart whether or not you wanted it. This is a quieter version of the same problem: a mod author pushes a change, the server restarts at night, and in the morning the server crashes on load, or clients cannot connect because their copy of the mod has not updated yet.

Different games handle this differently. Project Zomboid checks Workshop items when a player joins and kicks players whose versions differ; Garry's Mod, Arma 3 and DayZ fetch Workshop content through SteamCMD or the game's own loader. The general defence is the same as for the game: an evening update window, a backup before it, and a test server for anything with a long mod list. Steam Workshop mods on dedicated servers covers how each game fetches content and where it caches it.

A sane policy, by type of server#

Putting it together:

The heavy-mod row is where most of the work is, and where a second server pays for itself. Running a test server beside production covers setting one up, and game server version pinning and rollbacks covers how to stay on an old build or go back to one when an update cannot be undone any other way.

FAQ#

Should I turn on auto-update for my game server?

Yes for a vanilla server, because the clients update themselves and a stale server is unjoinable. No for a server with mods that patch game code, because the next game patch will break them and you want to choose when that happens.

Does update on restart slow down every restart?

Only slightly when nothing has changed - SteamCMD compares manifests and exits. It is validate that is slow, because it reads every file. Leave validate off for routine starts.

Why did my server update but players still see a version mismatch?

Either the update failed and the server started on the old build, or the server and clients are on different branches. Check the version line in the startup log, then check whether a beta branch is set on one side and not the other.

Can I delay an update until the mods are ready?

Only for games that let you. Steam games force clients onto the new build, so delaying the server means nobody can join. Some publishers keep the previous version available as a beta branch, which lets you run it for a little longer with players who switch their own client to the same branch.

What happens if the server restarts while an update is downloading?

The update is interrupted and the install is left partly updated. The next start usually resumes it, but if the server then fails with missing or corrupt files, run one update with validate to repair it.