Game server update day checklist

When a game patches, the safe order is always the same: take a backup before anything touches the server, find out whether your mods or plugins work on the new version, update the server files, start it and check it actually loads your world, then tell players it is ready. On a vanilla server that is fifteen minutes. On a modded one it may mean waiting a day for mod authors, and the hard part is resisting the urge to update anyway because players are asking. This checklist covers each step, the order that avoids losing a world, and how to roll back when the update goes wrong.

Why patch day breaks servers#

Almost every multiplayer game requires client and server to run the same build. When Steam updates players' clients, they can no longer join a server still on the old one - they see "version mismatch", "server is outdated" or simply fail to connect. So the pressure to update the server starts the moment the patch drops.

Updating the server, though, can break three things that updating a client cannot:

• Mods and plugins that hook game code. Frameworks such as BepInEx, Oxide and Carbon, SourceMod and Metamod, CounterStrikeSharp, RocketMod and Paper plugins depend on internal game code that patches change. Until their authors catch up, they crash the server, fail to load, or - worst - load and quietly corrupt data.
• The save. Some patches migrate the world format on first load. Once the new server has written to the save, the old server may refuse to read it, which turns a failed update into a lost world unless you backed up first.
• Config files. New versions add, rename or remove settings. A server can start with defaults for a renamed key and run with settings you did not choose without any error.

The rest of this post is about controlling those three.

Before the patch lands#

The best update days are prepared before the patch exists.

Know how your game announces updates. Rust force-wipes and updates on the first Thursday of every month; most games publish patch notes on Steam news shortly before or after; Minecraft releases come with snapshots and pre-releases weeks ahead. Follow the game's announcement channel and the channels of your critical mods.

Turn off automatic updates on modded servers. On a vanilla server, updating on every restart is convenient and mostly safe. On a modded one it means the next scheduled restart after a patch installs a version your mods do not support. Most panels and start scripts have an auto-update switch; for modded servers it belongs off, with updates done by hand. Automating game server updates covers when automation is safe.

Keep a list of what is installed. Mod names, versions and where they came from. When a patch lands you need to check each one, and doing that from memory misses the one that breaks.

Have a test server, if the community is large enough to need one. A copy of production on its own small plan lets you try the update first. Running a test server beside production covers how small it can be.

The checklist#

On the day, in this order:

1. Read the patch notes. Look for words like "save", "world", "format", "server", "config" and "breaking". A balance patch and a save migration are different days.
2. Check your mods and plugins. Look at each critical one's page, GitHub releases or Discord. Has the author said it works on the new version, or released an update? If a critical mod is not updated, stop here and tell players.
3. Tell players what is happening. A short message: the patch is out, the server will update at a time, or it will wait for mods. Players handle a delay with an explanation much better than silence. Announcing maintenance and downtime has wording that works.
4. Stop the server cleanly. A clean stop saves the world. A kill does not.
5. Take a backup now. Not last night's - one taken after the clean stop, so it holds the latest state. Lock it against rotation if your host allows that, so a week of scheduled backups does not push it out.
6. Note the current build. The build id from the server log or SteamCMD (app_status <appid> shows it). You need this to roll back.
7. Update the server files. Through the panel's update or reinstall option, or SteamCMD with app_update <appid> validate.
8. Update mods and plugins to versions that support the new build.
9. Compare config files. If the update shipped new default configs, diff them against yours for new or renamed keys.
10. Start and read the log. Watch it through to the "ready" line. Look for errors from mod loaders, for "creating new world" (which means it did not find yours), and for warnings about unknown settings.
11. Join and check. Log in, look at a known base or build, check an inventory, run an admin command. Five minutes of checking beats an evening of reports.
12. Tell players it is up.

Spotting config changes

Step 9 is the one people skip, and it causes the quietest problems. Games handle a changed config in one of three ways: they add the new key with its default and leave your file alone, they overwrite your file with a fresh default (rare, and nasty), or they read your old file, ignore the key they no longer recognise and carry on. In the last case the server starts, nothing complains, and a setting you relied on has silently stopped working.

The cheap defence is to keep a copy of every config file you have changed, taken before the update, and compare it afterwards. Most panels' file managers let you download a file in one click; on your own machine, diff does the comparison:

$ diff -u serverconfig.xml.before serverconfig.xml

Look for three things in the output: keys that disappeared, keys that appeared with defaults you would not have chosen, and value formats that changed (a number that became a word, a list that became a block). Then check the patch notes or the game's default config for what the new keys do. Five minutes of this after each major patch catches the "why has loot been wrong since Tuesday" report before anyone writes it.

Updating with SteamCMD#

