Satisfactory Server Performance Tuning and Optimization

Satisfactory is one of the more demanding games to host as a dedicated server, and it gets more demanding the longer your factory grows. This guide is the practical version of "what actually moves the needle" — what to monitor, what to change, and which optimisations are worth your time.

Tick rate (TPS), the one number that matters

Satisfactory's server targets 30 ticks per second. Each tick the server walks the entire simulation: every belt, every machine, every vehicle, every pipe. Hold close to 30 and the game feels right; drop noticeably below it and players will start describing the experience in increasingly creative ways ("everything's stuttery", "trains keep teleporting", "I think your host is bad").

In practice you do not need a precise TPS readout to know something is wrong. The early symptoms are belts visibly stuttering, vehicles snapping, and a vague sluggishness when interacting with machines. When players report any of those, suspect TPS first.

The biggest drivers of TPS loss, in rough order of impact:

• A very large active factory (machine count, belt length, pipe networks).
• Lots of vehicles, especially trucks doing pathfinding.
• Mods that do heavy server-side work each tick.
• The server briefly pausing for an autosave (this is normal — see below).
• Memory pressure forcing the server into swap (this looks like a network problem and is not).

Satisfactory's server simulation is largely single-threaded, so CPU clock speed and IPC matter more than core count. LOW.MS Satisfactory plans run on modern Ryzen hardware specifically because the per-thread performance is what this workload actually wants.

RAM: it's about factory complexity, not players

The most common misunderstanding about Satisfactory hosting is that RAM scales with player count. It does not. Two players building a sprawling megabase will burn more memory than ten players who just landed.

What actually drives RAM usage:

• Factory size and complexity. Every machine, conveyor segment, pipe, vehicle, and powered building takes up space in memory.
• Long uptimes. The server slowly accumulates state over multi-day sessions even when nothing is being built. A scheduled restart resets this — see below.
• Autosave spikes. When an autosave fires, the server briefly needs additional headroom to serialise the world. If you are already running close to your memory ceiling, this is the moment crashes happen. The fix is either more RAM, a longer autosave interval, or both.

Monitoring RAM on LOW.MS

The service overview page in the panel shows live Players / CPU / Memory / Bandwidth meters with an Auto Refresh toggle, so you can leave it open and watch values in real time. For historical trends rather than the current second, the Current Activity & Stats entry in the sidebar gives you charts over time.

If RAM is consistently sitting above 80% of your allocation, you are one bad autosave away from a crash. Upgrade or optimise.

How much RAM do I need?

Resist the urge to pick a tier from a table — RAM scales with what you build, not with how many people you build it with. The honest version of the answer is:

• A fresh save will sit happily under 6 GB.
• A respectable mid-game factory pushes 8–10 GB.
• A late-game world with nuclear, drones, and a serious building count can comfortably eat 12 GB or more.
• Megabase territory and heavy mod loads can run higher again.

If you are not sure where you sit, round up. The gap between "comfortable" and "out of memory" is much smaller than people expect, and the symptoms of running out look identical to a slow network — which is why people often blame their host instead of their own factory growth.

Configuration: trust the defaults

Important: LOW.MS ships some additional Game.ini tuning by default to head off the most common Satisfactory multiplayer performance issues. Unless you have a specific reason and know what you are doing, leave the tuned values alone — the defaults we ship are deliberate.

For most groups the only config edit worth making is bumping Engine.ini connection timeouts so players on slower connections finish first-time syncs without being dropped. You can do this through Configuration Files in the panel sidebar. A safe Engine.ini block looks like this:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=30
LanServerMaxTickRate=30
InitialConnectTimeout=60.0
ConnectionTimeout=60.0

[/Script/SocketSubsystemEpic.EpicNetDriver]
NetServerMaxTickRate=30
LanServerMaxTickRate=30

[/Script/Engine.Engine]
NetClientTicksPerSecond=30

Notes:

• NetServerMaxTickRate=30 matches Satisfactory's 30 TPS simulation target. There is no benefit to pushing it higher than the simulation can produce.
• The 60-second timeouts are a conservative bump from the 30-second defaults and are useful when players are syncing very large saves on first connect.

INI files live in FactoryGame/Saved/Config/WindowsServer/. Always stop your server before editing — Satisfactory writes to these files on graceful shutdown and will overwrite changes made to a running server. For the full settings reference, see the server settings guide.

Network Quality is the actual fix for "lag"

