There is no single “RAM per player” formula for Satisfactory. A small group can build a demanding factory, while a larger group may be working in one quiet area. Production lines, logistics, vehicles, exploration, and active simulation all affect the server’s workload.
Choose resources for the factory you have today, then review usage during normal play. Consider what the world is simulating as well as how many people connect.
A practical MaximusHost starting point
MaximusHost recommends starting with 8–16 GB RAM and 4–6 vCPU. The create form offers 6–24 GB RAM and 2–8 vCPU, giving you room to adjust as your factory grows.
- A newer private factory can often start near the lower end of the recommendation and be observed as it develops.
- A growing save with long production lines, many machines, vehicles, trains, or distributed player activity may need more headroom.
- A mature factory can put pressure on memory and processor time for different reasons. Raising only one resource is not automatically the right fix.
Choose a starting allocation that fits your plans and budget. The live create form shows the resources and estimate available to you.
What uses RAM in a Satisfactory factory?
RAM holds the server process and the data it needs while a session is active. World state, loaded areas, players, objects, and modded content can all contribute. A save that has accumulated many structures and systems may behave differently from a new world even with the same number of players.
Common reasons memory use can rise include:
- Factory scale. More buildings, belts, pipes, storage, and production chains mean more world state to track.
- Distributed activity. Players exploring or working far apart can keep more areas relevant at the same time.
- Long-lived saves. Expanding a factory over many sessions can increase the amount of state the server manages.
- Mods. A compatible mod stack can add content, dependencies, and its own memory use. A version mismatch is not solved by assigning more RAM.
- Busy moments. Joining, loading a session, saving, and a group working at once can look different from an idle period.
High memory use is useful information, but it is not a diagnosis by itself. Look for repeatable behavior during representative sessions rather than changing resources because of a single startup or save spike.
Why CPU matters just as much
Satisfactory servers also need CPU time for simulation and multiplayer work. A large automation network, active logistics, vehicles, trains, player movement, and world activity can create CPU pressure even when there is unused RAM. Conversely, a server close to its memory allocation can have trouble even when CPU appears modest.
Use Resources in your server manager to review RAM and CPU while the factory is active. Compare readings before, during, and after the slowdown. The Satisfactory overview guide explains the status and resource information shown there.
Watch workload, not just player count
Player count is only one signal. Four people building in one starter area can be easier to host than two people separately exploring, expanding a rail network, and loading a heavily automated endgame factory. A large save can also be demanding when a small group is online.
When planning a resource change, consider:
- Whether players are spread across the map or concentrated in one area.
- Whether the factory has recently added complex production, transport, or vehicles.
- Whether the problem appears during saves, loading, exploration, or ordinary play.
- Whether a game update, branch switch, or mod change happened before the problem.
- Whether server and client branches are compatible.
This avoids an expensive but unhelpful habit: increasing RAM after every issue when the actual cause is incompatible content, a version mismatch, or a workload that needs CPU headroom.
When to adjust an allocation
Consider more RAM or vCPU when normal sessions repeatedly show pressure, slow simulation, failures that point to resource exhaustion, or a stable pattern of trouble during predictable busy periods. Make one measured change at a time, then observe again under similar conditions.
Consider reducing resources only after recent, representative usage stays comfortably below the current allocation. Leave headroom for saves, new construction, player activity, and occasional spikes. A configuration that looks oversized during a quiet hour may be appropriate during a group build session.
Before a major branch, settings, or mod change, create a manual save from the Satisfactory management area. Keep track of the save and the versions you changed so you can return to a known point if needed.
Budgeting with credits and a dedicated IP
MaximusHost uses credit-based billing rather than a fixed monthly Satisfactory package. The running estimate includes your selected CPU and RAM, and Satisfactory requires a dedicated IP. Check the live estimate and Billing and Credits for how your account is charged while the server or IP is assigned.
The create form also shows any one-time creation charge before you submit. Use the calculator on Satisfactory hosting to compare resource choices before creating your server.
Common troubleshooting mistakes
Avoid making several changes at once. Raising RAM, switching branch, installing a mod, and changing server options together makes it hard to learn what helped or what caused a new problem. Do not use an allocation increase to mask an incompatible game branch or mod version.
Use the console and logs area to gather evidence, verify that players are on a compatible branch, and test one change at a time. That approach is slower for one session but much safer for a factory your group has invested in.
Next step
If you are ready to host, start near the recommended resources and adjust after you have usage data from your factory. Review Satisfactory dedicated server hosting for the estimate and dedicated-IP requirement.
