Satisfactory server settings, saves and mods

A Satisfactory dedicated server has almost no configuration file. You install it, open one port, and then everything else happens from inside the game: you claim the server from the Server Manager tab, set a name and an admin password, create or upload a save, and change the handful of settings that exist from a panel in the client. That design is pleasant right up to the first problem, because when something fails there is nothing obvious to edit. This post covers the settings that exist and where they end up on disk, where saves actually live on a Linux server (not where you would guess), how the autosave produces the hitch your players complain about, and how mods work when the server needs its own build of every one of them. The wider argument about why a Satisfactory server gets heavier the longer it goes well is in a Satisfactory dedicated server, and why it gets heavier.

Installing the server and the one port that matters#

The dedicated server is a free, separate download: Steam app id 1690800, anonymous login, no game licence needed on the machine running it.

$ steamcmd +force_install_dir /home/satisfactory +login anonymous \    +app_update 1690800 validate +quit$ cd /home/satisfactory$ ./FactoryServer.sh -Port=7777

For the experimental branch, add -beta experimental before validate. The client and server must be on the same branch and the same build; an experimental client cannot join an early-access server or the reverse, and the error message does not say so clearly. SteamCMD explained covers app ids and branch switching in general.

Since Update 8 the server uses one port for everything, and it needs it on both protocols:

That is the single most common Satisfactory hosting problem. The old guides still floating about list 15777 for queries and 15000 for a beacon; those are gone. What people do instead is open 7777 UDP, because that is what game servers use, and then find the server sits at "Offline" in the Server Manager forever. Management, claiming, save uploads and mod installation all run over TCP on the same number. Open both. Game server ports explained covers why a game has two channels at all.

Claiming the server and the two passwords#

A freshly started server is unclaimed and will let the first person who finds it take it over. Do this immediately.

1. Open Satisfactory, go to Server Manager on the main menu, choose Add Server, and enter address:7777.
2. Accept the certificate warning. The server presents a self-signed certificate because there is no name to issue a real one against; this is expected, not a sign of interception.
3. The server reports itself as unclaimed. Set a server name and an admin password. That claims it.
4. Optionally set a client password, which is what other players type to join.

The two passwords do different jobs. The admin password gives full control of the server: settings, saves, shutdown, mod installation. The client password only allows joining. Anyone who knows the admin password is an administrator - there is no per-player list and no role system, so it goes to the one or two people who actually run the server.

With the server claimed, you either Create Game - session name, a starting location, and a checkbox for Advanced Game Settings - or Manage Saves and upload an existing one. The four starting locations are Grass Fields, Rocky Desert, Northern Forest and Dune Desert; they change where you land, not the map, and Grass Fields is the gentle one.

The server settings and where they are written#

The Settings panel in the Server Manager is short. It is the whole of the server's gameplay-independent configuration:

These are written to ServerSettings.ini in the server's config folder (FactoryGame/Saved/Config/LinuxServer/ on Linux, WindowsServer on Windows) once you have changed them at least once. Read that file rather than trusting any published key list, including this table: Coffee Stain adds settings between updates and the file the server wrote is always current.

Auto Pause is the setting to think about first. With it on, the factory stops the moment the last player disconnects, and starts again when someone returns. That is usually what a group actually wants - the world is there when you log in, and the server costs nothing in CPU overnight. If you want production to continue while nobody is online, turn it off, and understand what you have bought: the simulation runs 24 hours a day, the save grows around the clock, and the container's CPU allocation is in use continuously rather than for the three hours a night anyone plays.

Network Quality trades bandwidth and server CPU for smoothness. Raising it helps when players see vehicles and other players stuttering while the factory itself is fine. Lowering it is worth trying on a server that is already CPU-bound, because it is the only knob that reduces per-player cost.

The player cap is not in that panel. The dedicated server defaults to four players, matching the game's supported co-op size, and the community route to more is a Game.ini in the same config folder:

[/Script/Engine.GameSession]MaxPlayers=8

This is unsupported by Coffee Stain and it is not free. Satisfactory's networking was tuned for four, and each extra player loading a different corner of a large factory costs more than the player count suggests. Eight works for most groups on a well-sized plan; sixteen is where people start reporting problems that no setting fixes.

Advanced Game Settings#

Advanced Game Settings are per save, not per server. You enable them with the checkbox when creating the game, or from the pause menu on a save that already has them enabled.

• No build cost, no power requirement
• God mode and flight mode
• Keep inventory on death
• Unlock all research, schematics and tiers
• Set the game phase directly
• Give items

Two things to know before ticking the box. Enabling Advanced Game Settings permanently marks the save and disables achievements on it, and there is no way back - copying the save does not clean it. And they are available to anyone on the server who opens the menu, not just the admin, so on a server with people you do not know well, "unlock all tiers" is one bored click away.

For a group replaying the game together, leave them off. For a build server where the point is the factory and not the progression, turn them on at creation and never think about it again.

Saves: where they live and how to move one#

This is where people lose an hour. The Linux dedicated server does not keep saves inside its installation directory. It writes them under the running user's home:

~/.config/Epic/FactoryGame/Saved/SaveGames/server/    Longship.sav    Longship_autosave_0.sav    Longship_autosave_1.sav    Longship_autosave_2.sav~/.config/Epic/FactoryGame/Saved/SaveGames/blueprints/

On a Windows server it is %LOCALAPPDATA%\FactoryGame\Saved\SaveGames\server\. On a client, your single-player and co-op saves are under %LOCALAPPDATA%\FactoryGame\Saved\SaveGames\ in a folder named after your store account id.

