If your Satisfactory server feels laggy, ninety percent of the time the problem is one setting. Fix it and most of the rest of this guide is fine-tuning.
The one setting that fixes most "lag"
Open your server's settings and find Network Quality. It is set to Low by default, which is an odd choice on Coffee Stain's part but here we are. Set it to Ultra. Then — and this is the part people miss — every player connecting to the server has to set it to Ultra on their own client too. If anyone is still on Low, they personally will see rubber-banding even if everyone else is fine.
That is it. That is the fix for the vast majority of "the host is bad" complaints I have ever read. Belts that stutter, vehicles that teleport, builds that snap to the wrong grid square — almost always Network Quality. Try it before you blame your hosting provider, your router, or your friend's apartment wifi.
The reason it works is that "Low" genuinely means low. The server is sending a stripped-down stream of state updates per tick, and the client is interpolating across the gaps. On Ultra it sends the full picture and everything snaps into place. The cost is more bandwidth, which on any modern connection is irrelevant.
Auto-pause: a question of play style
Auto-pause is on by default. When the last player logs off, the server pauses everything — belts, generators, autosaves, the lot.
If your group plays in scheduled sessions and treats the factory like a board game you put back in the box, leave it on. It saves a bit of CPU and you start exactly where you left off.
If you want production to happen overnight, or different people log in at different times and expect things to keep running while they are away, turn it off. There is no performance difference while anyone is online — it only matters between sessions. Most groups end up turning it off once their first overnight smelter run pays off a milestone the next morning.
Autosave interval — the only setting where save size matters
The default is 300 seconds (5 minutes). On a small factory you will never notice it. On a large one you absolutely will, because the server briefly pauses to write the save file to disk and a 150 MB save takes meaningfully longer to write than a 10 MB one.
Rule of thumb: if your save file is under 50 MB, leave the interval alone. If it is 50–150 MB, leave it alone unless you start noticing little hitches roughly every five minutes (that is your autosave). If it is 150 MB or more, push it out to 600 or 900 seconds.
Do not go below 300. More frequent saves do not meaningfully reduce data loss risk, and they do increase how often you feel the hitch. Your real safety net is a separate backup system, not a more aggressive autosave.
Player counts and what actually breaks
Satisfactory's server defaults to a max of 4 players because that is the number Coffee Stain optimises for. The cap can technically go far higher. The interesting answer is somewhere in between, and it depends almost entirely on what your group is doing rather than how many people are logged in.
Two to four players is the sweet spot — anything will run it. Five to eight is comfortable on a server with 12 GB or more RAM and a fast modern CPU, with the occasional hitch when several people are mass-placing buildings simultaneously. Nine to sixteen is where you start needing actual conversations about how you build — coordinating big construction phases instead of everyone hammering the placement key at once. Above sixteen is mostly a stress test of patience; the simulation is single-threaded enough that more bodies do not really translate into more fun.
The number that matters is not players — it is concurrent building activity. Ten players placidly running their existing factory is much easier on the server than three players doing a mass copy-paste of a Smart!-built modular blueprint.
Restart it on a schedule
Even with the memory improvements that came with the 1.1 patches, Satisfactory servers do creep upward in memory use over long uptimes. Schedule a daily restart for some hour nobody plays — pick whatever your group's "nobody is awake" window is. If your factory is huge, every twelve hours is better. The restart is fast and the experience after one is noticeably crisper.
If your host is LOW.MS, this is a single setting in the Scheduled Tasks sidebar entry on your service's panel page. Most managed hosts have something similar.
The Update 1.1 port change you might have missed
If you are coming from an older guide, the port situation has been simplified. Satisfactory used to want four ports open. Now you only need two:
- Game port: 7777 (UDP for game traffic, TCP for the HTTPS server API)
- Reliable messaging port: 8888
The old beacon and query ports (15000 and 15777) are no longer used. If you are on a managed host this is handled for you; if you are self-hosting, close the old ones and stop forwarding them. A fair number of "I cannot connect to my friend's server" threads are still people forwarding the wrong ports because they are following pre-1.1 instructions. If a player still hits the encryption token missing error after that, the linked guide covers the fix.
A note on hand-editing your server config
A managed host worth using will ship sensible Game.ini and Engine.ini defaults out of the box — LOW.MS, for example, ships some additional Game.ini tuning by default to head off the most common Satisfactory multiplayer performance issues. If your host does the same, leave the config alone unless you have a specific reason and know what you are doing.
If you are self-hosting, the only edit most people genuinely need is bumping InitialConnectTimeout and ConnectionTimeout in Engine.ini to 60 seconds, which gives players on slower connections more grace during first-time syncs.
Things that look like server problems but are not
Three symptoms get blamed on the host that almost never are.
Rubber-banding. Network Quality. Always. If you have already fixed Network Quality on every client and it is still happening, check whether the server is running out of RAM — a server that is swapping to disk produces exactly the same symptoms as a network problem and is much more likely than a real network issue on a managed host.
Lag spikes at suspiciously regular intervals. That is your autosave hitting. Time the gap with a stopwatch — if it lines up with your autosave interval, you have your answer.
Crashes after long sessions. Memory creep. Schedule a restart. If it crashes even after restarts, your save has outgrown your RAM allocation.
The fourth one — the genuinely weird desync where two players see different things in the same place — is almost always a mod version mismatch. More on that in the mod guide.
Client-side, briefly
Each player should also:
- Set their own Network Quality to Ultra (yes, repeating it, that is the point).
- Leave Send Gameplay Data alone unless they are on a really constrained connection.
- Disable client-side autosave for dedicated server play. The server is handling saves; the client autosave is redundant and can cause its own little stutters.
Do these once per player, never think about them again.
The honest summary
Set Network Quality to Ultra everywhere. Give the server enough RAM for whatever your factory wants to grow into. Schedule a restart. Open the right two ports. Trust the LOW.MS-shipped Game.ini defaults. That is it. Everything else in this article is fine-tuning around those points.
If you would rather not think about most of this, our Satisfactory hosting plans come with the right defaults set out of the box.