Satisfactory dedicated server: setup, saves and settings

Satisfactory is unusual in that the server gets measurably heavier the longer the game goes well. Every belt, every splitter and every stored item is state, and a factory that has been running for two hundred hours has a great deal of it. A server that was fine in month one and stutters in month three has not degraded - the save has grown. Plan for 8 GB at the start and 12 to 16 GB by the time the factory is worth showing people, open one port, and understand that almost everything you would expect to find in a config file is instead a panel inside the game client. This guide covers the install, the claim flow that catches everybody once, the settings that exist, saves and autosaves, mods, and the difference between a server problem and one player's route to it.

How a Satisfactory dedicated server works#

The dedicated server is a free, separate download: Satisfactory Dedicated Server, Steam app id 1690800, fetched anonymously with SteamCMD. It has no graphics, no console commands for gameplay, and - this is the part that surprises people coming from other games - no meaningful text configuration.

Instead the server exposes a small HTTPS API, and the game client is the administration tool. You add the server's address in the client's Server Manager, claim it, name it, set an admin password and then either start a new game on it or upload a save. Every server setting after that is a control in that same panel. There is no server.properties to edit and no in-game chat command to kick somebody.

Two consequences follow. The good one: administration works identically whether the server is on your own machine, on a VDS or on a panel host, because it is all done through the client. The bad one: if the management port is not reachable, the server can be running perfectly and be completely unmanageable, which is a failure mode worth recognising early.

The server also runs the factory with nobody connected, unless Auto Pause is on. That single setting is the biggest gameplay decision you will make about hosting: a paused server costs nothing while you sleep, and a running one means the coal plants you left burning have produced something by morning.

Requirements and resource usage#

Memory tracks the save, and the save tracks the factory. Player count barely moves it.

• CPU: the factory tick is largely one thread, so clock speed decides how many belts and machines the server can keep honest. A second and third core do real work - networking, saving and asset streaming are not on the game thread - but they do not raise the ceiling on factory size.
• Disk: the install is around 12-15 GB. A late-game save is 50-250 MB, and the server keeps several rotating autosaves plus whatever you have saved by hand, so the save folder alone can reach a couple of gigabytes. Fast storage is what turns an autosave from a visible freeze into a stutter - what NVMe actually changes has the honest version of that claim.
• Players: Coffee Stain build and test around four. More will connect, but nothing above four is tuned, and each extra player adds both memory and game-thread cost.
• Network: light. A few hundred kilobytes per second per player. If people rubber-band, look at the server tick before you look at the link.

If you are unsure which resource you are short of, CPU vs RAM for game servers is the shortest route to an answer, and when to upgrade your plan covers the signals worth acting on.

Installing and starting the server#

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

On Windows the binary is FactoryServer.exe and the arguments are the same. For the Experimental branch, add -beta experimental to the app_update line - and note that the client must be on the same branch, because an Experimental client cannot join a stable server or the reverse. That mismatch produces a server that simply does not appear, with no error explaining why.

SteamCMD explained covers app ids, branches and update scripts if this is the first server you have installed this way. On a panel host you do not type any of it; the same values appear as fields on the Startup tab.

Claiming the server, and the Server Manager#

The first start produces a server nobody owns. Claiming it is done from the game client, once:

1. Open Satisfactory, then the Server Manager, then Add Server.
2. Enter address:7777. The client contacts the HTTPS API, not the game port.
3. The server appears as unclaimed. Choose Claim, give it a name, and set the Admin Password.
4. Optionally set a Client Password, which is the join password. Leave it empty for an open server.
5. Create a new game, or go to Manage Saves and upload one.

The admin password is what any other machine needs to administer the server later, and there is no recovery flow for it - losing it means restoring control the hard way, from the filesystem. Write it down somewhere that is not the same machine.

