A successful upload only places a save on the server. It does not prove that the intended checkpoint is running or that the same session will return after a restart. Transfer the .sav, explicitly load it, then verify a fresh save and restart before handing the address to your group.
This guide covers PC saves and an existing Satisfactory dedicated server you administer. Console saves and PC dedicated servers belong to different supported ecosystems; do not assume this procedure exports a console world. Keep modded saves within the compatibility requirements of their particular mod setup.
Protect both factories before choosing a checkpoint#
Open the source world and make a clearly named manual save, such as factory-transfer-2026-11-04. Note its session name, playtime and a recognizable location. Keep an untouched copy outside the game's save directory and cloud synchronization. On Windows, the normal PC save root is %LOCALAPPDATA%\FactoryGame\Saved\SaveGames; individual account subdirectories can sit below it.
Check the source game and destination server builds and branches. A save from a newer build may not load on an older one. In particular, the maintained server integration documentation warns that a save written by 1.2 cannot be opened by 1.1. Update deliberately or return to a compatible earlier backup; renaming the file does not convert its format.
If the destination already hosts a factory, save that world explicitly through Server Manager and download a backup first. Stopping the dedicated process does not itself guarantee a fresh world save. Preserve its existing session even if the imported world is meant to replace it later.
Prefer Server Manager when administration already works#
Connect through the in-game Server Manager. A newly installed server must be claimed and given an administrator password before administrative save operations are available. Confirm you are managing the intended address; a familiar display name alone is insufficient.
- Authenticate as administrator and open Manage Saves.
- Upload the selected local checkpoint, using the upload control's save picker or file selection as provided by your game version.
- Locate that checkpoint in the destination's save list. Check the session and playtime rather than trusting the filename alone.
- Choose the save and load it explicitly. Loading switches the active world; schedule this with any players already connected.
- Check Auto-Load Session Name in the server settings. Set the intended session if that is what should start automatically.
The automatic setting selects a session and loads its most recent save at startup. It is not a permanent pin to the particular uploaded filename. An older checkpoint uploaded successfully can therefore coexist with a different active or automatically selected world. Preserve the existing saves while correcting that selection.
Use a stopped file transfer only when you know the real save root#
Filesystem access is a fallback for deployments where the manager's upload is unavailable. A server can install its executable in one directory and write saves under another account's home directory. Copying into the installation folder often creates a perfectly intact file that the game never sees.
| Deployment | Where to investigate |
|---|---|
| Native Linux | The server account's ~/.config/Epic/FactoryGame/Saved/SaveGames/server |
| Native Windows | The process account's %LOCALAPPDATA%\FactoryGame\Saved\SaveGames\server |
| Container | The image's documented persistent save directory and its actual host mount |
For a systemd deployment, this read-only command helps identify the account, environment and executable. Replace satisfactory.service with your actual unit name:
sudo systemctl show satisfactory.service \
-p User -p Group -p Environment -p WorkingDirectory -p ExecStart
Inspect the unit and running deployment together. An explicit HOME, container mount or wrapper configuration can change the effective location. For example, the maintained Satisfactory container image documents /config/saved; that path is not a universal native-server path.
Save the destination explicitly, shut it down cleanly and wait until its process exits. Copy the source .sav into the confirmed server save directory with a distinct filename. Retain the existing files. Give the copied file the same appropriate ownership and access as working saves; avoid broad permission changes across the installation. Start the server, then select and load the imported checkpoint through Server Manager.
Do not replace ServerSettings files as though they were factory checkpoints. Server identity, administrative settings and world progress serve different purposes. Blueprints are separate too: transferring a world does not automatically transfer your reusable blueprint library. Use the blueprint transfer guide if those files are also needed.
Diagnose the stage that actually failed#
If the file is absent from the list, check the actual save root, extension and process access. If it appears but loading fails, investigate build compatibility and the server log before changing network rules. If loading succeeds but the wrong factory returns after restart, revisit the session selection and newest save in that session.
A client that cannot join an otherwise loaded world needs a separate connection or client compatibility investigation. Repeatedly importing the same file will not resolve every multiplayer failure. Keep player data intact while establishing which step failed.
When several machines are involved, record which host owns the destination and where its persistent data lives. Nexardo provides a management approach for your own infrastructure; it does not replace the game's save compatibility checks.
Finish with a persistent-world check#
Join, inspect the expected factory and verify the character's inventory. Create a new named save, confirm it appears, then perform a controlled restart and reconnect. Confirm the same session and newly recorded progress return. Keep the source and previous destination backups until your group has checked the transferred world; only then resume normal play and scheduled backups.
Sources#
- Satisfactory developer support: PC save location, backups and platform limits.
- Satisfactory dedicated-server documentation: Server Manager and session settings.
- Maintained Pterodactyl Satisfactory integration: save handling and version migration.
- Satisfactory container documentation: persistent directories.