Moving a save onto the server has two routes. The supported one is Manage Saves then Upload Save in the Server Manager, which pushes the file over the HTTPS API. It is the right answer and it works, until the save is large and the upload times out, which starts happening on mature factories. The fallback is to copy the .sav straight into the server folder over SFTP or a file manager and restart the server, after which it appears in the save list like any other. SFTP and the file manager covers getting at that path on a panel.

Two rules when you do it by hand. Copy only .sav files, and keep the session name consistent - the file name is what the Server Manager lists. And never overwrite a save the server is currently running; stop it first, because the next autosave will write over whatever you put there.

Blueprints are separate. They are a pair of files per blueprint in the blueprints folder, and they do not travel with the save, which is why a blueprint built on a friend's single-player world does not show up on the server until someone copies it across.

Autosaves, the hitch, and real backups#

Satisfactory writes the whole world to one file. There is no incremental save, so every autosave serialises the entire factory, and the time that takes grows with the factory. Five minutes into a new world it is imperceptible. Three hundred hours in it is the freeze your players report as lag, and they report it on a schedule because it happens on one.

What actually helps, in order:

1. Lengthen the interval. Ten minutes instead of five halves how often anyone notices. It also doubles what a crash costs, so pick a number, do not just push it to the maximum.
2. Fast storage. The write is a large sequential one, and NVMe finishes it in a fraction of the time a spinning disk takes. This is one of the clearer cases in what NVMe actually changes.
3. More memory, if the machine is swapping. A server writing a save while over its memory limit is a different and worse problem.

What does not help is deleting autosaves to save disk. The three rotating files are the cheapest safety net you have.

They are also not backups. They sit beside the live save on the same disk, they rotate, and a corrupt world is faithfully written into all three within fifteen minutes. A real backup is a copy somewhere the server cannot write, taken on a schedule, and restored occasionally to prove it works - backups that actually restore makes that case properly. Take one before every game update without exception: Satisfactory saves are forward-compatible only, and a save opened by a newer build cannot go back.

On RE:NODE, backup slots are included on every Satisfactory plan, they are kept off the machine they protect, and restoring is a button rather than a ticket. The Schedules tab runs a nightly backup and, if you want one, a nightly restart on a cron expression - restart schedules that help has the argument for and against that on a game that grows in memory.

Mods with SML on a dedicated server#

Satisfactory's modding runs on SML, the Satisfactory Mod Loader, with mods distributed through ficsit.app and installed on clients by the Satisfactory Mod Manager. On a dedicated server, mods live in a Mods folder inside the server's FactoryGame directory, one folder per mod.

The constraint that catches people is build targets. A mod is compiled per platform, and a mod that ships only a Windows client build cannot run on a Linux dedicated server no matter where you put the files. Check each mod's listing for a server target before planning a modpack around it. The Mod Manager can install directly to a claimed dedicated server using the admin password, which resolves the targets for you and is much less error-prone than copying folders.

Everything else follows the usual rules for a modded server, and they are strict here:

• Client and server run the same mods at the same versions. A mismatch usually fails at connect rather than degrading quietly.
• SML is tied to the game version. After a game update, nothing loads until SML is updated, and then each mod after it.
• Removing a mod that added buildings breaks the save. The world contains objects the game can no longer resolve. Decide a modlist before you commit two hundred hours to it, and back up before adding or removing anything.
• Mods increase memory use, particularly ones adding buildings and recipes, and Satisfactory has no headroom to spare on a mature factory.

What to do when a mod update breaks is the general procedure for the patch-day version of this.

Sizing and troubleshooting#

Satisfactory's memory use tracks the size of the factory, not the number of players. A rough guide:

The server shows as Offline in the Server Manager but the port is open. TCP on 7777 is not. The management channel is HTTPS over TCP on the same port number as the game's UDP traffic.

The client refuses the certificate. Self-signed, expected, accept it. There is no way to install a real certificate for an IP address.

"Server is not claimed" after you claimed it. You are looking at a different server, or the client has a stale entry. Remove it from the list and add it again.

The server will not accept a client of the same version. Check the branch. Experimental and early access report similar version numbers and do not interoperate.

A save uploads and then fails to appear. Usually a timeout on a large file. Copy it into the server save folder directly and restart.

One CPU core is pinned while nobody is online. Auto Pause is off, so the factory is running. That is a choice, not a fault, but it is worth making deliberately.

Memory climbs all week and the server restarts on its own. That is the container reaching its limit and being restarted clean rather than left to swap. On a growing factory it is a signal to move up a tier rather than to tune anything.

FAQ#

How many players can a Satisfactory dedicated server hold?

Four by default, which is the supported number. Raising MaxPlayers in Game.ini works and is what most larger groups do, but it is unsupported and the networking was not designed for it. Eight is a reasonable stretch; beyond that expect problems no setting solves.

Does the factory keep running when nobody is online?

Only if you turn Auto Pause off. By default the world is paused while empty, which means no overnight production and no CPU burned while nobody is playing. Whether that is a feature depends entirely on how your group likes to play.

Where are the saves on a Linux server?

Under the running user's home directory, at .config/Epic/FactoryGame/Saved/SaveGames/server/, not inside the install folder. Blueprints are in a sibling blueprints folder.

Can I move a single-player save onto a dedicated server?

Yes. Upload it from the Server Manager, or copy the .sav into the server's save folder and restart. The save format is the same; what does not come across are your blueprints, which are separate files.

Do I need a copy of the game to run the server?

No. The dedicated server is a separate anonymous download on Steam, app id 1690800, and needs no licence. You need the game to administer it, because the Server Manager is part of the client.

Why does the server freeze for a moment every few minutes?

The autosave. The whole factory is serialised into one file, so the pause grows with the save. Lengthen the autosave interval, and make sure the storage underneath it is fast; nothing else changes it.