Satisfactory Mega-Factory Server Sizing: CPU Clock, RAM and Save IO

Satisfactory is unusual among survival builders because server load scales with factory complexity, not player count. A node hosting a starter base and one running a sprawling mega-factory with thousands of machines, belts, and trains have wildly different appetites. This article gives concrete CPU, RAM, and storage numbers so your Satisfactory server holds a stable update rate as the factory grows.

Why Satisfactory Is CPU-Bound, Not Player-Bound

The server simulates every machine, conveyor, pipe, train, and vehicle 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 load than ten players in a fresh world, so sizing by player count alone is a mistake. The key metric is update time per tick: as factory size grows, update time rises roughly linearly with active production entities. When update time exceeds the tick budget, clients rubber-band.

Concrete CPU, RAM and Storage Numbers

Factory size	CPU	RAM	Storage
Starter base (<500 machines)	2 cores @ 3.8 GHz+	8 GB	NVMe, 30 GB
Mid factory (1,000-2,500 machines)	4 cores @ 4.0 GHz+	12-16 GB	NVMe, 50 GB
Mega-factory (5,000+ machines)	6-8 cores @ 4.5 GHz+	24-32 GB	NVMe, 100 GB+

Update time scales with entity count, so a mega-factory roughly quadruples tick cost versus a starter base. RAM follows the entity graph and grows with every belt and pipe segment recorded in the save. Because the factory simulation is largely single-threaded, clock speed matters more than core count — see our game server plans for high-clock nodes.

CPU: Single-Thread Speed Dominates

• Minimum — a modern CPU with strong single-thread score and 3.8+ GHz sustained all-core.
• Recommended — 4.5 GHz sustained all-core for factories above 2,500 machines.
• 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 ten-second boost number.

Storage and Save Performance

Satisfactory saves are large — a mature mega-factory save can exceed 100 MB — and autosaves write the whole world. On SATA storage that write freezes the tick for a second or more, which players notice as a periodic hitch. NVMe cuts save write time dramatically. Reduce autosave frequency for large factories and stagger it away from peak build sessions, and keep rolling backups on separate storage.

Network Sizing

Bandwidth demand stays low even on large factories because the server sends entity state deltas, not full world data. A 1 Gbps uplink comfortably covers a full server. Do not overspend on uplink; spend on sustained single-thread clock and NVMe write latency instead.

Planning for Growth

Because load tracks factory size, plan for the factory you will have in three months, not the one you have today. Choose a node with headroom to add 2,500 machines without a CPU change, and monitor update time weekly. When update time approaches the tick budget, that is your signal to move to a higher sustained-clock CPU. Review our high-clock dedicated servers before you commit.

Measuring Update Time in Practice

Update time is the number that matters, and you can read it from the server’s own tick diagnostics. Record it at a fixed player count at three milestones: when the factory is fresh, at roughly 1,000 machines, and again past 3,000. Plotting those three points gives you a slope — machines per millisecond of update time — that predicts when you will hit the tick budget. A slope that rises steeply means each new production block costs more than the last, which happens once belts and trains start crossing region boundaries.

Set an alert at 80% of the tick budget so you have time to plan a migration rather than reacting to rubber-banding. Weekly sampling is enough for most communities; a factory that grows hard during a build weekend will move several percentage points in two days, so check more often during surge periods.

The UPS Question

Uninterruptible power matters more on Satisfactory than on most game hosts because a mid-save power loss on a large world can corrupt the save file outright. The save write is not atomic across the whole file on every version, so a cut during the write is a real risk. A modest UPS sized to hold the node for five to ten minutes — enough for a clean shutdown — is cheaper than rebuilding a 100-hour mega-factory. Configure the UPS to trigger a graceful shutdown at low battery rather than running to zero, and confirm the shutdown script stops the game service cleanly before the host powers off.

Multi-Instance and Headroom Strategy

If you host several Satisfactory worlds, the single-thread bottleneck means you are far better off with several high-clock cores than fewer high-core-count chips. Four instances on four 4.5 GHz cores each will each tick better than four instances crammed onto a 32-core low-clock server. Give each world its own NVMe save path if possible, and stagger autosaves so two large saves never collide on the same queue. When factory growth pushes a single world past its core’s update budget, migrate that one instance rather than the whole node.

A Worked Example

A community running a 6,000-machine world with 20 concurrent builders on a 4-core 4.2 GHz node measured an update time of 38 ms against a 33 ms tick budget — the server ran at 0.86 of real time, and clients rubber-banded. Moving to a 6-core node with 4.6 GHz sustained clock brought update time to 26 ms, restoring full tick rate. The extra cores went unused by the simulation; it was the sustained clock, not the core count, that fixed it. This is the pattern to expect on every Satisfactory sizing decision.