Your factory started as a few smelters and is now a map full of belts, trains and drones, and the dedicated server is starting to struggle. Before you pay for a bigger plan, answer the question every server owner hits at this point: do I need more RAM or more CPU? The two run out in different ways, and a bigger plan usually fixes only one of them.
Quick answer: Check memory first. If the server's memory use sits close to its limit, or the server stops without a crash dump, you need more RAM: the official Satisfactory wiki puts the minimum at 8 GB and says 16 GB may be recommended for larger saves or more than four players. If memory has room to spare and the whole factory still lags for everyone, the CPU is the limit. The wiki says the server "heavily favors high single-core performance", because its game loop runs on one main thread, and extra RAM does not make that thread any faster. A short stall every five minutes is the autosave, which you can space out.
Why a Big Factory Pushes Both RAM and CPU
Every building, belt, train and drone in your save is something the server keeps in memory and something it has to update while the game runs. As the factory grows, both loads grow, but they reach their limits at different moments.
RAM. The wiki calls its requirements "community recommendations for minimum requirements" and adds that the server "may or may not run with less powerful hardware, depending on player count and save file size." So the size of the save and the number of players decide how much memory you need. The wiki gives no formula from save size to gigabytes, and the save files page says the body of a save is stored as zlib-compressed chunks, so the size of the .sav file on disk does not tell you the memory use. The memory reading of the running server does.
CPU. The wiki says the server "uses multiple cores, but heavily favors high single-core performance", that anything with a single-thread rating of 2000 or higher should work, and: "It is highly recommended that servers exceed the minimum requirements, especially for CPU." It backs this up with a quote from Bogdan, a developer, from November 2021: "The game loop is still fundamentally single threaded though and all multi threaded work is happening on ticks. So one core will always work harder than others as a result."
That quote answers most of the RAM or CPU question. When the main thread cannot finish its work in time, the server falls behind, however much free memory or how many idle cores it has.
Signs the Server Is Short on RAM
- The memory figure climbs toward the limit while you play and stays there.
- The server stops with no error message and no fresh crash dump. On Linux, a process that runs out of memory is ended by the kernel's OOM killer with SIGKILL, which shows up as exit code 137. Our exit code 137 guide shows how to confirm it.
- The trouble started after you loaded a bigger save, raised the player cap or invited more people, the two things the wiki names: save size and player count.
A real crash looks different. The server writes its logs to FactoryGame/Saved/Logs in the install folder, with the current log named FactoryGame.log, and puts crash dumps in FactoryGame/Saved/Crashes. A fresh crash dump points at a bug in the game or a mod, not at missing RAM.
Signs the CPU Is the Limit
- Memory has plenty of headroom, but the lag is there the whole time people play, not only in short bursts.
- Everyone on the server feels it at the same time. If only one player lags while the others are fine, look at that player's connection and PC first.
- It got worse as you added production lines, trains and drones, not as the session got longer.
- On a VPS, one core sits near full load while the others have room. That is the main thread from the developer quote, and it is why the wiki's FAQ includes the question "why am I only seeing one core being used?"
The server works in ticks, at most 30 per second by default. The wiki's configuration files page says "the server will only reach the specified tickrate if hardware allows." A server whose main thread is overloaded manages fewer ticks, so the factory, vehicles and other players update less often for everyone connected.
How to Check Which One You Have
On a hosted game server
Open your panel while the lag is happening and watch memory and CPU side by side for an evening of normal play. Panels scale the CPU figure in different ways, so the pattern matters more than the number. CPU that rises when the lag starts and stays high while memory stays flat points at the CPU. Memory that reaches the limit just before the server stops points at RAM.
On your own VPS or PC
free -h
top
free -h shows memory in readable units. Its available column is the estimate of how much memory is available for starting new applications without swapping. In top, press 1 to show each CPU on its own line and H to list individual threads. Without threads mode, top can show a multi-threaded process above 100%, so a figure like 130% for the server tells you little. One server thread close to a full core while memory has room is the CPU limit.
The quick lookup
| What you see | Most likely cause | What helps |
|---|---|---|
| Memory near the limit, server stops with no crash dump | Not enough RAM | More RAM, or fewer players |
| Memory fine, steady lag for everyone, one core full | Main thread at its limit | Faster cores, lighter settings |
| A short stall every five minutes | Autosave | A longer autosave interval |
| Memory creeps up over a long session | A memory leak | The current version, a daily restart |
| Players time out while joining a big save | Joining, not RAM or CPU | Timeouts and the join fixes below |
Autosaves and Save Size
The server saves every 300 seconds (5 minutes) by default, and the configuration files page warns that saving more often also means "a drop in server performance while the server is saving." In the 1.0 patch notes Coffee Stain wrote that saving and autosaving "should now take considerably less time than ever before", which should make autosaves "a lot less disruptive", especially in big factories. If you notice a stall on a fixed rhythm, compare it with your autosave interval before you blame the hardware.
To change the interval, open the Server Manager and set Autosave Interval in minutes, or type FG.AutosaveInterval 600 in the Console tab, where the number is in seconds. A longer interval means fewer stalls but more lost progress if the server crashes. Auto-Save on Player Disconnect adds a save every time someone leaves, so on a server where players come and go a lot, that setting adds saves too.
Settings That Help a CPU-Bound Server
- Leave the tick rate at 30. The configuration files page is direct about it: "if the hardware can't hit the default 30, increasing it won't help."
- Test a lower Network Quality. The wiki's description of this server setting: "Increasing network quality may improve client load times and network performance at the cost of server framerate." On a server where the CPU is already the limit, the highest setting costs ticks. The wiki's advice is to "Experiment with these settings to see what works for you."
- Keep the player cap reasonable. The server is "tuned to be most performant with the default player cap of four", and the configuration page warns that a higher
MaxPlayersin Game.ini can affect "server stability, performance, and resource usage." - Restart once a day. Server Restart Interval sounds like an interval, but the wiki says it is the "Hour at which the server automatically restarts daily." Pick an hour when nobody plays. Memory leaks have been real: v1.1.0.3 fixed "a memory leak that would lead to an Object Limit related crash when playing for prolonged amounts of time", the v1.1.2.0 notes list a fix, shipped in the patch before it, for one that "would lead to severe performance degradation/out of memory crashes on both PC and Console when staying in the same session over time", and v1.2.3.0 "Fixed memory leak due to multiple issues related to Drones."
- Stay on the current version. The update of 4 November 2026, the one that added crossplay, lists "Potential fixes to some of the issues that would result in being unable to join big saves in multiplayer" and a dedicated server crash fix for drones.
What a Bigger Plan Fixes and What It Does Not
More RAM fixes a server that runs into its memory limit: the OOM kills stop, and you get room for a larger save or more than four players, which is exactly where the wiki suggests 16 GB.
More RAM does not fix:
- A main thread at its limit. The game loop still runs on one core, so the extra memory sits unused while the lag stays.
- Autosave stalls. They come from the save itself. Space them out instead.
- Join timeouts. Players with older PCs or slow connections can need more than the default 30 seconds; the configuration page shows how to raise
InitialConnectTimeoutandConnectionTimeoutunder[/Script/OnlineSubsystemUtils.IpNetDriver]in Engine.ini. Players dropped with an overflow error while joining need our outgoing reliable buffer overflow fix instead. - A memory leak. More RAM only delays the moment it fills up. Updating and a daily restart deal with it.
When the CPU is the limit, what helps is a faster core, not more cores: by the developer's own description, one core will always work harder than the others. Settings that cost server framerate, such as a high Network Quality or a raised player cap, are the other lever you control.
How Our Plans Handle This
Our Satisfactory hosting plans differ in RAM and disk, not in CPU. As of 7 November 2026, Small has 8 GB for €8.00 a month, Medium 12 GB for €11.80, Large 16 GB for €15.60 and Extreme 24 GB for €23.20, with €0.10 more per GB in the USA. The CPU depends on the region: Ryzen 9 3900X-class in the Netherlands, Germany, Poland, Canada and India, Ryzen 9 7950X3D-class in the USA and Ryzen 9 5950X-class in Singapore and Australia, in each case shared with the other servers on the node. So moving from Small to Large gives your server more memory, but not more CPU time. If your memory reading has room and the lag stays, contact us before you upgrade and we will help you size it.
FAQ
Does more RAM make a Satisfactory server run faster?
Only when it was running out of memory. Once the server has enough RAM, extra memory sits unused. Lag with memory to spare comes from the main thread, and the wiki says the server "heavily favors high single-core performance".
How much RAM does a big Satisfactory factory need?
The wiki puts the minimum at 8 GB and says "16GB RAM may be recommended for larger saves or to host more than 4 players." It gives no formula from save size to gigabytes, so watch the memory reading over a few evenings of normal play and add RAM before the next big expansion. Our requirements guide has a RAM table by factory stage.
Why does my Satisfactory server lag every five minutes?
That is the default autosave interval of 300 seconds. The wiki notes a drop in server performance while the server is saving. Set a longer Autosave Interval in the Server Manager, or use FG.AutosaveInterval in the Console tab with a value in seconds.
Why is my dedicated server only using one core?
The wiki's FAQ answers it with a developer quote: "The game loop is still fundamentally single threaded though and all multi threaded work is happening on ticks." The server uses several cores for some work, but one core always does the most.
Should I raise the tick rate to fix lag?
No. The default is 30, and "the server will only reach the specified tickrate if hardware allows." If the hardware cannot reach 30, a higher limit changes nothing. Look at the settings above instead, and our setup guide for where the config files live.
Sources
All opened on 7 November 2026:
- Satisfactory wiki: Dedicated servers, Configuration files, Save files
- Coffee Stain on Steam: Satisfactory 1.0 out now, v1.1.0.3, v1.1.2.0, v1.2.3.0, Crossplay update of 4 November 2026
- Linux: free(1), top(1), oom_kill.c