Most "my server feels laggy" complaints are not a server problem at all — they are the Network Quality setting being left on Low. Set it to Ultra on the server and on every connecting player's client. Do this once and the majority of rubber-banding, snapping, and "it feels off" complaints quietly disappear.

This is not gradual. There is no benefit to easing up to Ultra. Start at Ultra and only consider reducing it if you have a specific bandwidth-constrained player who genuinely cannot run it.

The common issues guide covers this in more detail, including why "Low" is a misleading default in the first place.

Schedule restarts in the LOW.MS panel

Satisfactory servers creep upward in memory use over long uptimes. A scheduled daily restart is one of the highest-leverage things you can do for stability — it clears accumulated state, reloads the save fresh, and resets any slow runtime growth.

The in-game Server Manager does not include a scheduled restart feature. Schedule it from Scheduled Tasks in the LOW.MS panel sidebar. Pick a time when nobody in your group is online (most groups use the early hours of the morning) and set it to daily. If your factory is enormous, twice a day is even better. The downtime is typically under a minute and the difference afterwards is noticeable.

Autosave interval: tune it to your save size

Autosaves are essential, but they cost you a brief pause while the server writes the file to disk. On a small factory you will not notice. On a large one you absolutely will.

Rules of thumb:

• Under 50 MB: leave the default 300 seconds (5 minutes) alone.
• 50–150 MB: still mostly fine on 300, but if you start noticing little hitches every five minutes, push out to 600.
• 150 MB and up: use 900 or higher. Past this point the autosave hitch is the most visible performance issue you have, and reducing how often it occurs is more important than the marginal data-loss risk from waiting longer.

Do not go below 300. More frequent autosaves do not meaningfully reduce data loss risk, and they multiply how often you feel the hitch. Your real safety net is scheduled backups and rotating autosave slots, not a faster cadence.

Factory design choices that genuinely help

These are the design changes that show up as measurable TPS wins.

Trains beat trucks

Trucks recalculate pathfinding constantly — every truck on the map is continuously evaluating obstacles and route adjustments. Trains follow fixed tracks with predetermined stops and are much cheaper to simulate. If you have more than a couple of truck routes in active use, switching them to rail will measurably help your tick rate.

Fewer vehicles overall

Every vehicle — trucks, tractors, explorers, drones — costs simulation time. Drones are relatively cheap; large fleets of ground vehicles are not. Consolidate where you can.

Don't leave idle machines powered

A machine that is powered but waiting on inputs (or backed up on outputs) still costs simulation cycles. If a section of your factory is currently doing nothing useful, switch its power off rather than leaving it sitting there. The cleanest way to do this is to put non-essential sections behind a power switch from the start.

Conveyors: shorter runs, more buffers

Extremely long conveyor runs are more expensive to simulate than the same total throughput broken into shorter segments with storage in between. If you find yourself running a single belt across half the map, breaking it up with a buffer will help.

Save file size as a rough health indicator

Save file size is a usable proxy for how much your server is being asked to simulate each tick. As a very rough guide: under 50 MB you have nothing to worry about, 50–150 MB is normal mid-game territory, 150 MB and up is when you should already have applied the optimisations on this page, and 300 MB+ is megabase scale where every tip in this guide matters.

Your save file size shows up in the LOW.MS file manager. Watching it grow over time tells you when to pre-emptively bump RAM rather than waiting for the first crash.

When it's time to upgrade the plan

If you have done the above and your server is still struggling, the most common useful upgrade is RAM. Symptoms that point at this:

• Crashes that happen specifically during autosaves.
• TPS that recovers after a restart but degrades over the day.
• RAM consistently above 80% in the panel graphs.

Bump RAM through the LOW.MS control panel — changes typically apply on the next billing cycle, or you can ask support for an immediate upgrade if you are firefighting.

The short version

Set Network Quality to Ultra everywhere. Schedule a daily restart from the LOW.MS panel. Push autosave intervals out as your factory grows. Use trains instead of trucks. Watch your RAM graph and upgrade before you hit the ceiling, not after the first crash. Trust the LOW.MS-shipped Game.ini defaults — they exist for a reason. That is most of what this guide is, condensed.

Related guides

• Server settings guide — full configuration file reference.
• Common issues and fixes — troubleshooting the symptoms this guide tries to prevent.
• Getting started — initial server setup.
• Admin guide — administrative tasks.
• Mods guide — performance impact of mods.