How to Update a Rust Server on Forced Wipe Day

Once a month every Rust server has to take the same update on the same evening, and every map has to go. The steps themselves are short. What goes wrong is the order: updating while the server runs, wiping before the update, starting with an old Oxide, or waiting on a build that is not out yet while players already have the new client.

This guide covers a server run by systemd on your own Linux machine, with the paths Panelra uses (/opt/rust-servers/instance-1). The build ids and timings come from our Ubuntu test host.

When the update lands

Facepunch releases the monthly update on the first Thursday of the month at 19:00 London time. London time is fixed, so the UTC time moves with British Summer Time:

Our Rust wipe schedule lists the next twelve dates with the time in UTC, UK, US Eastern and CET.

19:00 is when the patch is due, not a promise. Some months the build appears later. Do not script "update at 19:00 sharp": check for the new build, and only start the maintenance once it exists.

Why you cannot wait

Steam updates your players' clients on its own. As soon as their client is on the new build, they can only join servers on the same protocol version. A server still on last month's build turns them away with a protocol mismatch, usually shown as "Wrong Connection Protocol: Server update required!". The reverse also happens: a player whose client has not updated yet sees "Client update required!" on your new server, and updating the game in Steam fixes that on their side.

So the update is not something to do tomorrow. Every player whose client updates is locked out of your server until you update it too.

Before the patch

Do this in the afternoon, while the old build is still live:

• Announce the time. Players plan around wipes. Post the forced wipe time and whether blueprints go too.
• Back up the identity folder. server/<identity>/ holds the map, the save and the player databases. Copy it off the host.
• Note the current build. You will compare against it later:

RUST_DIR=/opt/rust-servers/instance-1
STEAMCMD=/opt/rust-servers/steamcmd/steamcmd.sh
grep '"buildid"' "$RUST_DIR/steamapps/appmanifest_258550.acf"

• Pick the new seed if you are not keeping it, between 1 and 2147483647, and have it ready for server.cfg.

Check that the new build is out

api.steamcmd.net mirrors Steam's app info as JSON. This prints the latest build on the public branch:

curl -fsS https://api.steamcmd.net/v1/info/258550 \
  | jq -r '.data."258550".depots.branches.public.buildid'

When that number is higher than the buildid in your manifest, the patch is out. On 28 September 2026 it returned 25454815 for public, and the same JSON lists the other branches too (staging, release, last-month and more).

The order that works

1. Warn players, then save over RCON.
2. Stop the server and wait until the unit is really down.
3. Update with SteamCMD.
4. Reinstall Oxide, or let Carbon update itself later.
5. Wipe the map (and blueprints, if you choose).
6. Start.

The reason for this order: SteamCMD must not replace files under a running process, and a wipe done while the server runs gets undone by the next autosave or the save on shutdown. Oxide has to go on after the update, because the update is what removes it. The wipe comes last before the start so nothing writes a world back in between.

1 and 2: warn, save, stop

systemctl stop rust-server
systemctl show -p ActiveState --value rust-server

Wait until the second command prints inactive (or failed). deactivating means the process is still writing to disk. On our test host the stop took 7 seconds.

3: update with SteamCMD

"$STEAMCMD" +force_install_dir "$RUST_DIR" +login anonymous +app_update 258550 validate +quit

This is the command from the Facepunch wiki. validate makes SteamCMD check every game file against Steam's copy and replace anything that differs. That is what you want on update day: a clean, complete build. It is also why Oxide disappears, see below.

The size of the download depends on the patch. A routine staging patch on our test host was 113 MB and SteamCMD finished in 19 seconds; forced wipe patches are usually bigger. The whole install is about 6.1 GB on disk, so keep that much free space plus room for the download.

If SteamCMD fails halfway (network, Steam hiccup), run the same command again.

4: Oxide or Carbon

Oxide works by replacing Assembly-CSharp.dll and other game assemblies in RustDedicated_Data/Managed with patched copies and adding its own Oxide.*.dll files. The validate in step 3 puts the vanilla DLLs back, so after every update the server boots as plain Rust with no plugins until you reinstall. The Facepunch wiki says it directly: Oxide comes out with an update shortly after each server update, and "you must do this every time".

cd "$RUST_DIR"
curl -sL -o oxide-rust.zip https://github.com/OxideMod/Oxide.Rust/releases/latest/download/Oxide.Rust-linux.zip
unzip -o oxide-rust.zip -d "$RUST_DIR"
rm oxide-rust.zip

The Oxide release has to be the one built for the new Rust build. Compare latest_release_version and latest_release_at in https://umod.org/games/rust.json with the time the Rust patch landed. If the new Oxide is not out yet, you have two choices: open vanilla and reinstall Oxide when it appears, or keep the server closed until then. How to install Oxide on Linux has the details.

Carbon does not patch the game DLLs. It is loaded through the doorstop preloader from carbon.sh, and its files are not part of the Steam depot, so the update leaves it in place. On our test host a validate update replaced Assembly-CSharp.dll and left carbon.sh and libdoorstop.so untouched. On the first start after the Rust update, Carbon checks for a matching build and updates its own files. On the production build it only moves to the new protocol once Rust itself is updated, which is why it goes after step 3. If you switched self-updating off in carbon/config.json, extract the new Carbon archive now instead. See how to install Carbon on Linux.

5: wipe

