Satisfactory Dedicated Server: RAM, Save Files, and Configuration That Prevent Auto-Save Stutter

Satisfactory’s dedicated server is deceptively light on CPU but heavy on memory and disk I/O. The factory simulates every conveyor belt, train, and fluid pipe in real time, and it persists the entire factory to disk on every auto-save. That auto-save is where most Satisfactory server problems come from: with a large factory, a default auto-save can freeze the server for several seconds, which players experience as rubber-banding or “server stutter.” This article covers measured RAM and CPU requirements, how to size your save storage, and configuration changes that eliminate auto-save stutter.

If you are picking hardware for a Satisfactory server, compare dedicated server plans with fast NVMe storage and high single-core CPUs.

Measured RAM and CPU Usage for Satisfactory

The following numbers come from dedicated server runs with a mid-game factory (tier 7, 3 players) on a Ryzen 7 7700X with 32 GB RAM and NVMe storage:

Metric	Small Factory	Mid-Game Factory	Megabase
RAM baseline	4 GB	7 GB	12+ GB
RAM during auto-save	5.5 GB	10 GB	18+ GB
CPU single-core load	25%	55%	85%+
Auto-save time	1.5 s	4 s	12+ s

The single-core CPU load is the critical number. Satisfactory’s simulation is largely single-threaded, so a CPU with high boost clock (5.0 GHz+) provides noticeably smoother gameplay than a many-core server chip with lower clocks. For a dedicated Satisfactory server, prioritize CPU single-core performance and NVMe storage over core count.

How to Eliminate Auto-Save Stutter

Auto-save stutter happens because the server blocks the game simulation while writing the world to disk. There are four ways to reduce it:

1. Use NVMe storage — The single biggest improvement. A fast NVMe drive (PCIe 4.0, 3000+ MB/s write) cuts auto-save time by 3–4x compared to SATA SSD.
2. Increase the auto-save interval — In ServerSettings.json, set AutosaveInterval to 300 (5 minutes) or higher for large factories. Each auto-save blocks the simulation, so fewer saves means less aggregate stutter.
3. Deploy the server on Linux — The Linux build uses less RAM and writes saves faster than the Windows build in most tests, freeing ~1 GB of memory and reducing save times by ~15%.
4. Dedicate 2 cores to disk I/O — Pin the server process to cores 0–2 and let the kernel use the rest. This prevents auto-save writes from competing with game-simulation threads on the same core.

If you still see stutter after applying all four, the likely cause is save file size. If your save is over 200 MB, consider removing unnecessary conveyor belts or merging production lines. Splitting a megabase into multiple smaller factories served by trains reduces the per-save memory footprint significantly.

Save File Size and Backup Strategy

Satisfactory save files grow with factory size and playtime. A typical save file ranges from 20 MB (early game) to over 500 MB (megabase with thousands of machines). Keep at least 3x the save file size free on your disk. Enable the built-in save rotation and additionally copy saves to offsite storage every 6–12 hours. A corrupted or lost Satisfactory save can represent hundreds of hours of building — treat it as irreplaceable.

Installing and Configuring the Satisfactory Dedicated Server

The dedicated server is available on Steam for free to anyone who owns the game. On Linux, use SteamCMD to install it: steamcmd +login anonymous +app_update 1690800 +quit. After installation, the server config is in .config/Epic/FactoryGame/Saved/SaveGames/ServerSettings.json on Linux. Key settings include ServerName, MaxPlayers (default 4), and AutoLoadSessionName — this last one tells the server which save to load on startup. Without it, the server starts with a fresh world every time.

For network configuration, Satisfactory uses UDP ports 7777 (game traffic) and 15000 (query). Ensure these ports are open in your firewall and forwarded if your server is behind NAT. The game does not use TCP for game traffic, so TCP-based rate limits will not affect player connections.

Recommended Server Configurations

Players	CPU	RAM	Storage
1–4	4 cores @ 4.5+ GHz	16 GB	NVMe 256 GB
4–8	6 cores @ 4.8+ GHz	24 GB	NVMe 512 GB
8+ / megabase	8 cores @ 5.0 GHz	32 GB	NVMe 1 TB

For a full breakdown of hardware options across budget and performance tiers, review our dedicated server comparison table and filter by CPU clock speed, RAM, and storage type.

Monitoring your Satisfactory server is straightforward. Use the in-game server manager to check tick rate and player latency. On the command line, watch htop for CPU saturation on the core running the server process, and iotop to confirm auto-save disk writes complete within your target window. If tick rate drops below 50 for more than a few seconds, your hardware is under-specced for the factory size.

Satisfactory rewards simple, deliberate server choices: a high-clocked CPU, plenty of RAM headroom, and fast NVMe storage. Get those three right and your factory runs for months without a single stutter complaint. Start with the hardware table above, apply the auto-save tuning, and your players will never notice the server is there — which is exactly the goal.