Match this symptom
The vanilla Rust server reaches startup complete after an update, but plugins disappear, produce API errors, or crash the process before players can join.
The answer first
Keep the production identity stopped and preserve its plugin data and logs. Confirm the updated server starts vanilla, then install a framework build compatible with that exact Rust version and reintroduce plugins in controlled groups on a copied identity.
Preserve plugin-owned state before experimenting
- 1Stop automatic restart loops and keep players out.
- 2Copy the entire server/<identity> plus framework plugin, config, language, and data directories.
- 3Save the first failing startup log and record the Rust build, framework build, and plugins changed in the maintenance window.
- 4Keep the last known-good pre-update snapshot untouched.
Establish a vanilla baseline
Steam validation owns official binaries and can replace files patched by a third-party loader. On a copied identity, disable the framework without deleting plugin data, start Rust, and wait for Server startup complete. A vanilla failure points to the official update, world, OS, or launch command—not a plugin API.
Version-match the framework
- 1Obtain the current framework build from the framework's trusted publisher channel.
- 2Confirm it explicitly supports the installed Rust server build.
- 3Install it after SteamCMD validation, because later validation can replace its modified files again.
- 4Start with no optional plugins and verify the framework itself loads cleanly.
Reintroduce plugins without risking the world
- Load foundational dependencies before plugins that require them.
- Add small groups and save each startup log so the first incompatible plugin is identifiable.
- Verify plugin-owned permissions, economy, kits, or other data before allowing public writes.
- Do not permanently remove a data-bearing plugin from the only world and save over its missing objects/state.
Reopen only after the persistence test
When every required plugin loads, run server.save, native quit, restart, and verify plugin data again. Create a fresh known-good checkpoint of the updated Rust build, framework, plugins, and identity before returning the public ports.
Interpret the first framework or plugin error
A missing loader banner after otherwise normal vanilla startup points to framework installation or version alignment. A loader that starts and then reports an unknown hook, type, or API member points to a plugin built for another framework/Rust API. A plugin that loads but loses economy, permissions, kits, or map markers points toward omitted plugin data or an identity/path change rather than the official world save itself.
Preserve the earliest error and the lines immediately before it; later cascading failures often name many innocent dependents. Check the plugin publisher's current compatibility statement and dependency versions rather than editing its data files blindly. If no compatible release exists, restore the matched pre-update stack where a permitted binary is available or keep the updated copied server vanilla while waiting—never fabricate API shims on the only production data.