Satisfactory Your Satisfactory server is lagging and you want to fix it. Before you throw more RAM at the problem or blame your hosting provider, let’s figure out what’s actually going on. Satisfactory server performance is driven by a few specific bottlenecks, and most of them aren’t solved by upgrading your plan.
The Three Bottlenecks
CPU (The Usual Suspect)
Satisfactory’s game simulation runs on a single thread. One CPU core handles all machine processing, belt calculations, fluid dynamics, vehicle pathfinding, and player interactions. More cores don’t help. Clock speed is what matters.
This is a fundamental engine constraint, not a bug. Coffee Stain’s developers have confirmed it: “The game loop is still fundamentally single threaded… one core will always work harder than others.” The server spawns multiple threads for networking and I/O, but the core factory simulation that determines whether your game feels smooth is bound to one core.
What this means in practice: no amount of server resources can make a sufficiently complex factory run at full speed. There’s a ceiling, and it’s determined by single-core CPU performance.
Memory
RAM doesn’t cause lag directly - but running out of it does. When the server exhausts its allocation, it starts swapping to disk (or crashes), and everything grinds to a halt.
The more common memory issue is gradual accumulation. Satisfactory servers grow in memory usage over time, even with the same factory. Patch 1.1.2.0 (November 2025) fixed the worst memory leak (a blueprint-related bug), but the server still accumulates data during long uptimes. Scheduled restarts are the standard mitigation.
Autosave spikes are the other RAM concern. During autosave, the server temporarily needs 2-4GB above its normal baseline. If you’re running near your ceiling, an autosave can push you over and crash the server.
Network
Network issues show up as desync, rubber-banding, and delayed interactions. These are often confused with server lag but are actually a client-server sync problem.
The biggest factor is the Network Quality setting. With it set to Low (the server default), the server syncs less frequently with clients, which reduces CPU load but increases perceived lag. Setting it to Ultra on both server and all clients dramatically improves the experience.
Understanding TPS
TPS (ticks per second) is the server metric that matters. Satisfactory targets 30 TPS. Each tick, the server processes one frame of factory simulation.
- 30 TPS: Normal. Everything runs smoothly.
- 20-30 TPS: Slightly degraded. You might notice occasional stutters.
- Below 20 TPS: Noticeably laggy. Belt items move in bursts, interactions feel delayed.
- Below 10 TPS: Effectively unplayable.
How to check: Use the console command stat unit to see frame time breakdown. There’s no built-in TPS counter like Minecraft has, but frame times directly correlate - if the server frame time is consistently above 33ms (1000ms / 30), you’re dropping below 30 TPS.
You can also watch for symptoms: conveyor belt items stuttering instead of flowing smoothly, vehicles snapping between positions, and a general feeling of input delay.
Factory Optimizations That Actually Help
Before upgrading your server, try optimizing your factory. These changes reduce the simulation load on that single CPU core:
Use higher-tier belts instead of parallel low-tier belts. Four Mk.1 belts moving 240 items/min is more expensive to simulate than one Mk.4 belt moving 780 items/min. Consolidate where possible.
Replace truck routes with trains. Trucks recalculate pathfinding constantly, which is expensive. Trains follow fixed tracks with predetermined stops - much cheaper to simulate. If you have more than 2-3 truck routes, switching to rail will measurably improve TPS.
Reduce pipe junction complexity. Fluid simulation is heavier than belt simulation. Every pipe junction, valve, and pump is a calculation point. Simpler pipe layouts with fewer junctions perform better.
Minimize vehicle count. Every active vehicle (trucks, tractors, explorers) adds pathfinding overhead regardless of whether a player is near them. Vehicles you’re not actively using should be parked and powered down if possible.
Build vertically when practical. Compact vertical factories with short belt runs simulate more efficiently than sprawling horizontal layouts with long belt networks. Every belt segment is an object the server tracks.
Optimization vs Rebuilding
These tips are about reducing simulation load, not demanding you rebuild your factory from scratch. Apply them to new construction and optimize bottleneck areas first. A perfect factory layout isn’t worth anything if you burned out rebuilding it.
Memory Management
Scheduled Restarts
The single most impactful thing you can do for long-term server performance. Satisfactory has a built-in auto-restart feature: Server Manager > Server Settings > Server Restart Interval.
The server auto-saves before restarting and loads the latest save on startup. Restarts take seconds to minutes depending on save file size.
Recommended schedule:
- Normal factory: daily restart (default is midnight UTC)
- Heavy factory: every 12 hours
- Mega-factory with memory pressure: every 6-8 hours
Autosave Tuning
If your server stutters on a regular cycle (every 5 minutes exactly), it’s autosave. The default interval is 300 seconds. For large factories, the save operation blocks the game thread and causes a TPS drop.
Increase the interval to 600-1800 seconds (10-30 minutes) to reduce the frequency. The console command is FG.AutosaveInterval 600. The tradeoff is more potential progress loss if the server crashes between saves.
The game keeps 3 rotating autosaves by default, so you always have recent saves to fall back on.
When to Upgrade Your Server
Upgrade RAM if:
- The server crashes during autosave (RAM spike exceeding allocation)
- Memory usage is consistently above 80% of allocation
- You’re adding major factory expansions and need headroom
Consider better hosting if:
- TPS drops are frequent and factory optimization hasn’t helped
- You need higher single-core clock speed (this is the bottleneck that can’t be solved with more RAM)
- Your current host is overselling CPU and you’re not getting the clock speed you’re paying for
Accept the ceiling if:
- You have a 2,000+ machine mega-factory on a server with good specs and TPS is still dropping
- The single-threaded simulation has hit the CPU clock speed wall
- This is a game engine limitation, not something fixable with better hardware
Quick Diagnostic Checklist
When your server is lagging, run through this:
- Check autosave - is the lag on a regular 5-minute cycle? Increase the interval.
- Check uptime - has the server been running for days without a restart? Restart it.
- Check RAM usage - is the server near its allocation ceiling? You need more headroom.
- Check Network Quality - is it set to Ultra on the server and all clients?
- Check factory complexity - how many machines, vehicles, and belts are active? Can any be optimized?
- Check mods - did you recently add a mod? Some mods (especially automation and content mods) add significant CPU load. Try disabling recent additions.
If you’ve worked through all of these and TPS is still dropping, you’re likely hitting the single-core CPU ceiling. At that point, the options are: optimize the factory, split production across multiple servers, or accept the tradeoff of building at that scale.
WinterNode runs Satisfactory servers on high-clock-speed hardware with automatic backups every 12 hours and instant RAM upgrades. Get your Satisfactory server →
Frequently Asked Questions
Player count rarely causes lag. Factory complexity does. A 2-player server with a mega-factory will lag more than an 8-player server in early game. The game loop is single-threaded, so CPU clock speed matters more than core count.
Yes. The server accumulates memory over time despite fixes in Patch 1.1.2.0. Daily restarts keep performance consistent. Satisfactory has a built-in auto-restart feature in Server Settings.
Only if you're actually running out of RAM. Most lag is CPU-bound - the single-threaded game loop hits a clock speed ceiling before RAM becomes the bottleneck. More RAM helps with autosave spikes and prevents OOM crashes, but won't fix TPS drops.