Uploading an existing single-player save is the usual way to start. Client saves live in %LOCALAPPDATA%\FactoryGame\Saved\SaveGames\<your id>\ on Windows; pick the .sav in Manage Saves and the client pushes it to the server. The server keeps its own saves under FactoryGame/Saved/SaveGames/server/, which is also where you would drop a file directly over SFTP if the upload is too large to go through the client.

The settings that exist, and where they live#

Server-level settings are in the Server Settings tab of the Server Manager. They apply to the server regardless of which save is loaded:

• Auto Pause - pause the simulation when the last player leaves. Saves CPU, stops production.
• Auto Save on Disconnect - write a save when a player leaves. Cheap insurance, one more write.
• Autosave Interval - minutes between automatic saves. Five by default.
• Number of autosaves - how many rotating copies to keep before overwriting the oldest.
• Network Quality - how much bandwidth the server is allowed to spend on updates. Higher is smoother and costs more.
• Send Gameplay Data - telemetry to Coffee Stain. Off is a valid answer.

Save-level settings are Advanced Game Settings, and they belong to the save rather than the server: no build cost, unlock all research, set the game phase, disable arachnids and so on.

Underneath, the server writes its configuration into FactoryGame/Saved/Config/LinuxServer/ (or WindowsServer/ on Windows). Change settings from the client rather than by editing those files: the running server holds its own copy and will write it back over yours. The one file worth touching directly is Engine.ini, where NetServerMaxTickRate under [/Script/OnlineSubsystemUtils.IpNetDriver] sets the server's network tick. Raising it can smooth movement for a small group with CPU headroom, and it is unsupported - if it makes things worse, put it back.

Ports and connecting#

Since the networking rewrite in Update 8, one port number does both jobs, and the older arrangement with a separate beacon and query port is gone. That is simpler, but it contains a trap: hosts and firewalls often allocate a game port as UDP only. With UDP alone the server is joinable by anyone who already has it configured and is completely invisible to the Server Manager, so you can neither claim it nor change a setting. If the client cannot see a server you know is running, that TCP side is the first thing to check. Game server ports explained covers why games end up with this split in the first place.

Players join through the Server Manager once the server is claimed and a session is loaded, or through a friend's session list. There is no public server browser, so the address is something you hand out.

Saves, autosaves and backups#

The regular hitch that players report as lag is usually the autosave writing a large file. Every machine, every belt segment, every item in transit and every item in a container is serialised, and on a mature factory that is a real amount of work.

• Lengthen the interval as the save grows. Five minutes is right for a new game and wrong for a two-hundred-hour one. Ten to fifteen minutes on a mature save trades a longer worst-case rollback for far fewer interruptions.
• Keep fewer rotating autosaves if disk is tight, but keep at least three. Corruption tends to be discovered a session later, not immediately.
• Take a manual save before anything structural: a game update, a mod change, a blueprint import, a big demolition.
• The autosaves are not backups. They live on the same disk as the save they protect and they are overwritten on a timer. A backup is a copy somewhere else, on a schedule, that you have restored at least once - backups that actually restore is worth the five minutes.

On RE:NODE, storage is NVMe throughout, which is what makes a large save write quickly rather than noticeably. Backup slots are included on every Satisfactory plan, taken on demand or on a schedule and stored off the machine they protect, and restoring one is a button. The Schedules tab can run the nightly backup and a weekly restart as ordered tasks, which is the whole maintenance routine for most groups - restart schedules that help covers picking the hour.

Why it gets heavier, and what to do about it#

Nothing about a Satisfactory server degrades. The save grows, and the cost of holding and writing it grows with it. Three things dominate:

1. Item count in transit. Belts hold items individually. A long belt network with everything running full is, to the server, a very large number of moving objects. Buffering into containers is cheaper than buffering on belts.
2. Building count. Every machine ticks. A thousand constructors cost a thousand ticks whether or not they have inputs.
3. Save size. Which is the first two, written to disk every autosave interval.

