Satisfactory Server Requirements Calculator
Satisfactory's dedicated server is unusual: its hardware needs are driven far more by how big your factory is than by how many players are online. A handful of friends building a sprawling Tier 8 mega-factory will stress a server harder than a larger group still in the early tiers. Because the simulation loop is dominated by a single thread, raw clock speed beats core count almost every time.
Use the calculator below to estimate RAM, CPU, storage, and bandwidth for your save, then read the breakdown for accurate, version-current numbers (Update 1.1 / patch 1.1.2.0). All figures are based on Coffee Stain's official wiki guidance plus community benchmarks.
Satisfactory dedicated server requirements
Satisfactory ships with a free, headless dedicated server for Windows and Linux. Coffee Stain publishes a baseline spec on the official wiki, but real-world needs depend heavily on your save's complexity, so plan around your end-game ambitions rather than your current tier.
RAM
The official minimum is 8GB, which covers an early-game world with the default 4-player cap. Coffee Stain recommends 16GB for larger saves or more than 4 players. Community benchmarks line up with this progression:
- Early game (Tiers 1-3): ~4-6GB in use; 8GB plan
- Mid game (Tiers 4-6): ~6-8GB; 12GB plan recommended
- Late game (Tier 7-8): ~8-12GB; 16GB plan
- Mega factories: 12-16GB+; 16-24GB plan
Crucially, RAM scales with factory complexity (machine count, item throughput, belts, vehicles) more than with player count. Leave 2-4GB of headroom above your average usage to absorb autosave spikes.
CPU
This is the part most planning guides get wrong. The official wiki states the server uses multiple cores but heavily favors high single-core performance — in practice the simulation loop is dominated by one thread, so per-core clock speed and instructions-per-clock (IPC) dictate tick rate (default 30 TPS) and lag, not core count. Coffee Stain recommends a CPU with a single-thread rating around 2000 or higher — roughly an Intel i5-3570 or AMD Ryzen 5 3600 and newer. Practically, target 2-4 fast cores at 3.4GHz+; a high-clock quad-core will beat a 16-core, low-clock server chip for this workload. Only 64-bit x86 is supported (no 32-bit, no ARM). On virtual machines, set the CPU type to host — the generic kvm64 type omits instructions the server requires and the server will crash when you create a world.
Storage
The server files are about 12.4GB on Windows and around 8GB on Linux (including a ~2GB base distro plus the game files). Save files grow with the factory: mid-game saves are ~20-50MB, late-game and mega-factory saves reach 200-500MB, and the largest multiplayer worlds can exceed 1GB. Because the server autosaves on a schedule and keeps three rotating backups by default, budget about 15GB total. An SSD is effectively required — autosaves write the whole world to disk, and on an HDD this causes long, visible lag spikes. NVMe shortens those spikes further and loads big saves in seconds.
Network and bandwidth
As of Update 1.1 the server needs two ports: a game port (default 7777, TCP and UDP, which also serves the HTTPS API) and a Reliable Messaging port (default 8888, TCP). The legacy query (15777) and beacon (15000) ports are gone. The game port can't be redirected, so external and internal port numbers must match. Bandwidth is modest — broadband with a stable upload is enough; budget roughly 3-5GB of egress per active player per month for typical play, more if players keep Network Quality on Ultra.
Vanilla vs modded
Mods (via the Satisfactory Mod Manager / SMM) increase both RAM and CPU load, and the server and every client must run an identical mod set. Plan on roughly 1.5x RAM for a moderate mod list and more for content-heavy packs.
Optimizing your Satisfactory server
Most Satisfactory server lag is a CPU or autosave problem, not a RAM problem. These changes have the biggest impact:
Prioritize single-thread speed
Because the simulation loop is dominated by one thread, low ticks-per-second (TPS) and rubber-banding almost always trace back to per-core CPU speed. Pick the highest-clock CPU available rather than the most cores, and on a VM use the host CPU type so the guest sees the real instruction set (the kvm64 type is missing instructions the server needs and will crash on world creation).
Tune the autosave interval
The default autosave runs every 300 seconds (5 minutes) and keeps three rotating backups. On large factories the save blocks the game thread and causes a periodic TPS drop. Raising the interval to 600-1800 seconds (10-30 minutes) reduces how often that stutter happens. Pair a longer interval with reliable backups so you don't risk much progress.
Schedule daily restarts
Even after patch 1.1.2.0 fixed the worst memory leak, the server's memory use still creeps up over multi-day uptimes. A scheduled daily restart (the server has a built-in restart-interval feature) keeps RAM use and tick rate consistent. This is the single easiest fix for \"the server got laggy after a few days.\"
Raise Network Quality to Ultra everywhere
The server defaults Network Quality to Low (0), which causes jittery machine/vehicle movement and unreliable ziplines, ladders, and crates for clients. Set it to Ultra in Server Settings — and note that each connecting player must also set Ultra on their own client for it to take effect. Ultra costs more CPU and bandwidth, so confirm your CPU headroom first.
Leave RAM headroom
Size your plan ~2-4GB above your observed average so autosave spikes and gradual growth don't push you into swap, which tanks performance. If you average 8GB in use, a 12GB plan is the safer choice.
Use an NVMe SSD and compress backups
NVMe shortens autosave stutter versus SATA SSD or HDD. For backups, a ~200MB save typically compresses to 30-50MB, so keeping weeks of history is cheap on storage.
What to look for in a host for Satisfactory
Satisfactory's quirks make some host features matter much more than headline specs. Use this checklist when comparing providers, regardless of brand.
- High single-thread CPU performance. This is the number one factor. Look for hosts that publish their CPU model and clock speed, and favor high-frequency consumer-class chips over many-core server CPUs. On virtualized hosts, confirm the VM uses the
hostCPU type, because thekvm64type lacks instructions the server needs and causes crashes. - Generous RAM with headroom. Don't buy exactly at the minimum. Choose a plan that sits 2-4GB above your expected peak so autosave spikes and gradual memory growth don't cause crashes.
- NVMe SSD storage. Frequent full-world autosaves make disk speed a real performance factor; NVMe meaningfully reduces save-time stutter.
- Automated, rotating backups. Saves are large and corruption is possible; look for scheduled backups you can restore with one click, plus enough storage (15GB+) to keep several.
- Full file access (FTP/SFTP) and a console. You'll want to upload existing saves, edit config files, and run console commands like the autosave interval.
- One-click or easy mod support. If you plan to mod, confirm the host makes installing a matching server-side mod set straightforward, since server and clients must match exactly.
- Low latency to your players. Pick a data-center region close to most of your group; geographic distance affects responsiveness more than raw bandwidth here.
- DDoS protection. Public game servers are common targets; built-in mitigation keeps your server reachable.
- Scheduled restarts. The ability to set an automatic daily restart helps manage the server's gradual memory growth.
Match the plan to your factory's end-state, not its current size — upgrading mid-playthrough is common, so flexible, easy upgrades are worth more than a slightly cheaper fixed tier.
CPU note: Heavily single-thread-bound: the server can use multiple cores, but the simulation game loop is dominated by one thread, so clock speed and IPC matter far more than core count. Coffee Stain recommends a single-thread rating of 2000+ (roughly an Intel i5-3570 / AMD Ryzen 5 3600 or better). A high-clock 4-core (3.4 GHz+) beats a many-core, low-clock server CPU. Only 64-bit x86 is supported (no 32-bit, no ARM). On VMs, use the 'host' CPU type, not kvm64.
RAM scales with factory complexity (machines, items, belts) more than with player count, so size for your end-game save rather than current player numbers. Numbers reflect the free official dedicated server on Update 1.1 / patch 1.1.2.0. The worst memory leak was fixed in 1.1.2.0, but memory still grows gradually over long uptimes, so schedule daily restarts. An SSD is effectively required for autosaves. Modded servers add roughly 1.5x RAM and require server and clients to run identical mod sets.