# Fix Satisfactory mod version conflicts after an update

A Satisfactory update can leave the game, loader and individual mods on different compatibility timelines. A stalled join does not identify which component is responsible. Start with a version comparison and a protected checkpoint, then reproduce the problem outside your live factory.

## Build a before-and-after record

1. Record the exact server game build and branch. Compare them with the affected client's build.
2. Export or record both mod profiles, including SML and dependency versions. Include a release link for each package.
3. Identify the server operating system. A package available for one dedicated-server target may be unavailable for another.
4. Capture complete client and server startup logs for one failed connection, noting its time and time zone.

Keep both the last working checkpoint and a copy of the current configuration. Avoid updating every dependency again before recording the failure: that removes useful evidence about which change introduced it.

## Read compatibility claims precisely

Use the [SML release page](https://ficsit.app/mod/SML) and each mod's own release information to check the game version and supported targets. The newest package is not automatically the right one for a server that remains on an older build. Do not install development artifacts merely because they have a later version number.

The [upstream manual-install guide](https://docs.ficsit.app/satisfactory-modding/latest/ManualInstallDirections.html) requires an SML release compatible with the game. Its Linux manual instructions are explicitly incomplete, so old hand-copy recipes are a poor way to repair a managed Linux installation. Return to a coherent, supported manager profile rather than layering files from several tutorials.

## Separate startup and joining failures

If the server stops during loader initialization, compare dependencies and binary targets first. A missing library or incompatible package will not be repaired by changing the public port.

If the server reaches a usable state but a client cannot join, compare that client's required package set with the intended server profile. Client-only mods and server-capable mods are different categories; review the author's instructions before deciding that both folders must be identical.

If only a particular machine fails, reproduce with another prepared client on the same game build. If every client fails immediately after one package changed, that change becomes a useful lead, not proof that the world itself is damaged.

## Find the smallest failing combination

Prepare a separate new factory with a known-compatible baseline. Add the affected mod and its dependencies, restart cleanly, connect and test the failing action. Add other packages one at a time until the issue returns. Preserve logs and the profile at each meaningful checkpoint.

Do not perform this isolation by removing building or item mods from your established factory and saving it. A new test world answers the compatibility question without changing your production content. If the issue requires your real save to reproduce, keep that save isolated and ask support or the author before loading it with missing dependencies.

## Choose a safe recovery

Keep production on the last proven combination where supported, or wait for a compatible release. Roll back packages together with the corresponding configuration and save checkpoint when necessary. A game update that changed the save format can limit rollback; do not force a downgrade without checking.

Related: [Satisfactory API and stalled-join checks](https://help.cloudexa-hosting.com/books/survival-games/page/diagnose-satisfactory-server-api-errors-and-stalled-joins) and [backup preparation](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes).