Satisfactory loads the wrong factory: understand sessions, saves and auto-load

The short answer: In Server Manager, check the session you want and its saves. Explicitly load the correct save, inspect the factory in-game, then make sure Auto-Load Session Name matches that session. Auto-load identifies a session; according to the server documentation, startup loads its most recent save. A successful upload alone therefore does not prove that your intended factory will appear after the next restart. Back up your files before replacing anything.

This guide is for PC players using a dedicated server: self-hosted, with another provider or with SupremeTier. You do not need a new server or a change of provider. Without admin access, you can inspect the factory and prepare the diagnosis; an authorized person handles loading, uploads and server settings. There is a separate section below for locally hosted co-op. The manufacturer's current FAQ excludes consoles from joining dedicated servers, so these Server Manager instructions are not a console guide. Source: Coffee Stain

Sources checked: 29 October 2026. Menu labels may vary with language and build. These instructions are based on documentation. The walkthrough is a constructed example, not a report of a game-server test we performed.

First narrow it down: world, progress or character?

Your railway is missing after a restart. That can mean three very different things: another factory was loaded, an older version of the same factory is running, or a different character has left you in the wrong place. Before anyone deletes files, compare two or three unmistakable features: your HUB's location, a distinctive production facility and a recently completed milestone. A spawn point or an empty inventory is not enough to prove that the wrong world is loaded.

Also check the server entry. Does your group have several servers, an old address in its favorites or an additional local co-op game? Record the address and port of the entry you actually use. The displayed server name is a label; it does not have to match your session name. Ask a second player to confirm that you mean the same entry. Do not share an admin password or access token in the process.

The manufacturer's FAQ explains that a different online player identity can result in a new character. If the factory matches, investigate that account issue first. Rolling back the world could otherwise undo everyone's progress without resolving the actual problem. Source: Coffee Stain troubleshooting

Session, save and auto-load: three terms, three jobs

A session is the named context for your playthrough. Multiple saves can belong to one session. A save is a particular stored snapshot. Auto-Load Session Name specifies which session the dedicated server should load at startup. The server documentation describes this as loading the most recent save within that session. Source: server documentation

Imagine your session is called “Nordwerk.” Its snapshots include “Before-Rebuild,” “Evening-Save” and automatic saves. The session answers “Which factory playthrough?” The save answers “Which point in that playthrough?” This distinction explains two common mistakes: the most recently uploaded file does not have to be the currently loaded world, and a file's name is not necessarily the right auto-load session name.

Uploading is not a startup instruction

Uploading transfers a save to the server. In the API, immediately loading that upload is a separate option called LoadSaveGame. An upload without a subsequent load can therefore succeed while your group continues playing in the previous factory. Inspect the result in-game: a completed progress bar initially confirms only the operation the interface actually performed.

Loading now and loading at startup are separate operations

The API separates LoadGame from SetAutoLoadSessionName. The first loads a named save. The second sets the automatic startup target and, according to the documentation, does not change the session that is already loaded. Do not assume that every provider's panel automatically links these steps. Read the configured value again after saving it. Source: publicly mirrored documentation supplied with the game

Keep the file name, session name and server name separate

Write the three names down individually. Your server could be “Weekend Server,” the session “Nordwerk” and a manual save “Nordwerk-before-restart.” Renaming a file outside the game is not a reliable way to change its internal session assignment. Read that assignment in save management. For auto-load, use the session name shown there rather than guessing from a file in your upload folder.

Before you change anything: back up first

Choose one person to lead the process. Everyone else should stop building while you select a save and test the restart. Loading an earlier state could otherwise discard progress someone has just made. Record the last known correct point and the state your group wants to recover. “We have a backup” is of limited help when several similar files exist and nobody knows their dates or origins.

Back up the intended original save and also the server state you found, keeping both outside the active save directory. If you have file access, include the server's associated settings through the intended backup process. With a provider that does not offer file access, use its export or backup function and confirm that the download actually exists. A backup kept only inside the same temporary server directory will not protect you if that directory is replaced.

Let any save operation finish. For direct filesystem copies, the server should be cleanly stopped through its regular service or panel controls. This differs from uploading through a running Server Manager: that management function needs a reachable server. Do not treat a copy of a file that is still being written as a consistent backup, and do not forcibly terminate the process just to save time.

Explicitly save before stopping. Do not rely on a restart button to create a fresh world save. The Pterodactyl egg documentation specifically warns about this limitation in its shutdown process. Verify the newly written entry in Server Manager and back it up before stopping the instance. This separates “the server shut down cleanly” from “our latest building progress was actually saved.” Source: Pterodactyl, Save Files

Your backup record should include at least:

• Origin: a player's PC, the existing server or an earlier backup.
• Backup date, time and time zone.
• Session name and file name, where visible.
• Playtime and save time shown in save management.
• Branch, build and installed mods, where known.
• Two factory features that help your group recognize the state.
• The location of the unchanged original copy.

Your way back: If a test fails, stop the sequence of experiments. Keep the problematic intermediate state separately, load the intended backed-up copy through the normal management interface and restore the auto-load target you recorded earlier. If you had to change versions, a compatible server version also belongs in your recovery plan. Copying a backup in a newer format does not automatically make it readable by older software.

Compare the build and branch before trying different saves

“We both have Satisfactory” is not precise enough for diagnosis. Record the branch used by the game client and by the dedicated server: the regular branch or Experimental. Add the actual build identifier displayed by the game, server interface or startup log. Labels in a provider's panel are clues; what the running process reports is what matters. If available, also record the build that last saved your intended file.

The version comparison answers the first question: Can this installation load the intended state at all? If manual loading already fails, changing the auto-load name will not fix that failure. If the correct factory loads manually but another one appears after every restart, the startup target is the closer lead. Do not mix these two classes of problem by updating, renaming and restoring files at the same time.

Coffee Stain explicitly recommends backups when switching versions. Put aside an unchanged copy before opening a save in another branch and saving it again. Attempt a return to an older version only with a suitable save. A file's existence does not establish compatibility. Source: Coffee Stain, main and Experimental branches

Mods add another layer. Keep a list of the installed mods and their versions. Test changes to that set only on a copy of the save. Starting successfully without mods does not prove that mod-dependent content has been preserved. If you do not know the mod dependencies, treat that save as a separate recovery case first. The main walkthrough below assumes a save that is fundamentally loadable in the chosen server environment.

Find the right save

Start with the player who last saw the correct factory. Ask for the specific save or an export of it. “Use the newest one” becomes ambiguous once people have copied files, renamed them or freshly downloaded older backups. A filesystem timestamp may describe the copy operation rather than the factory's progress.

Compare several clues: session assignment, the save time shown in save management, playtime, recognizable buildings and recently completed milestones. File size is only supplementary information. A larger file is not necessarily the correct one; a smaller file is not automatically damaged. Higher playtime also does not prove the desired construction is present if people continued playing different branches of the same factory.

Open uncertain candidates only as working copies. Record what you see in each one. Two clearly labeled attempts are more useful than ten untracked uploads. When restoring an older save, one question is especially important: does your group want to inspect a historical state or continue playing from it permanently? In the second case, you need a new, verified saved state after checking the contents, followed by another restart test.

If none of the candidates contains the expected factory, stop investigating the startup target. Look through additional existing backups and local saves for the missing state. A setting cannot reconstruct buildings that do not exist in any saved snapshot. Do not tell the group that its data is lost before you have established which sources have actually been searched.

Example: from upload to restart

Constructed example, not a live test: Four players want to continue “Nordwerk.” After a restart, however, their dedicated server loads “Probefabrik.” The intended local save is called “Nordwerk-Abend.” The group recognizes Nordwerk by a station beside the HUB and a new aluminum production line. These names and observations are illustrative only.

1. Record the starting point

The responsible person records the server address, port, active session and displayed auto-load value. They also back up both the server state they found and the local “Nordwerk-Abend” file. The download remains unchanged in a second location. Everyone understands that no productive building should take place during the test.

Expected intermediate result: you can explain which factory is currently running and what you will return to if the attempt fails. If the server address itself is unclear, do not upload anything yet. A technically successful upload to the wrong server would still be the wrong result.

2. Check the candidate and version

The group compares the client and server branches and builds, then checks the intended save against its known features. The name alone is insufficient. If a compatibility error appears, investigate that first. Keep the original protected rather than trying arbitrary versions against the only copy.

Expected intermediate result: “Nordwerk-Abend” is the intended candidate, its origin is known and the selected server environment can load it. If those conditions are not met, leave the next action open rather than marking it successful.

3. Upload through Server Manager

Open Server Manager from the main menu, select the correct server and authenticate with admin access. The documented interface provides save management under Manage Saves. Choose the local save for upload there. Use the upload function shown in your build and wait for the result. Source: server documentation, Loading a save file

Then check whether the file appears in the server-side save list and which session it belongs to. If the interface also offers to load the upload immediately, record whether you selected that option. If it does not, load it separately afterward. If a file with the same name already exists, cancel an unclear overwrite prompt and back up the existing file first.

4. Load that exact save and inspect the factory

Explicitly select the uploaded candidate for loading. Wait for loading to finish. The API documentation notes that the API can become temporarily unavailable while a save loads. A short interruption at this stage is therefore not proof by itself that loading failed. Do not blindly repeat load requests. Source: API documentation, LoadGame

Join the game and check the station, HUB and aluminum line. A second player confirms those features. If the aluminum line is missing, you may have chosen the wrong point in time. Return to candidate selection. Setting auto-load to “Nordwerk” already would not replace this content check.

5. Save the verified state and match the auto-load target

Save the confirmed factory with a clear manual name, such as “Nordwerk-vor-Neustart.” Check that the new entry actually appears in save management. This is particularly important if your group chose an older state as its new continuation: auto-load should not silently pick an existing newer but unwanted state from the same session.

Set Auto-Load Session Name to the session name actually displayed: “Nordwerk.” Save the setting, reopen the view and read it again. Do not enter “Nordwerk-vor-Neustart” if that is only the file name. Also inspect the most recent saves in that session. Additional automatic saves can appear, so record the list immediately before restarting.

6. Restart normally without assuming success

Agree on a short restart with your group. Let saving finish, then use your panel's or service manager's regular restart process. With self-hosting, use the service that is actually configured. An example service name from another tutorial is not a valid command for every system. Do not create a crash as a test or change the startup script, version and save directory at the same time.

After startup, wait until the server is ready. Do not immediately load Nordwerk manually: doing so would hide whether automatic startup worked. First read the active session and auto-load target. Then have a player join and inspect exactly the same factory features as before.

7. Record the result against clear criteria

The test passes for this restart if the intended session runs without manual loading, the agreed factory features are present and the newly verified state is recognizable. Record the time, active session, auto-load target and result. A running server process or a green status indicator alone is not enough.

If “Probefabrik” returns, compare the setting with your pre-restart note. If Nordwerk remains active but the aluminum line is missing, investigate saves within that session. These are different follow-up paths. The first concerns startup configuration and whether it persists; the second concerns the loaded point in time. Keep your backup until the group confirms the successful state.

Set up correctly and still wrong

The auto-load value changes back after startup

First check whether the change was actually saved and displayed again afterward. If it was, ask the operator to check for mechanisms that restore settings at startup: startup templates, recovery scripts, changing configuration directories or a container path that does not persist. These are diagnostic hypotheses, not an automatic assignment of blame to your provider.

Change only one variable per attempt. Record the value before stopping and after startup. If the server name or admin setup also resets, that points toward a broader loss or replacement of server settings. Do not delete those settings as a quick fix: you could lose additional information and the previous access configuration.

Auto-load and the active session match, but the progress does not

Selection within the session is now the closer lead. Check whether the expected progress was saved at all and whether the save you inspected actually exists on the server. Distinguish the last time someone built something from the last successful save. Repeated restarts cannot create a missing intermediate state.

When restoring an older save, compare the other newer entries before considering the diagnosis complete. Save the verified continuation again and repeat the check. Do not remove candidates merely because their names look similar. If cleanup becomes necessary, export them separately first and document their assignments.

The save disappears after a container or service restart

Investigate the storage location and whether it persists. An upload may be visible in a running instance while a restart starts another instance with different storage. Ask the operator to compare the actual mounted storage path, service account and startup configuration. Reinstalling would not be a useful first diagnostic step here.

With self-hosting, also check whether you are accidentally managing two instances. Keep the installation directory, save storage and service account separate in your reasoning. Program files being in a particular location does not prove that the active saves are stored there too. A repair needs observed paths rather than only a default taken from the internet.

The server cannot load the candidate or reports errors

Keep the complete relevant error message and the sequence of events. Is the file present in the server-side list? Does its session assignment match? Did the upload finish? Only then proceed to build, branch and, where relevant, mod checks. Do not designate a file with a known loading error as the unattended startup target for an active group.

If another backed-up save of the same factory works, record that difference. It narrows the issue without proving a specific kind of file corruption. Avoid using “repair” tools on your only copy. A concise report with one failing and one loadable candidate is more useful than a long list of undocumented changes already attempted.

Self-hosted or rented?

For the normal process, you need Server Manager and admin access. Direct file access is an additional option for backups and diagnosis, not a requirement for every player. On a rented server, exports and restarts may be provided through the hosting panel. Button names differ; instructions should not pretend that every panel looks identical.

For local saves on a self-hosted Windows PC, Coffee Stain gives the base directory %LOCALAPPDATA%\FactoryGame\Saved\SaveGames. The account whose files you inspect matters. A server service may run under a different account from your interactive game. The manufacturer's path for your signed-in user therefore does not establish the correct service-account path. Source: Coffee Stain, save files

On Linux and in containers, confirm the actual save location used by the installation. Check persistent storage mounts and the service account's write permissions before copying files. Do not grant blanket access to every user. Resolve a permissions problem through appropriate ownership and the intended access mechanism rather than indiscriminately opening access.

Without admin access, send the authorized person the intended session, candidate name and factory features. Ask for the values before and after restarting. The group can then judge the result without giving everyone the admin password.

Local co-op: the host chooses the save

When a player hosts the world directly on their PC, that PC is the authoritative source of the loaded game. A dedicated server's auto-load value is not the relevant setting. After making a backup, the host ends the running game, chooses the intended save in the load menu and invites friends again. As with a dedicated server, inspect the factory first and then its progress.

In particular, compare who is hosting this time. Two players may have copies of the same factory at different stages. If someone else opens the game, an older local save is a reasonable lead to investigate. A file name passed between players does not document which copy was played most recently.

Before a cloud-sync operation with an uncertain outcome, keep separate copies of the local candidates. Use save information and factory features to decide which version the group will continue. Do not randomly enable and disable syncing while several devices open different copies. The safe order remains: back up the copies, establish their origins, deliberately load one, inspect the contents and document the new authoritative continuation.

A restart record you can reuse

Fill in these fields before and after the test. An empty value means “not checked yet.” This template is not automatic evidence and does not read server data.

Final decision: “Passed” means the correct session and factory state loaded without manual intervention. “Partial” could mean the factory matches but the auto-load value could not be read. “Failed” means an agreed feature is missing or another session is running. This makes clear what has been demonstrated and what remains open.

Advanced: the server API

If your existing management tool already supports the Satisfactory API, use it to supplement manual observations. QueryServerState distinguishes the active session (ActiveSessionName) from the startup target (AutoLoadSessionName). EnumerateSessions returns session groups with save information. That distinction helps separate an incorrect startup value from an incorrect save within the right group. Source: API documentation

According to the modding community's developer documentation, the reference supplied with the game is located at CommunityResources/DedicatedServerAPIDocs.md in the installation directory. For specific requests, use the file that belongs to your installed build. The public mirror linked here dates from 2024 and does not replace that comparison. This guide deliberately does not provide an untested sequence of requests containing credentials. Source for the documentation location

API status alone cannot prove the visible contents of the factory. Combine it with a join test. A successful response to a setting change also does not prove that an external startup template will preserve the value across a restart. Record the observations from before and after startup in the same test record.

FAQ

Should I enter the file name in Auto-Load Session Name?

Use the session name displayed in save management. File selection identifies a specific save; auto-load identifies the session for the next automatic startup. Verify the assignment rather than guessing from a file name.

Why did my upload succeed while the old factory remains active?

Check whether loading was actually triggered after the upload. Uploading and immediate loading are separate operations. Explicitly select the uploaded save, join the world and inspect known structures. Only then can you judge whether the intended contents arrived.

Can we permanently continue from an older state?

Yes, if your installation can load it and it contains the intended contents. Back up the other candidates, load the older state, inspect it and save the chosen continuation again. Check auto-load and the session's most recent saves. The subsequent restart test shows whether the continuation actually reappears.

Is renaming the save file enough?

No: renaming does not establish the session assignment. Read the assignment in management and check the startup target separately. A meaningful manual save name helps your records but does not replace selection or a restart test.

Do I have to delete old autosaves?

Not as your first diagnostic step. Back them up and compare them first. An old autosave may be the only remaining copy of the desired state. If targeted cleanup is needed later, keep exported copies outside the active storage and document what you removed.

Should I reinstall the server first?

Start with server identity, save selection, auto-load and persistence of settings. Reinstalling can introduce additional variables and make diagnosis harder. If an installation really does need repairing, first prepare a complete recovery plan with backed-up data.

Does an empty inventory mean this is the wrong factory?

Not reliably. Check buildings and progress first. A different online player identity may explain a different character. Compare account access and the actual world state before rolling back the whole group's progress.

What should I send to support or my server administrator?

Give the exact time, server entry, branch and build, intended and active session, auto-load value and tested save. Add your observations before and after a normal restart and the relevant error message. Explain whether the save loads manually. Do not send passwords or tokens; share saves containing private information only through an appropriate protected channel.

Sources and review status

Review status: Sources read on October 29, 2026. The manufacturer's FAQ confirms backups, version-switching advice and the distinctions described above. The community wiki linked by Coffee Stain documents Server Manager and the meaning of the auto-load target. Direct access to that wiki was blocked during this check; the relevant statements were readable in the current search index. API terminology was also checked against the public mirror of the documentation supplied with the game. No test on a specific current server installation was performed.

• Coffee Stain: support and FAQ
• Satisfactory Wiki: dedicated servers
• Public mirror of the server API documentation
• FICSIT: find the API reference in your installation

The test records and example walkthrough are editorial tools. They do not promise to recover data that no longer exists. Keep the unchanged backup until your group has confirmed the correct factory and progress after restarting.