With the server still stopped, delete the map and save files from the identity folder, plus the blueprint databases for a full wipe:

cd "$RUST_DIR/server/<identity>"
rm -f -- *.map *.sav *.sav.[0-9]*
# full wipe only:
rm -f -- player.blueprints.*.db player.blueprints.*.db-wal player.blueprints.*.db-shm

Set the new server.seed in server.cfg if you are changing it. How to wipe a Rust server lists every file in the folder and what each wipe type does to it.

6: start and watch

systemctl start rust-server
journalctl -u rust-server -f

A new map has to be generated on the first start. On our 4 vCPU test host that took about 8 minutes from Started to Server startup complete. For comparison, a start after an update on an existing map took under 2 minutes. A long silence during map generation is normal; do not restart the server because it looks stuck.

Verify the build

The installed build is in the Steam manifest:

grep -E '"(buildid|TargetBuildID|BetaKey)"' "$RUST_DIR/steamapps/appmanifest_258550.acf"

On our test host after an update this printed:

	"buildid"		"25582902"
	"TargetBuildID"		"25582902"
		"BetaKey"		"staging"
		"BetaKey"		"staging"

What to check:

• buildid matches the latest build from api.steamcmd.net for your branch. If it still shows the old number, SteamCMD did not update; run it again and read its output.
• BetaKey shows which branch the install follows. Ours says staging, because the test host runs the staging branch. A public server should not show staging here. If it does, you are not running the build your players have.
• Framework loaded. On Oxide, run oxide.version over RCON. On Carbon, run c.version. An unknown command means the server is running vanilla.

Then join the server yourself with an updated client before you announce it.

The staging branch caveat

The staging branch is a different game for your players, not an early copy of the same one. Facepunch calls it "essentially the experimental build", and players reach it by launching the separate "Rust - Staging Branch" app in Steam. A staging server only accepts staging clients, and a public server only accepts public clients.

To run staging, add -beta staging after +app_update 258550:

"$STEAMCMD" +force_install_dir "$RUST_DIR" +login anonymous +app_update 258550 -beta staging validate +quit

Things to know:

• It updates far more often. On 28 September 2026 our staging test host went from build 25581777 to 25582902, and the branch had moved on to 25583886 within the hour. Public was still on 25454815.
• Staging wipes follow their own calendar. Facepunch says staging map wipes happen one week before regular Rust.
• Going back to public needs the branch named. The Facepunch wiki warns that once you move up in build id, you have to request the public branch to get back to the default build. Run app_update 258550 -beta public validate and check BetaKey again. The wiki's other option is to delete the steamapps folder and install again.
• Mods are built per branch. The Oxide latest link above targets the public build. Check the framework's own releases before running it on staging.

Common mistakes

• Updating in a start script. A SteamCMD call in ExecStartPre or a wrapper runs on every start. The wiki notes this "will always keep your files vanilla" on Oxide servers, and a crash restart during the patch window updates you with nobody watching.
• Wiping before the update. It works, until the update fails and you are left with a wiped server on the old build. Update first.
• Starting before Oxide matches. The server starts, plugins do not load, and players spawn on a fresh map without your kits, shops or protections.
• Not waiting for inactive. A server that is still shutting down can write the old world back after you deleted it.

To schedule all of this with a script and a systemd timer instead of doing it by hand, see how to automate Rust server wipes.

What Panelra automates

Panelra runs forced wipe day without you at the keyboard:

• Patch detection. On the first Thursday, from 16:00 UTC, Panelra checks for a new public build every 90 seconds until the forced patch is seen. The rest of the month it checks hourly.
• Update and wipe as one job. When the build appears, the server gets a 5 minute in-game countdown with warnings at 5 minutes, 2 minutes, 1 minute and 30 seconds, and a save at the 1 minute mark. The agent then stops the unit, waits until it is fully inactive, runs SteamCMD, checks again that nothing restarted it, deletes the wipe files, writes the new seed into server.cfg and starts the server. Wiping blueprints on forced day is a separate per-server choice. A server you had stopped is updated and wiped but stays stopped.
• No double work. The regular auto-update steps aside while the forced wipe is about to run, so the two never race, and a server already wiped for the new build is not wiped again.
• Optional backup first. With backup before wipe turned on, Panelra takes the backup before it starts the countdown.
• Oxide and Carbon. Panelra checks for new Oxide and Carbon releases every 5 minutes and, with framework auto-update on, queues the new version for install when it finds one. The forced wipe job itself does not reinstall Oxide, so an Oxide server comes back vanilla after the update and stays that way until the new Oxide release is out and installed. Carbon checks for its matching build and updates itself on that first start.

You watch the progress in the dashboard and get the new build id and seed when it finishes. See wipe scheduling and plugin management.

Free during the open beta. Pricing will be announced before the beta ends.

Forced wipe day checklist

• Announce the forced wipe time and wipe type.
• Back up server/<identity>/ and note the current buildid.
• Wait for a new public build on api.steamcmd.net.
• Warn players, save, systemctl stop, confirm inactive.
• app_update 258550 validate (add -beta staging only on staging).
• Oxide: reinstall the build for the new Rust version. Carbon: nothing, it updates on start.
• Delete *.map, *.sav and backups; blueprints too for a full wipe.
• Set the new seed in server.cfg.
• Start and wait for Server startup complete.
• Check buildid, BetaKey and oxide.version or c.version, then join.