Satisfactory Dedicated Server Performance Optimization (2026, UE 5.6)
Update 1.2 moved Satisfactory to Unreal Engine 5.6.1, bringing meaningful server-side optimizations but also new tuning opportunities and potential pitfalls. This guide covers everything a dedicated server admin needs to know to keep tick rate high and latency low as factories grow from early game into mega-factory territory.
This guide applies to Satisfactory Update 1.2 (UE 5.6.1) and later. Some settings differ from older guides written for Update 1.0 or 1.1.
Understanding What Makes Satisfactory Servers Lag
Satisfactory's performance bottlenecks are different from most survival games. Unlike games where the player count drives load (e.g., Rust, ARK), Satisfactory's primary CPU consumer is the factory simulation — specifically:
- Conveyor belt item passing — Every item on every belt is a simulated entity
- Fluid pipeline simulation — Pressure calculations across pipe networks run every tick
- Vehicle autopilot physics — Each automated truck/train is a full physics actor
- Power grid simulation — Large power networks compute load balancing every tick
- World streaming — Loading/unloading landscape chunks as players move around the map
Player count has a secondary impact: each connected client causes the server to replicate game state, which increases bandwidth and slightly increases CPU for serialization.
Server Hardware Baseline (2026 Recommendations)
| Factory Stage | Min RAM | Rec RAM | CPU | Storage |
|---|---|---|---|---|
| Early game (Tier 1–4) | 4 GB | 8 GB | 4 cores @ 3.0+ GHz | 10 GB SSD |
| Mid game (Tier 5–7) | 8 GB | 16 GB | 6 cores @ 3.5+ GHz | 20 GB SSD |
| Late game / Phase 4 | 16 GB | 32 GB | 8 cores @ 3.8+ GHz | 30 GB NVMe |
| Mega-factory (100+ km belt) | 32 GB | 64 GB | 12+ cores @ 4.0+ GHz | 50 GB NVMe |
UE 5.6.1 bonus: Coffee Stain reports up to 50% memory reduction in Update 1.2 for large factories compared to 1.0/1.1. If you were previously hitting RAM limits, you may find 1.2 runs comfortably in the same tier with headroom to spare.
Launch Arguments for Performance
The Satisfactory dedicated server is launched via a shell script (Linux) or batch file (Windows). You can pass Unreal Engine arguments to tune behavior at startup.
Recommended Launch Arguments
| Argument | Effect |
|---|---|
-nullrhi |
Disables rendering entirely (headless mode). Saves significant CPU and all GPU resources. |
-nosound |
Disables audio subsystem. Saves CPU overhead on a headless server. |
-useperfthreads |
Enables performance-optimized thread pool. Recommended on servers with 6+ cores. |
-nopause |
Prevents the server from pausing when no players are connected. Required for automated operations. |
-unattended |
Suppresses dialog boxes and interactive prompts. Required for unattended operation. |
Engine.ini Tweaks for Dedicated Servers
The file FactoryGame/Saved/Config/LinuxServer/Engine.ini (or WindowsServer on Windows) accepts engine-level configuration. The following tweaks are tested with UE 5.6.1:
Explanation of Key Settings
- gc.TimeBetweenPurgingPendingKillObjects=60 — Runs garbage collection every 60 seconds instead of the default (which can cause stutters). On a factory-heavy server, GC pauses are noticeable — this reduces frequency but each GC cycle takes slightly longer (acceptable tradeoff).
- s.AsyncLoadingThreadEnabled=1 — Enables background thread for asset streaming. Reduces main thread hitches when players travel to unloaded areas.
- MaxClientRate=100000 — Allows each client up to ~100 KB/s of network throughput from the server. Default is lower; this helps prevent desync on congested networks.
Diagnosing Lag: Finding the Bottleneck
Using the In-Game Profiler
Satisfactory exposes server performance metrics via the admin interface at https://[server-ip]:7777. Log in with your admin token and navigate to Server Stats. Key metrics to watch:
| Metric | Healthy Range | Action if Unhealthy |
|---|---|---|
| Tick Rate (TPS) | 30 TPS | If <20 TPS, locate and reduce largest factory sections |
| Average Frame Time | <33 ms | If >50 ms, factory simulation is the culprit |
| Network Round-Trip | <50 ms | If >100 ms, check MaxClientRate and server bandwidth |
Conveyor Belt Optimization
Conveyors are almost always the top CPU consumer on mature servers. Strategies to reduce belt load:
- Use Mk.5 belts where possible — Higher throughput means fewer belts to achieve the same item-per-minute rate
- Avoid long cross-map belt runs — Use trains or Tanker Trucks (new in 1.2) instead
- Merge belt networks — A single Mk.5 belt is cheaper to simulate than three parallel Mk.3 belts
- Avoid belt spaghetti — Each merge/splitter junction is an additional simulation node
Fluid Pipeline Optimization
With 1.2 introducing Tanker Trucks, consider offloading fluid transport between distant production areas to vehicles rather than kilometers of pipe. The vehicle simulation cost is lower than simulating a long pressurized pipe network.
Automatic Server Restarts for Memory Management
Even with 1.2's memory improvements, servers running for multiple days may accumulate memory fragmentation. A scheduled nightly restart keeps things fresh:
Combine this with a pre-restart save command via RCON or the server API to ensure no progress is lost. The server's autosave interval is configurable in the web UI (default: every 5 minutes).
Save File Size Management
Satisfactory save files grow significantly as factories expand. On long-running servers:
- Regularly delete old auto-save slots (keep 3–5 most recent)
- Save files can grow beyond 100 MB for mega-factories — ensure your storage doesn't fill up
- Save file loading time increases with size — a 200 MB save may take 3–4 minutes to fully load on server startup
Set up an automated backup script that copies the 5 most recent saves to a separate location before each restart. This protects against corrupted saves from unclean shutdowns.
Want optimized Satisfactory hosting without the configuration overhead? Supercraft Satisfactory servers include pre-tuned engine configurations and automatic daily save backups.