Satisfactory server lag in large factories

A Satisfactory dedicated server gets slower for three reasons, and none of them is the number of players. The factory simulation grows with every machine and every item on a belt; the save grows with it, so every autosave freezes the game for longer; and the server has to send each player the state of everything near them, which in a dense factory is a lot of state. Memory follows the save - 8 GB is comfortable for a new world, a mature megabase wants 12-16 GB. The fixes are mostly build choices: fewer, overclocked machines, trains and drones instead of trucks, storage in containers rather than on belts, and an autosave interval chosen on purpose. This post explains where the cost comes from, how to tell which kind of lag you have, and what to change.

Installing and claiming a server is covered in the Satisfactory dedicated server guide, and the Server Manager settings in Satisfactory server settings and saves. This post starts once the factory is big enough to hurt.

Where a Satisfactory server spends its time#

The server runs the whole factory. Machines in a corner of the map nobody has visited for days are still producing, belts are still moving items and trains are still running their timetables. That is the point of a dedicated server, and it means the factory's cost does not depend on where the players are standing.

The work divides into four parts:

• Factory simulation. Every machine, belt, splitter, pipe, train and vehicle updates. This runs largely on one game thread, so clock speed decides the ceiling.
• Replication. For each connected player, the server works out which nearby objects have changed and sends them. A player standing in the middle of a 300-machine block costs much more than one standing in a field.
• Saving. The whole world is serialised into one .sav file on every autosave. The time this takes grows with the factory.
• Memory management. The engine periodically cleans up memory. On a big world that cleanup is a short stall you can feel.

Only the first of these is helped by a faster CPU core. The second is helped by fewer players in the densest areas and by network settings. The third is helped by fast storage and a smaller world. The fourth is helped by more memory headroom and by restarts.

Telling the kinds of lag apart#

The fourth and fifth rows are not the server at all. A player whose PC renders three thousand lights at 25 frames a second will call it lag; so will a player on a congested route. Latency, jitter and packet loss covers telling a network problem from a server problem.

The first row is the most common complaint on a mature server, and it is the one people most often misdiagnose as "the server needs more RAM".

The autosave freeze#

Satisfactory has no incremental save. Every autosave writes the entire world - every building, every item on every belt, every vehicle and its path - into one file, and while that happens the game thread is busy.

Save size grows with the factory:

Three things reduce the freeze:

1. Fast storage. The write is large and sequential. NVMe turns a multi-second freeze into a short one; what NVMe actually changes is honest about the cases where it matters, and this is one.
2. A smaller save. Items on belts are saved individually. A factory with long belts running full and backed up into a dead end stores every one of those items. Emptying belts used as storage shrinks the file.
3. A deliberate interval. The Server Manager's autosave interval defaults to five minutes. Ten halves how often anyone notices, and doubles what a crash costs. Pick a number you can live with in both directions.

There is a fourth thing that does not help: deleting old autosaves to save disk. The rotating autosaves are the cheapest protection you have, and each one is only the size of the save.

Build choices that keep a factory cheap#

The biggest performance gains in Satisfactory come from how you build, not from server settings. A few principles apply to almost every large factory.

Fewer machines doing more. Power Shards overclock a machine up to 250%, and Somersloops - in 1.0, production amplification - multiply output without more buildings. Ten overclocked constructors do the work of twenty-five at normal speed, and every one you do not build is a building the server does not tick, replicate or save. Power is the cost; power is cheaper than performance.

Containers instead of belts as storage. Items on a belt are individually tracked objects. Items in a container are a count. A belt loop or a long backed-up belt acting as a buffer is one of the most expensive structures you can build. Feed into an Industrial Storage Container and out again.

Trains and drones, not trucks. Automated trucks and tractors are the worst offenders on servers. Vehicles following a recorded path are physics-driven, they cost more the more there are, and on dedicated servers they have a long history of getting stuck, drifting off their path or stopping when nobody is nearby. Trains run on fixed tracks and are cheap. Drones are cheaper still for low-volume long-distance logistics.

Dimensional Depot uploads. In 1.0 the Dimensional Depot lets you send items into central storage and build from it directly. Using it for construction materials removes whole networks of belts that existed only to bring concrete and steel beams to a build site.

Foundations are not the problem. Since Update 8, foundations, walls and other simple building pieces are handled as lightweight buildables, which are far cheaper than they used to be. Big floors and walls cost memory and save size, but not much simulation. Machines and items moving are what costs.

Lights and signs cost frame rate, not server time. Hundreds of lights in one area are rendered by each client. If a factory's frame rate is poor on everyone's PC but the server's graphs are calm, look at lights before anything else.

Replication and the number of players#

Satisfactory is built and tested around four players. More can join with a configuration change described in Satisfactory server settings and saves, and every extra player costs more than the last, because each has their own set of nearby objects to keep up to date.

Replication cost depends on what is near each player, not on how big the factory is overall. Four players standing in the same dense manufacturing block share a lot of state. Four players in four different dense blocks multiply it. That is why rubber-banding in a big factory often stops when the player walks out into the open.

Two things help:

