Satisfactory Dedicated Server Hardware: CPU UPS, RAM and Mega-Factory Sizing

Satisfactory is unusual among survival builders because the server’s load scales with your factory’s complexity, not just player count. A dedicated server hosting a small starter base and one hosting a sprawling mega-factory with thousands of machines, belts, and trains have wildly different hardware appetites. Here is how to size CPU, RAM, and storage for a Satisfactory dedicated server that still runs at a stable update rate as the factory grows.

Why Satisfactory Is CPU-Bound, Not Player-Bound

Satisfactory simulates every machine, conveyor, pipe, train, and vehicle on the server at a fixed tick. Player count adds modest overhead; factory complexity adds the bulk. Two players in a 5,000-machine factory generate far more server load than ten players in a fresh world. This means sizing by player count alone is a mistake, and upgrade planning must anticipate factory growth.

The key metric is update time per tick. As factory size grows, update time rises roughly linearly with the number of active production entities. When update time exceeds the tick budget, the whole server slows down and clients rubber-band.

CPU: Single-Thread Speed Dominates

Satisfactory’s factory simulation is largely single-threaded. This is the opposite of what most hosting buyers expect, and it means core count is far less important than single-thread performance and sustained all-core clock stability.

• Minimum: a modern CPU with strong single-thread score (recent Ryzen 5/7 or equivalent Xeon/EPYC with high clocks).
• Recommended: 3.8+ GHz all-core sustained, which keeps large factories ticking smoothly.
• Not useful: 32+ cores at low clocks; the simulation will not use them and you pay for idle silicon.

Avoid any host that thermally throttles under sustained load. A factory ticks continuously, so sustained clock is what matters, not a 10-second boost number.

RAM: Scales With Factory Size

Satisfactory memory use climbs with entity count. Rough planning figures from community-hosted worlds:

• Small factory (< 500 machines, 2-4 players): 8-12 GB.
• Medium factory (500-2,000 machines): 16-24 GB.
• Large factory (2,000-6,000 machines): 32 GB.
• Mega-factory (6,000+ machines, trains, drones): 32-64 GB, and rising.

Always leave 25% RAM headroom above your observed peak. A swap event during an autosave will stall every connected player.

Storage: NVMe for Saves and Logs

Satisfactory saves are large and written frequently. A mega-factory save can exceed 50 MB, and autosave writes it to disk every few minutes. Put saves on NVMe with high write endurance. SATA SSDs work for small worlds but generate noticeable save-related stalls in large ones. Keep at least three save rotations plus an off-server backup.

Network and Platform Notes

Satisfactory’s networking is comparatively light: bandwidth scales with players and visible factory activity rather than machine count. A 1 Gbit uplink comfortably serves 8-16 players. The real constraint is server-side simulation speed, so invest budget in CPU and RAM before bandwidth.

Run the server on bare metal or a dedicated instance rather than a shared VPS. Satisfactory’s steady CPU demand makes it a poor fit for noisy-neighbor virtualization, where a busy host can silently steal the clock headroom your factory needs. See our dedicated server options for single-tenant hosting with high sustained clocks.

Tuning the Server for Large Factories

Hardware gets you most of the way, but a few server-side settings extend the ceiling further. Increase the save interval on very large worlds so autosave does not collide with peak production; a save that briefly stalls the simulation is harmless at 15-minute intervals and disruptive at 2-minute intervals. Run the server process pinned to the fastest physical cores so the operating system cannot migrate the simulation onto a slower sibling core mid-tick. Disable any CPU power-saving states in firmware so the clock never dips between ticks.

If you host multiple games or worlds on one machine, isolate Satisfactory on its own cores. Its steady, near-constant CPU demand is a poor neighbor for anything latency-sensitive, and co-resident workloads will rob it of the sustained clock it depends on.

When to Upgrade Versus Rebuild

Satisfactory worlds rarely shrink. When your observed update time sits consistently above 60% of the tick budget at normal player counts, plan an upgrade rather than waiting for players to notice rubber-banding. If only RAM is exhausted, a memory upgrade is cheap and immediate. If update time itself is the constraint, you need a faster single-thread CPU, which usually means a new machine. Tracking that 60% threshold gives you weeks of warning before the factory outgrows its host.

Sizing Checklist Before You Buy

• Estimate eventual machine count, not current: factories triple in size over a wipe.
• Prioritize single-thread performance and sustained clock over core count.
• Budget 32 GB RAM for any world you expect to grow past a few hundred machines.
• Use NVMe storage sized for several full save rotations.
• Ensure the host guarantees no CPU overcommit or steal time.

Satisfactory rewards a server chosen for the factory it will become, not the one it starts as. Reserve bare-metal game hosting with high sustained clocks. Get the single-thread clock and RAM ceiling right and a dedicated machine will carry a mega-factory for years.