Satisfactory Server Performance Optimization Guide
Expert guide to maximizing performance on Satisfactory dedicated servers. Learn how to optimize tick rate, reduce memory usage, handle large factory saves, and eliminate lag for smooth multiplayer gameplay.
Patch 1.1.2.0 (November 2025): This patch fixed a severe memory leak affecting long-term saves. If you've been experiencing crashes related to memory limits or "UObjects", update your server immediately.
Important Limitation: Satisfactory dedicated servers primarily use a single CPU core, which severely limits performance. Multi-core CPUs don't provide proportional benefits - focus on single-thread performance (higher clock speeds).
Understanding Performance Bottlenecks
Primary Performance Factors
- Single-Core Limitation: Server runs mostly on one core - prioritize CPU clock speed over core count
- Object Count: Each building, conveyor, and item adds to CPU load
- Network Replication: Data synchronization between server and clients
- Save File Size: Large saves increase load times and memory usage
- Tick Rate: Server updates per second (default 60, can be reduced)
- Memory Usage: RAM consumption grows with factory size (leaks fixed in 1.1.2.0)
Server Configuration Optimization
Server Settings That Actually Exist
There is no ServerSettings.ini in a Satisfactory dedicated server. The settings the server itself owns are integer entries in GameUserSettings.ini, under the class section for its settings object, in FactoryGame/Saved/Config/LinuxServer/:
[/Script/FactoryGame.FGGameUserSettings]
mIntValues=(("FG.DSAutoPause", 1))
mIntValues=(("FG.DSAutoSaveOnDisconnect", 1))
mIntValues=(("FG.AutosaveInterval", 900))
FG.DSAutoPause is the biggest single saving on a server that is not busy around the clock: the simulation stops when the last player disconnects, and a paused server costs almost no CPU. FG.AutosaveInterval raises the gap between autosaves, which is what you want on a large factory where each save is a visible hitch. FG.ServerRestartTimeSlot and FG.NetworkQuality exist too and take the same form.
Engine Net Settings
Tick rate and client bandwidth are Unreal settings rather than Satisfactory ones, so they go in Engine.ini, under the net driver section:
[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=45
MaxInternetClientRate=100000
MaxClientRate=100000
Settings that do not exist, and what happens if you use them. We checked these against the shipped 1.2.4 server build, across all 351 of its modules: there is no ServerSettings.ini file, no [/Script/FactoryGame.FGReplicationDetailActor] section, and no mCullDistance or bEnableCulling key. ServerName, ServerPassword and ServerDescription are not config keys either: the server name and passwords are set through the in-game Server Manager or the server's HTTPS API, never by editing a file. Unreal silently ignores a config section it does not recognise, so a block built from those names costs nothing and does nothing, which is exactly why it survives in so many guides.
Launch Parameters
# Confirmed present in the 1.2.4 server build
-log -unattended -multihome=0.0.0.0 -Port=7777
# Headless: no renderer, no audio
-nullrhi -nosound
# Threading and memory
-useperfthreads -MaxMemoryUsage -lowmemory
Six arguments that circulate for Satisfactory are not in this build at all: -startserver, -nosteamclient, -USEALLAVAILABLECORES, -malloc=system, -nomansky and -nohomedir. They are inert rather than harmful, but they are not doing the thing you are adding them for.
One more is worth calling out on its own, because it is still copied into new guides. -ServerQueryPort=15777 appears in none of the build's modules. It belonged to the pre-1.0 server, which used separate game, query and beacon ports; current builds no longer take it. If you are following a guide that opens 15777, check what your server is actually listening on before you change firewall rules around it.
Memory Management Strategies
Reducing RAM Usage
Problem:
Satisfactory servers can consume 8-16GB+ RAM with large factories, causing crashes and slowdowns.
Solutions:
- Enable Texture Streaming: Set
r.TextureStreaming=1in Engine.ini - Reduce View Distance: Lower
r.ViewDistanceScale=0.7in clients (not server) - Clean Up Items: Remove abandoned items and debris with SCIM editor
- Memory Limit: Use
-MaxMemoryUsage=8192launch parameter (8GB limit)
Handling Large Save Files
Problem:
Save files over 100MB cause long save/load times and increased memory pressure.
Solutions:
- Increase Autosave Interval: Set
mAutosaveInterval=1800(30 minutes) - Use Incremental Saves: Enable
mUseIncrementalSaves=1in Game.ini - Compress Saves: Enable
mCompressSaveGames=1(adds CPU load) - Manual Save Management: Keep only last 3-5 saves, archive older ones
Network Performance Optimization
Reducing Bandwidth and Lag
Net tick rate and client bandwidth are Unreal Engine settings, and they live under the net driver section, not under [/Script/Engine.NetworkSettings]. Put them in FactoryGame/Saved/Config/LinuxServer/Engine.ini:
[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=30
MaxInternetClientRate=50000
Lowering the server tick rate from the default is the lever that actually pays on a large factory, because replication cost scales with how often the server tells every client what moved. Thirty is a reasonable floor for a build-heavy save; going lower starts to show as visible stutter on conveyors.
Settings you may have seen elsewhere that do not exist. We checked these against the shipped 1.2.4 server build, across all 351 of its modules: NetClientMaxTickRate, ReplicationBandwidthLimit, mCullDistance and bEnableCulling appear nowhere in it, and neither does the section [/Script/FactoryGame.FGReplicationDetailActor]. Unreal silently ignores a config section it does not recognise, so a block built out of those names costs you nothing and does nothing. If a guide hands you one, that is the tell.
Server-Side Settings That Are Real
The dedicated server does expose its own switches, as entries in the [/Script/FactoryGame.FGGameUserSettings] section of GameUserSettings.ini:
[/Script/FactoryGame.FGGameUserSettings]
mIntValues=(("FG.DSAutoPause", 1))
mIntValues=(("FG.DSAutoSaveOnDisconnect", 1))
FG.DSAutoPause stops the simulation when the last player disconnects, which is the single largest CPU saving available on a server that is not busy around the clock. FG.DSAutoSaveOnDisconnect writes a save at the same moment. Both are read by the dedicated server itself rather than by the save, so they survive loading a different session.
Client-Side Optimizations
- Reduce Graphics Settings: Lower shadow quality, post-processing, and effects
- Update Drivers: Ensure latest GPU and network drivers
- Wired Connection: Use Ethernet instead of Wi-Fi for stable latency
There is no -NoFoliage launch argument. It does not appear anywhere in the shipped build, so passing it changes nothing. Foliage density is a video setting in the client's own options menu, and it is a client-side cost only: it never reaches the dedicated server, which runs headless and draws nothing.
Factory Design for Performance
Efficient Building Practices
Best Practices:
- Minimize Conveyor Lengths: Shorter belts reduce update calculations
- Use Manifold Systems: Simpler than load balancers, less CPU intensive
- Limit Particle Effects: Reduce smoke, sparks, and visual effects
- Optimize Power Grid: Consolidate power plants and reduce wire complexity
- Avoid Excessive Lighting: Lights add to rendering and update costs
Problematic Constructions to Avoid
- Massive Storage Arrays: Each storage container tracks individual items
- Excessive Splitters/Mergers: Each adds to simulation complexity
- Long Distance Belts: Prefer trains or drones for long-haul transport
- Over-Clocked Machines: Higher clock speeds increase update frequency
- Unnecessary Foundations: Large foundation areas increase collision checks
Monitoring and Diagnostics
Performance Monitoring Tools
# Windows Performance Monitor
# Track: Process\Private Bytes, Processor\% Processor Time
# Linux monitoring commands
top -p $(pgrep FactoryServer) # CPU/RAM usage
iftop -i eth0 # Network bandwidth
iotop # Disk I/O
# Satisfactory built-in stats
Open console (~) and type:
stat fps # Client FPS
stat unit # Performance breakdown
stat net # Network statistics
Identifying Performance Issues
| Symptom | Likely Cause | Solution |
|---|---|---|
| Server tick rate drops below 30 | High object count | Reduce factory complexity, increase cull distance |
| Clients experience rubberbanding | Network congestion | Lower NetServerMaxTickRate, optimize replication |
| Long save times (60+ seconds) | Large save file | Increase autosave interval, clean up with SCIM |
| Memory usage constantly increases | Memory leak | Restart server daily, monitor with process explorer |
| Clients disconnect frequently | Packet loss/timeout | Check network stability, reduce bandwidth limits |
Advanced Optimization Techniques
Engine.ini Tweaks
[/Script/Engine.RendererSettings]
r.ShadowQuality=0
r.DistanceFieldShadowing=0
r.DistanceFieldAO=0
r.AmbientOcclusionLevels=0
r.DefaultFeature.AntiAliasing=1
r.Tonemapper.Quality=0
[/Script/Engine.StreamingSettings]
r.Streaming.PoolSize=512
r.Streaming.UseFixedPoolSize=1
[/Script/Engine.GarbageCollectionSettings]
gc.TimeBetweenPurgingPendingKillObjects=30
gc.MaxObjectsNotConsideredByGC=500000
Dedicated Server Hardware Recommendations
Small Factory (up to 1000 buildings):
- CPU: 4+ cores @ 3.5GHz+
- RAM: 8GB DDR4
- Storage: SSD with 50GB free
- Network: 100 Mbps upload
Large Factory (5000+ buildings):
- CPU: 8+ cores @ 4.0GHz+
- RAM: 16GB+ DDR4
- Storage: NVMe SSD with 100GB+ free
- Network: 500 Mbps+ upload
When to Upgrade Hardware
Consider upgrading your server when:
- Tick rate consistently below 20 even after optimization
- Memory usage exceeds 90% during normal operation
- Save/load times exceed 5 minutes
- More than 8 players experience simultaneous lag
- Factory expansion plans exceed current capacity
Pro Tip: Regular server restarts (every 24 hours) can clear memory leaks and improve performance. Schedule restarts during low-activity periods.
Network Quality setting vs CPU cost (refreshed 2026-05)
The most commonly mis-configured performance setting on a Satisfactory dedicated server is Network Performance (sometimes called "Network Quality"). It has four values: Ultra, High, Medium, Low. Ultra is the default for fresh installs, but Ultra demands very high single-thread CPU performance. On mid-tier desktop CPUs like an i5-12400F or Ryzen 5 5600, Ultra saturates the replication core and causes laggy projectiles, vehicle stutter, and missed input acknowledgement.
| Setting | Target tick | Approx CPU cost | Recommended hardware |
|---|---|---|---|
| Ultra | 60 Hz | 100% baseline | Ryzen 9 / i9, 5.0GHz+ boost |
| High | 45 Hz | ~70% of Ultra | Ryzen 7 / i7, 4.5GHz+ boost |
| Medium | 30 Hz | ~50% of Ultra | Ryzen 5 / i5, 4.0GHz+ boost |
| Low | 20 Hz | ~33% of Ultra | Older or shared CPU cores |
If your server tick rate falls below the setting's target during normal play, drop one tier. The visible drop in tick smoothness is usually less noticeable than the cumulative effect of CPU saturation (projectile lag, vehicle stutter, missed action confirmation). For a deeper diagnostic flow including Engine.ini MaxInternetClientRate tuning and NIC-level optimizations like disabling Large Send Offload, see our network quality CPU bottleneck guide.
Reading the CPU graph: factory throughput drives the number
Your plan grants N CPU cores. The percentage in the panel is per-process across all cores. Satisfactory's UE5 server scales heavily with belt counts, factory tick load, and player count - 150-300% with a mid-game factory is normal, and a late-game mega-factory can sit at 300-450% steady on a 6-core plan. The honest question is not "is the number high" but "are we hitting the cgroup ceiling?" Use the throttling check in the cross-game CPU explainer. If you are not throttled, you are not in trouble.
Need optimized Satisfactory server hosting? Launch your Satisfactory server with Supercraft for premium hardware and automated performance tuning. Plans default Network Quality correctly for the underlying CPU tier so you don't have to guess.