• The Network Quality setting in the Server Manager. It trades bandwidth and server work per client for smoothness. Raising it helps when vehicles and other players stutter while the factory is fine. On a server that is already CPU-bound, lowering it reduces per-player work.
• Engine bandwidth limits. The community has long recommended raising the Unreal Engine network bandwidth caps in the server's Engine.ini and Game.ini for large factories, so that replication is not throttled. The keys are standard Unreal ones, such as MaxClientRate and MaxInternetClientRate under [/Script/OnlineSubsystemUtils.IpNetDriver], and TotalNetBandwidth under [/Script/Engine.GameNetworkManager]. Coffee Stain does not document them as supported settings, the right values depend on your connection, and their effect has changed between game versions - check the Satisfactory wiki's dedicated server page for the current advice before editing, and keep a copy of the original files.

[/Script/OnlineSubsystemUtils.IpNetDriver]MaxClientRate=104857600MaxInternetClientRate=104857600

Players have their own Network Quality option in the client settings too; if one player stutters more than the others, check theirs.

Memory: how much and why it grows#

Memory tracks the save. A bigger factory means more objects held in memory, and Unreal's memory use only ever grows during a session.

Two things are worth understanding.

Saving needs extra memory. Serialising the world briefly holds a copy of a lot of it. A server that runs at 90% of its limit is most likely to hit the limit exactly during an autosave - which is the worst possible time, because the save is interrupted.

Memory does not come back during a session. A server that has run for a week uses more than the same world freshly started. Engine cleanup passes reclaim some, and on a large world those passes are the short hitches you feel between autosaves. A regular restart resets it.

RE:NODE's Satisfactory plans run from 8 GB to 14 GB. A container that reaches its limit is stopped and restarted clean rather than left to swap, which protects the machine but costs everything since the last save; if the memory graph climbs close to the limit, move up a tier before it becomes a habit. Changing plan adjusts the limits on the existing server rather than rebuilding it, so the save stays where it is. When to upgrade your plan has the signals worth acting on.

CPU and what a faster core buys#

The factory tick runs mostly on one thread. On a graph that looks like one core pinned and the rest idle, which on a multi-core allocation averages out to a figure that looks fine. Reading a server load graph covers why a single-threaded game can be saturated at 40% reported CPU.

What extra cores do buy: saving, networking and engine housekeeping run off the game thread, so a second and third core stop those from competing with the factory. Beyond that, more cores do nothing for factory size. What more clock speed buys is a higher ceiling on how much factory can tick per second before production rates themselves fall behind.

When the factory tick is over budget, the symptoms are subtle: machines produce slightly under their rated speed, trains arrive late, and the whole world feels slightly sticky. The response, in order: demolish what you do not need, consolidate with overclocking and Somersloops, replace trucks, empty belt buffers - and only then consider a bigger plan.

Restarts and housekeeping#

A scheduled restart is the simplest performance measure for a large Satisfactory world. It clears accumulated memory, resets the engine's cleanup cost, and gives a clean save point.

The Server Manager has a Server Restart Time Slot setting that lets the server restart itself at a chosen hour. On a panel host you can also use a schedule - on RE:NODE the Schedules tab runs a restart and a backup on a cron expression, so the nightly copy is taken just after a clean save. Make sure Autosave on Player Disconnect is on, so the last player leaving always writes the world.

Weekly is enough for most groups; daily is reasonable for a megabase that climbs noticeably in memory. Restart schedules that help goes into timing.

Before every game update, take a backup. Saves are forward-compatible only: a save opened by a newer version cannot go back to the older one, and an update that hurts performance cannot be undone without the copy. Backups that actually restore explains why restoring one occasionally is part of the job.

Troubleshooting#

Freeze every five minutes. The autosave. Check that the freezes match the interval, then shrink the save and lengthen the interval a little.

Freezes got worse after building a new site. More items in transit and more machines in the save. Check for belts used as buffers in the new build.

Trucks stop or wander off their routes. A known weakness of automated vehicles on dedicated servers. Replace the route with a train or drones.

Server restarted itself mid-session. Probably the memory limit, possibly during a save. Look at the memory graph before the restart - why your game server keeps restarting has the patterns.

One CPU core pinned with nobody online. Auto Pause is off, so the factory runs around the clock. That is a choice; turn Auto Pause on if you did not mean it.

Rubber-banding only in the main base. Replication. Network Quality and fewer players in the densest area help; a bigger plan usually does not.

FAQ#

Does more RAM make a Satisfactory server faster?

Only if it was short of memory. RAM lets the server hold a bigger factory without being stopped at its limit; it does not make the factory tick faster or the save shorter. Faster cores and a leaner factory do that.

How big can a Satisfactory factory get on a dedicated server?

There is no hard limit. The practical one is when the autosave freeze and the factory tick become unpleasant. Groups that build with overclocking, trains and containers get far further than groups with truck routes and belt buffers.

Are trains bad for performance?

No. Trains are one of the cheapest ways to move a lot of material. Large numbers of complicated junctions with heavy signalling add some cost, but trucks and belt loops are far worse.

Why does the game lag when everyone is in the same factory?

The server sends each player the changing objects around them. Several players in the densest block multiply that work. Spreading out, or raising Network Quality if the server has CPU to spare, helps.

Should I turn off Auto Pause for a big factory?

Only if you want production while nobody plays. With it off the factory runs, the save grows and one core stays busy all day. With it on, the world waits for you.