The practical responses, in the order they are worth trying: lengthen the autosave interval, remove belt loops and long idle belts that exist only as storage, demolish abandoned starter factories rather than leaving them running, and only then buy memory. Changing plan on RE:NODE adjusts the limits on the server you already have rather than rebuilding it, so the save stays where it is if you do decide the factory has outgrown the tier.

If everybody rubber-bands at the same moment, that is the server. If one player does and the others do not, that is their route to it - latency, jitter and packet loss covers telling the three apart, and the distinction is worth making before anybody buys a plan they did not need.

Mods with SML and the mod manager#

Satisfactory mods come from the mod repository at ficsit.app and load through SML, the Satisfactory Mod Loader. On a server, mods live in FactoryGame/Mods/ next to the game files, and every client must run the same mods at the same versions.

• Satisfactory Mod Manager can install to a remote server over SFTP or FTP, which is the least painful route if your host gives you those credentials. The command-line tool, ficsit-cli, does the same job in a script.
• Every game update breaks mods. SML itself is version-locked to the game, and a server that auto-updates on patch day is a server that will not start until the mod authors catch up. Turn automatic updates off on a modded server and update deliberately.
• Removing a mod that added buildings is destructive. Anything built with it disappears from the save, and what it was connected to may not survive the gap. Take a save you have tested first.
• Experimental and stable have different mod builds. Pick a branch and stay on it.

A modded server is also the usual answer to "why does it need four more gigabytes". Building mods raise the ceiling on what your factory can contain, and factories fill the space they are given.

Troubleshooting#

The Server Manager cannot see the server. TCP on port 7777 is closed, or the address is wrong. Game traffic is UDP and management is TCP; having only one of them produces exactly this.

"Server is already claimed" and nobody knows the password. The claim is stored in the server's config directory. Stopping the server and clearing that state is the only route back, and it means re-claiming and re-uploading, so keep the admin password somewhere safe.

The server does not appear after a game update. The client updated and the server did not, or one of them is on Experimental. Versions must match exactly.

Everything freezes for several seconds on a schedule. The autosave. Lengthen the interval; there is no setting that removes it.

The factory has not produced anything while we were away. Auto Pause is on. That is a choice, not a fault, but it surprises people who expected a dedicated server to keep running.

The server stops and restarts by itself under load. Memory. On RE:NODE, a container that reaches its limit is stopped and restarted clean rather than left to swap - which means you lose whatever happened since the last autosave, so a server running close to its ceiling should autosave more often, not less.

A save uploaded through the client fails or times out. Large saves are better placed directly into FactoryGame/Saved/SaveGames/server/ over SFTP, then picked from Manage Saves.

FAQ#

How much RAM does a Satisfactory server need?

Eight gigabytes for a new game with a small group, ten to twelve by mid game with several production sites and trains, and fourteen to sixteen for a mature megabase. Mods that add buildings add two to four on top, because the factory grows to fill what they make possible.

Why is there no config file for server settings?

Because administration moved into the game client in the 1.0 era. The server exposes an HTTPS API, the client's Server Manager is the front end for it, and the files the server writes underneath are its own state rather than an interface. Edit them and the running server overwrites you.

Does the factory keep running when nobody is online?

Only if Auto Pause is off. With it on, the simulation stops when the last player leaves and resumes when somebody joins. Off means overnight production, more CPU use, and a save that keeps changing while you are not there.

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

Yes. Upload it through Manage Saves in the Server Manager, or drop the .sav into the server's save folder directly. Progress, blueprints and the map all come with it; achievements are already governed by whether the save has Advanced Game Settings enabled.

Do all players need the same mods?

Yes, the same mods at the same versions, and the same SML version. There is no partial matching, and a mod that auto-updated for one player breaks that player only, which makes it look like their problem rather than a version problem.

Is the autosave hitch fixable?

Not removable, only reducible. Faster storage shortens it, a longer interval makes it rarer, fewer rotating copies makes each write cheaper, and a smaller factory makes it smaller. A server that hitches on a schedule is saving, not lagging, and the fix is a setting rather than a bigger plan.