For a small private Satisfactory group, the best server configuration is usually the unmodified baseline: four players, a 30-tick server rate, five-minute autosaves, pause-when-empty enabled, and save-on-disconnect enabled. Forward TCP and UDP port 7777 plus TCP port 8888 to the server, allow the same traffic through the host firewall, and run the process as a service if the world must remain available without someone watching the terminal.
Those defaults are not arbitrary. The server is tuned for a four-player cap, and raising the tick rate does not cure hardware that cannot sustain the default. Larger groups can work, but every increase in player count or save frequency consumes stability headroom. The practical goal is therefore to change only the setting that solves a known problem, then verify the result after a graceful restart.
What are the best Satisfactory dedicated-server settings for a small group?
Use the defaults first, then enable the two protections that matter most for an unattended private world: pause when empty and save when a player disconnects. This combination avoids simulating an empty factory while protecting recent progress when somebody leaves unexpectedly.
| Setting | Recommended starting value | Why |
|---|---|---|
| Maximum players | 4 | The server is tuned to be most performant at the default cap. |
| Server tick rate | 30 ticks per second | The documented default is suitable for most scenarios; raising it does not repair an underpowered host. |
| Autosave interval | 300 seconds (5 minutes) | Balances crash-loss exposure against save-time work. |
| Pause when empty | Enabled | Stops unattended simulation and reduces idle CPU use. |
| Save on player disconnect | Enabled | Captures progress when the last active player leaves. |
| Game port | 7777 (TCP and UDP) | Standard server and game traffic. |
| Reliable Messaging port | 8888 (TCP) | Required with the 1.1 networking changes. |
Apply routine changes in Server Manager rather than editing files by hand. Keep a short change log for anything you alter, because patches can replace or require re-editing configuration values.
How many players can a Satisfactory server handle?
The normal, performance-oriented cap is four players. Up to 127 players is described as theoretically possible, but that upper bound is not practical for ordinary operation and should not be treated as a supported target for a home server.
Four players: the stable baseline
A four-player world leaves the most headroom for factory simulation, network processing, saves, and operating-system tasks. It is the right choice for a private group that values predictable joining, fast recovery, and minimal tuning. Keep MaxPlayers at its default unless you have a measured reason to expand.
More than four players
Raising the cap is a tradeoff, not a free capacity upgrade. More connected players create more replicated game state and more simultaneous activity, so CPU, memory, storage latency, and upload capacity all matter. Increase the cap only after checking those resources during a busy session, and change one variable at a time so you can identify the cause of any new instability.
If you need a larger cap, the value is available as MaxPlayers in Game.ini. The practical limit for your world will be below the theoretical 127-player figure, and the documentation does not provide a universal hardware specification that guarantees a particular larger group size.
Should I increase the Satisfactory server tick rate?
No. Leave the tick rate at the default 30 ticks per second unless you have a specific, tested reason to change it. The game’s default tick rate is considered good for most scenarios, and increasing it cannot compensate for a host that already fails to sustain the default workload.
A higher rate asks the server to process simulation updates more often. That can reduce the time between updates only if the machine has spare CPU capacity and the clients, network, and world can keep up. If the server is already stuttering, first check CPU saturation, memory pressure, disk activity during saves, and upload quality. Increasing the rate in that situation usually reduces stability headroom instead of fixing lag.
Network tick-rate settings are among the advanced values available in configuration files. Treat them as an experiment: record the original value, stop the server cleanly, make one change, restart, and test with the same group and workload. Revert immediately if server frame time, join reliability, or save performance worsens.
Which ports do I forward for Satisfactory?
Forward TCP and UDP port 7777 and TCP port 8888 from the router to the server host. Allow the same traffic through the host firewall. Port 7777 is the standard game and server port; port 8888 is the Reliable Messaging port required after the 1.1 networking changes.
| Purpose | Protocol | Default port | Router and firewall action |
|---|---|---|---|
| Standard server/game traffic | TCP and UDP | 7777 | Forward to the server’s private IP and allow inbound traffic. |
| Reliable Messaging | TCP | 8888 | Forward to the same host and allow inbound traffic. |
Changing the ports
The standard port can be changed with the startup option -Port=. The Reliable Messaging port can be changed with -ReliablePort=. If an external port is remapped, use -ExternalReliablePort= so clients are told which public port to reach.
When you move a port, update every layer together: the server startup arguments, the router rule, the operating-system firewall rule, and the connection details shared with players. A rule pointed at the wrong private address will fail even when the port number is correct, so reserve a fixed DHCP lease or otherwise keep the host’s local address stable.
Home network versus VPN access
A home installation needs broadband, router forwarding or a VPN, and firewall rules that permit the required traffic. A VPN can avoid exposing a public forward in some network designs, but it adds another client and routing dependency for every player. Whichever method you choose, test from outside the host’s local network; a local connection can succeed even when the public route is broken.
How do I configure the server in Server Manager?
Use Server Manager for routine controls because it writes supported values in the format expected by the current server version. The labels can change after patches, but the controls cover the following workflow.
- Start the dedicated server once and open Server Manager for that installation.
- Set the server name and administrator password. Use a separate player password for a private group.
- Choose the session to auto-load so a restart returns to the intended world.
- Enable Pause when empty and Save on player disconnect for an unattended private server.
- Set the autosave interval, restart timing, gameplay-data sharing, and network quality options to match your group’s policy.
- Apply the changes, then stop and start the server through its normal controls rather than killing the process.
The manager also exposes restart timing and network-quality controls. Keep restart behavior conservative while you are diagnosing a problem: an automatic restart can restore availability, but frequent restarts can interrupt players and conceal an underlying resource or networking fault.
How often should a Satisfactory server autosave?
The documented default is 300 seconds, or five minutes. Keep that interval for most groups. Reduce it only when the group cannot tolerate losing up to several minutes of progress after a crash, and understand that every save adds disk work and can briefly reduce performance while the world is written.
Choosing an interval
| Priority | Useful approach | Trade-off |
|---|---|---|
| Balanced play | 300 seconds (5 minutes) | Moderate potential loss with moderate save overhead. |
| Minimize crash-loss exposure | Shorter than 300 seconds | More frequent disk activity and a greater chance of save-time hitching. |
| Reduce save overhead | Longer than 300 seconds | More progress can be lost if the process or host fails before the next save. |
You can change the value with FG.AutosaveInterval in the server console or through the Server Manager workflow. Measure the effect during a busy factory session rather than an empty world, because save duration depends on the amount of world state that must be written.
Autosaves are not backups
Rotating autosaves are a convenience for recovering a recent state, not a complete backup strategy. Keep copies outside the rotating set, ideally on different storage or another machine, and retain enough history to recover from corruption or an unwanted edit. A backup made while the process is still writing can be inconsistent, so use the server’s graceful stop or an appropriate backup procedure before copying live files.
Should the server pause when nobody is online?
For a private group, yes: enable pause-when-empty unless you deliberately want factories to continue running while everyone is away. Pausing removes unattended simulation work and can lower idle CPU consumption; it also prevents production from advancing while no player is available to notice a problem.
Pair it with save-on-disconnect. The pause setting controls simulation, while the disconnect save controls persistence. They solve different risks and are more useful together than either one alone.
Where are the advanced configuration files?
Use the Server Manager for settings it exposes, and edit files only for values that the interface does not provide. Stop the server gracefully before editing: shutdown writes can overwrite changes made while the process is running.
| Operating system | Configuration directory |
|---|---|
| Linux | <installation_directory>/FactoryGame/Saved/Config/LinuxServer/ |
| Windows | <installation_directory>FactoryGameSavedConfigWindowsServer |
If the files are missing, launch the server once so it can create them. After an update, verify that the values still exist and are still recognized; patches may overwrite ini values or change the supported keys.
Values commonly handled in files
MaxPlayersinGame.inifor a player-cap change.mNumRotatingAutosavesto control how many rotating autosaves are retained.- Connection-timeout values for clients on slow or unreliable links.
- Port-range controls when multiple server instances share a host.
- Network tick-rate settings when a controlled test justifies changing them.
Make a dated note of each edit, the old value, and the reason. If a later patch changes behavior, that record lets you revert quickly instead of guessing which override caused the problem.
How do I set up a Satisfactory server safely?
A reliable setup is a short sequence: install the supported server software, create the world, configure access, open the network path, test externally, and then automate restarts and backups.
- Choose the host. Use a 64-bit Windows or Linux machine with enough CPU, memory, storage performance, and upload bandwidth for the planned group. The server can be installed through Steam, SteamCMD, or Epic.
- Install and launch once. Start the server so it creates its save and configuration directories. Confirm that the intended session can be loaded before changing advanced values.
- Configure routine settings. In Server Manager, set names and passwords, select auto-load, enable pause-when-empty and save-on-disconnect, and retain the five-minute autosave unless testing shows a different interval is necessary.
- Reserve the local address. Give the host a stable private IP so router and firewall rules do not silently point to another device after a lease change.
- Forward and allow traffic. Send TCP/UDP 7777 and TCP 8888 to the host, then create matching inbound firewall rules.
- Test from an external network. Have a player connect from outside the host’s LAN. If that fails, check the public address, router rule, firewall profile, and whether the ISP uses carrier-grade NAT.
- Automate operation. Run the server as a service when it must stay online. Configure restart behavior and make backups outside the rotating autosave files.
- Document changes. Record ports, startup arguments, file edits, backup locations, and the date of the last update.
Is self-hosting or managed hosting better?
Self-hosting is best when you want control over files, save locations, logs, ports, and update timing and are comfortable administering the operating system. Managed hosting is better when you want someone else to handle operating-system updates, port forwarding, firewall rules, and service restarts.
| Consideration | Self-hosted | Managed service |
|---|---|---|
| Control | Direct access to files, logs, ports, and update timing. | Provider-defined controls and maintenance windows. |
| Networking | You configure forwarding, firewall rules, or a VPN. | Usually simplified through a control panel. |
| Availability | Requires a service wrapper or scheduled restart plan. | Restart administration is generally included in the service. |
| Maintenance burden | You handle patches, backups, and troubleshooting. | Less operating-system work, but less low-level control. |
| Cost model | Uses existing hardware and connection capacity. | Recurring hosting charge; exact pricing depends on the provider and plan. |
Neither model removes the need for backups or sensible player limits. A managed panel can simplify networking, but it cannot make an oversized group practical on inadequate hardware.
What causes lag, failed joins, or lost progress?
Diagnose the symptom before changing performance settings. Most failures fall into a small number of branches.
Players cannot join from outside the LAN
- Confirm that TCP and UDP 7777 and TCP 8888 are forwarded to the current private IP.
- Check that the host firewall allows the same protocols and ports on the active network profile.
- Verify any changed
-Port=,-ReliablePort=, or-ExternalReliablePort=argument. - Test from a genuinely external connection and check for carrier-grade NAT or a blocked inbound service.
The server stutters during saves
- Watch disk activity and save duration during a busy session.
- Increase the autosave interval only if the group accepts greater potential progress loss.
- Move the save location to storage with better latency and keep unrelated workloads off the host.
- Do not raise the tick rate while the host is struggling; that adds work.
The world keeps running after everyone leaves
Check the pause-when-empty option in Server Manager and confirm that the setting survived the last update. If the process is running under a different installation or session than the one you edited, apply the option to the active instance.
Changes disappear after a restart
Stop the process gracefully before editing. A running server can write its in-memory values during shutdown and overwrite manual changes. Also check whether an update replaced the relevant ini file or changed the accepted key.
The server stops when a terminal closes
Manual launching does not automatically restart the process after a crash or terminal closure. Run it as a service or another supervised background process, then test a deliberate stop and restart so you know the recovery path works.
Which configuration fits each group?
Choose the smallest configuration that meets the group’s actual need. The following profiles make the trade-offs explicit without pretending that one hardware specification fits every world.
| Group profile | Player cap | Tick rate | Autosave | Operational approach |
|---|---|---|---|---|
| Two to four friends, occasional play | 4 | 30 | 300 seconds | Server Manager, pause when empty, save on disconnect; manual launch can be acceptable when someone is present. |
| Four-player persistent world | 4 | 30 | 300 seconds | Run as a service, forward required ports, keep external backups. |
| More than four players | Increase only after testing | 30 initially | 300 seconds initially | Measure CPU, memory, disk, and upload headroom; change one setting at a time. |
| Low tolerance for crash loss | Hardware-dependent | 30 | Shorter than 300 seconds after testing | Accept extra save work and maintain independent backups. |
What should I check after a Satisfactory update?
Version-sensitive behavior is normal for a dedicated server. After a major patch, verify port allocation, Server Manager labels, supported Linux distributions, ini keys, and startup arguments before inviting the group back.
- Read the current configuration guidance for changed networking or server-manager controls.
- Confirm that the service starts and auto-loads the intended session.
- Check that the firewall and router still expose the configured ports.
- Verify player cap, tick rate, autosave interval, pause behavior, and disconnect saving in the active instance.
- Make a fresh external backup before extensive play.
Graceful shutdown remains important after updates and during routine maintenance. It gives the server time to write its final state and reduces the chance that your intended configuration or latest save is replaced by stale data.
Which settings should you use?
For most private groups, use four players, 30 ticks per second, 300-second autosaves, pause-when-empty, and save-on-disconnect. Forward TCP/UDP 7777 and TCP 8888, run the process as a service if continuous availability matters, and keep backups outside the rotating autosave set. Treat larger caps, shorter saves, and advanced tick or timeout changes as measured exceptions rather than automatic upgrades.
Frequently Asked Questions
Can I host a Satisfactory server on Linux?
Yes. Dedicated servers support 64-bit Linux as well as 64-bit Windows. Linux configuration files are stored under <installation_directory>/FactoryGame/Saved/Config/LinuxServer/, and the same graceful-shutdown and backup practices apply.
What happens if I change the game port but not the Reliable Messaging port?
The two services can use different values, but every changed port must be reflected in startup arguments, router forwarding, firewall rules, and the connection information given to players. Leaving one rule on an old value can produce failed joins even when the other port is reachable.
How many rotating autosaves should I keep?
The retention count is controlled by mNumRotatingAutosaves. Rotating files help recover a recent state, but they should be supplemented with independent backups stored outside that rotation.
Does pause-when-empty save electricity?
It can reduce idle simulation work and therefore lower CPU activity while nobody is connected. It does not replace a service configuration, backups, or a proper shutdown plan.