What a Satisfactory server needs
The official wiki's requirements are short. The processor matters most: the server uses several cores but, in the wiki's words, heavily favours single-core performance, and it gives a single-thread benchmark rating of 2000 or higher as the level that should work. An Intel i5-3570 or AMD Ryzen 5 3600 is the stated baseline. There is no ARM or 32-bit build, and the wiki warns that a virtual machine presenting a generic kvm64 processor will not run it.
Memory is listed as 8 GB, with 16 GB suggested for larger saves or for hosting more than four players. Those are figures for a whole machine, and the wiki adds that real needs depend on the player count and the size of the save file. In practice the factory decides: a young world is light, and a late game megabase with long belts and busy train lines is what uses the larger figure.
The server is tuned for four players, which is the default cap. Our Satisfactory plan is 6 GB for €16.99 a month with VAT included.
- CPU: one fast core matters more than many cores, single-thread rating of 2000 or higher
- Memory: 8 GB listed, 16 GB suggested for larger saves or more than four players
- Disk: the wiki lists 12.4 GB of server files on Windows and about 2 GB of server files on Linux
- Players: four by default, and the server is tuned for that number
- Operating system: Windows 10 or 11, Windows Server 2016 to 2022, or a Linux distribution such as Debian or Ubuntu
Install the server with SteamCMD
The dedicated server is its own Steam app, number 1690800, and it downloads anonymously. You do not need to own the game on the account that runs SteamCMD, and you do not need the full game installed on the server machine.
On a Windows PC the server also appears under Tools in the Steam library. On a rented or headless machine, SteamCMD is the normal route, and a hosting panel runs the same command for you during installation.
Start the server once and leave it running. Nothing is playable yet: a new server has no name, no password and no save until someone claims it from the game.
- Install or update: steamcmd +force_install_dir <folder> +login anonymous +app_update 1690800 validate +quit
- Experimental branch: add -beta experimental after the app number
- Back to the normal release: use -beta public, because SteamCMD can remember the branch you picked last
- Check it is listening: open https://your-ip:7777/ in a browser. A certificate warning followed by a short JSON error means the server is up
Ports: 7777 on UDP and TCP, plus 8888 on TCP
This is the part most guides get wrong, because the answer has changed three times.
Since Patch 1.1 a server needs the standard port, 7777 by default, on both UDP and TCP, and a second port for reliable messaging, 8888 by default, on TCP only. UDP 7777 carries game traffic. TCP 7777 carries the server's HTTPS API, which is what the in-game Server Manager talks to. TCP 8888 carries the reliable messaging channel. If 8888 is not reachable, the wiki describes the exact symptom: players can start connecting and then sit on the loading screen forever.
The standard port is changed with the -Port= launch parameter. The wiki states that port redirection is not supported for it, so the outside and inside port numbers must be the same. Do not forward outside port 7778 to inside port 7777.
The reliable port is more flexible. Set it with -ReliablePort=, and if your router or host maps it to a different outside number, tell the server with -ExternalReliablePort=. Without -ReliablePort the server starts at 8888 and tries up to 512 ports upward until it finds a free one, a range you can change in Engine.ini under the ReliableMessagingTCPFactory section with PortRangeBegin and PortRangeLength. If you do set -ReliablePort and that port is taken, the server refuses to start instead of picking another. Players only ever type the standard port: the game tells the client which reliable port to use.
Guides that list ports 15000 and 15777, the old beacon and query ports, describe the game before Patch 1.0. The wiki says plainly that those two numbers are no longer used. Guides that mention the game port plus 20000 on TCP, 27777 by default, describe a short period after Patch 1.0.1.6 that Patch 1.1 replaced with port 8888.
- 7777 UDP: game traffic
- 7777 TCP: the HTTPS API used by the Server Manager
- 8888 TCP: reliable messaging, needed since Patch 1.1
- 15000 and 15777: not used since Patch 1.0
- Running two servers on one address: give each its own -Port and -ReliablePort
Claim the server and set the admin password
A fresh server belongs to whoever claims it first, so do this as soon as it is running.
Open Satisfactory, choose Server Manager from the main menu and add the server by its address and port. The server creates its own self-signed certificate, so the game asks you to confirm it the first time. Then give the server a name and set the administrator password. That is the claim.
The administrator password is what protects loading saves, changing server options and creating a new game. It is separate from the player password. Player password protection is off by default, and you turn it on with the Change Password button in the Server Settings tab if you want to limit who can join.
If you lose the administrator password, the wiki's fix is to stop the server and delete the settings file named ServerSettings.7777.sav, with your own port number in the name, which sits just above the server's save folder. That also resets the server name, the player password, the session that loads automatically and the certificate, and the server can then be claimed again.
Upload an existing save, or start a new game
Once the server is claimed you can either create a new game from the Server Manager or bring a world you already have.
The simple way to move a save is from inside the game: open the server in the Server Manager, go to the Manage Saves tab and upload a local save. The server stores its saves in a folder named server inside its SaveGames directory. On Linux that is ~/.config/Epic/FactoryGame/Saved/SaveGames/server, and on Windows it is %LocalAppData%\FactoryGame\Saved\SaveGames\server for the user running the server. You can copy a .sav file there over SFTP instead and then load it from the Server Manager.
Blueprints are stored next to it, in a blueprints folder inside the same SaveGames directory, which only appears once the first blueprint has been made.
Set the Auto-Load Session Name option to your session so the server loads the most recent save of that session whenever it starts.
Autosaves and the settings worth changing
The wiki's configuration page gives the defaults: the server saves every 300 seconds, which is five minutes, and keeps three rotating autosaves named after the session with _autosave_0, _1 and _2 on the end. When a new one is written the oldest is dropped.
The interval is changed from the Server Manager, either with the Autosave Interval setting or with the console command FG.AutosaveInterval followed by a number of seconds. The wiki notes the trade: saving more often costs server performance while each save is written. On a large factory a longer interval is usually the better choice.
The number of copies kept is set in Engine.ini with mNumRotatingAutosaves in the FGSaveSession section. Edit ini files only while the server is stopped, because the server rewrites them on a clean shutdown and will overwrite your change. They live in FactoryGame/Saved/Config/LinuxServer or WindowsServer inside the install folder.
Three rotating autosaves are not a backup. They sit on the same disk and roll over within fifteen minutes at the default interval, so keep separate copies of the save folder as well.
- Auto Pause: pauses the game when nobody is connected. Leave it off if you want the factory to keep producing while everyone is logged off
- Auto-Save on Player Disconnect: writes a save whenever a player leaves
- Server Restart Interval: despite the name, this is the hour of the day at which the server restarts, not a number of hours
- MaxPlayers: set in Game.ini under /Script/Engine.GameSession. The default is four, and the wiki warns that raising it can hurt stability and performance
- server.SaveGame <name>: a console command that saves the session on demand
Updates and the Experimental branch
Updating is the same SteamCMD command you installed with. Run it with the server stopped and it downloads whatever changed. The wiki notes that dedicated server builds are released alongside every game patch, so when players receive a patch through Steam or Epic, update the server before the next session.
Satisfactory has two public branches. The normal release is what most players are on. Experimental is where Coffee Stain publishes updates first, and its own patch notes tell players to back up their saves before trying it. A server on Experimental is for a group that has all chosen Experimental in their own game. Move the server with -beta experimental, and move it back with -beta public.
Before any update, and always before changing branch, copy the save folder somewhere else. For shutting down, the wiki recommends the HTTPS API's shutdown function, or typing quit in the Console tab of the Server Manager, so the server closes cleanly and writes its settings.