For Steam-distributed servers the update itself is one command. On your own machine:

$ steamcmd +force_install_dir /home/game/server +login anonymous \    +app_update 896660 validate +quit

validate checks every file against Steam's manifest and replaces anything that differs. That is good for repairing a damaged install and bad for anything you edited inside the game's own folders - those edits are reverted. Keep your configuration in the files and folders the game treats as yours, not patched into shipped files.

Afterwards, confirm the build changed:

$ steamcmd +force_install_dir /home/game/server +login anonymous \    +app_status 896660 +quit

Games that need a real Steam login rather than anonymous (Arma 3, DayZ and some others) need the account with the game on it. On a panel, the update is usually a reinstall or a restart with the update switch on; the panel runs the same SteamCMD command underneath. SteamCMD explained covers the flags and the errors.

Non-Steam games

Not everything updates through Steam:

Each has its own rhythm. Minecraft is the extreme case: a new version can mean waiting weeks for Paper and plugins, and many servers stay a version behind deliberately, using ViaVersion to let newer clients connect. Minecraft version upgrades covers that path, and FiveM server updates and artifacts covers FiveM's recommended builds.

When mods are not ready#

This is the decision that defines patch day on a modded server. Your options:

Wait. Keep the server on the old build. Players on updated clients cannot join until it is updated, so the server is effectively down, but the world and mods are safe. For popular mods the wait is often a day or two. Be honest with players about it.

Stay on the old version through a beta branch. Some games publish previous builds as Steam beta branches - 7 Days to Die keeps older major versions available that way, and Valheim has had a public test branch. Players can switch their client to the same branch, and everyone carries on. This only works where the developer offers it, and branch names change; the game's own announcements list them. SteamCMD app ids and beta branches covers how to select one, and game server version pinning and rollbacks covers what can and cannot be pinned.

Update without the broken mods. Disable the mods that are not ready, update, and run with the rest. Safe only for mods that add nothing to the world - a chat filter or a map viewer. Removing a mod that added items, blocks or creatures can delete them from the world or stop it loading.

Update anyway. Occasionally a mod works despite not being marked as updated. Test it on a copy, never on the only world you have.

The wrong answer is the most common one: updating everything at once because players are impatient, finding the server crashes on start, and then trying to fix it under pressure. What to do when a mod update breaks your server is the guide for when that has already happened.

Rolling back#

If the update went wrong, you need two things: the old game build and the pre-update save. The backup you took in step 5 holds the save. The old build is harder:

• On Steam, old builds are available only through beta branches the developer publishes, or by downloading a specific depot manifest with the download_depot command - possible, fiddly, and not something every panel exposes.
• Some panels and backups include the whole server folder, game files and all. Restoring such a backup brings back the old build as well as the save, which is the simplest rollback there is.
• For non-Steam games, keep the previous build's archive until the new one has run cleanly for a week.

Whichever way, restore both together. An old server with a save already migrated by the new version may refuse to load it, and a new server with an old save may migrate it again. Backups that actually restore and testing a restore before you need it are the reason step 5 is not optional.

After the update#

The day after matters too.

• Watch for slow failures. Some breakage shows only under load or after a few hours: memory growing faster than before, a crash when a particular area loads, an item that vanishes on relog. Read the logs the next morning.
• Keep the pre-update backup locked for at least a week, until you are confident nothing went wrong.
• Update your mod list with the new versions, so next time you start from an accurate record.
• Reset the schedule. If you turned off scheduled restarts or backups while you worked, turn them back on. Scheduled tasks worth having lists the ones to restore.
• Note what went wrong. If a mod took a week to update, consider whether you want to depend on it. If the update process was painful, write down the steps that worked for next month.

FAQ#

Why can nobody join my server after a game update?

Because the clients updated and the server did not, so the versions no longer match. Stop the server, back it up, update the server files, and start it again. If you run mods, check they support the new version first.

Should I enable automatic updates on my game server?

On a vanilla server, updating on every restart is reasonable. On a modded server it is risky, because the next restart after a patch installs a version your mods may not support. Update modded servers by hand, after checking.

How long should I wait for mods to update?

Popular, actively maintained mods often update within a day or two. Smaller ones can take weeks or never update. If a mod you depend on is still not updated after a week, plan for running without it.

Can I stay on the old version of a game?

Only if the developer publishes old builds as Steam beta branches or you kept the old files. Players also need to switch to the same branch on their clients. Many games offer no way back at all.

Do I need to wipe the world after an update?

Usually not. Most updates load existing worlds fine. Some major updates recommend or require a new world for new content to generate, and a few force a wipe. The patch notes say so when it matters.