Why Did My Rust Base Collapse After a Patch? The Patch-Day Save Bug, Honestly Told

Facepunch opens Devblog 80 with an apology, in plain language: the patch on Thursday was broken, and the team did not communicate well. That is the whole tone of the postmortem, and it is worth copying before any of its details. The game was in alpha, the author writes, but that is no excuse for throwing just anything at the main branch. The trigger for the worst bug was specific, and the postmortem states it exactly: if you were running a server for a while, then updated your server to the patch, a lot of your buildings would fall down. It does not say every server, every player, or first-time installs. It says subsequent restarts had no problems. Read that sentence twice, because the rest of this article turns on it.

The postmortem never explains the mechanism. There is no save-format change, no serialization mismatch, no stability recalculation, and no code path named anywhere in it, and this article will not invent one to fill the gap. What it does explain is the context that made the bug possible. The patch touched a lot at once, and a lot of new bugs came with it. Sound pooling, a last-day, untested addition, made a lot of negative difference and was disabled by an update, which seems to have fixed the problems most people were experiencing. That was the sound problem, not the save problem, and merging the two would be a second bug, this time in the retelling.

The postmortem is blunt about testing. There was no internal QA team. The team relied on people playing the dev branch, but most of the problems in this update were visible on the dev branch and nobody was playing on it, because of those bugs. Internal error reporting did not differentiate between the dev branch and the main branch, so errors reported on the dev branch were eclipsed by day-to-day errors on the main branch. The testing pipeline did not fail in one place. It failed in three: nobody staffed to test, nobody playing the test branch, and reports that could not tell test errors from live errors.

Thursday patching was deliberate, not accidental. The postmortem explains that patches went out on Thursday instead of Friday because the team expected bugs and wanted a day to fix them before the weekend. The stated lesson then breaks the habit it describes: feel less bound by the patch day, delay what is not ready and take the heat, and keep work on the dev branch until it has a reasonable amount of testing, even if that means irregular patches. One more boundary matters for honesty. The same postmortem mentions memory reports that only seemed to start after an update to Unity 5.2, and marks that observation as not confirmed. It is a memory observation, not a cause of the collapse, and this article keeps it that way.

Facepunch published no fix procedure for this incident, so the reusable part of this story is process, not code. Treat every patch as a data-loss rehearsal. Take a snapshot before patching, and restore from it once somewhere that is not production, so you know the snapshot works. Upgrade a copy of the live world first, not the live server. Roll out to one server before the fleet, with a named person who can call the rollback. Write the player-facing status note before patch day, not during the outage. None of these steps is attributed to Facepunch, because the postmortem does not state them. They are what the incident teaches, stated as lessons, not as history.