How to set up a Satisfactory server: a step-by-step guide
This guide takes you from nothing to a working Satisfactory dedicated server: choosing an operating system, installing through SteamCMD, claiming the server, opening ports and the mistakes most often made on first boot. One thing should be clear from the start, because it is where Satisfactory differs from every other game here: resource needs grow with factory size, not player count. A four-player server can need twice the memory it needed on day one, because of a huge production line built months later.
Before you start
- A server. In a new game, four players run comfortably on 8 GB / 4 vCPU. In late-game factories — tens of thousands of machines, long conveyor runs and train networks — 16 GB is normal. Sizing by the first week's usage is the most expensive mistake in this game. The logic behind the calculation: how many vCPUs and how much RAM? Use the server configurator to pick resources one by one and see the monthly total.
- Players who own the game. The server software downloads anonymously and free, but everyone who connects has to own the game.
- A destination for backups. In this game the save file is the factory, and its loss cannot be undone.
1. Operating system
Ubuntu 22.04 LTS is the practical choice; Satisfactory's official Linux dedicated server runs cleanly on distributions of this class and you get more out of the same hardware than on Windows. The server needs no graphical interface, so the only effect of choosing a template with a desktop installed is wasted RAM.
You will manage the server over SSH; for key-based access and the hardening steps worth doing on day one, see connecting to a server over SSH.
2. Installing through SteamCMD
The server files are downloaded anonymously through SteamCMD; the app ID for the Satisfactory dedicated server is 1690800:
./steamcmd.sh +force_install_dir /home/satisfactory/server +login anonymous \
+app_update 1690800 validate +quitOnce the download finishes, the server is started with the FactoryServer.sh script. Do not leave it attached to an SSH session: when the session closes, so does the process. Defining it as a systemd service with Restart=always removes most of the downtime players would otherwise see.
3. Claiming the server and loading a save
In Satisfactory, most of the configuration happens not in a text file but in the in-game server manager. When the server first starts it is unclaimed: the first person to connect to its IP address from the game sets the administrator password and claims it. Skip that step and the server stays up with no game loaded at all.
After claiming it you set the server name and then either start a new game or load an existing save. If you are migrating an existing world, load the save through the in-game manager; copying the file by hand causes version mismatches, and that is the hardest possible way to get a factory back.
Saves live in the Saved/SaveGames folder under the server's user profile. That folder is exactly what you back up, not the whole installation directory. Limit the number of autosaves: each one writes a complete file, and since a single late-game save can reach hundreds of megabytes, accumulated saves hold a significant share of the disk. For the same reason, the stutter you feel while saving depends on disk speed; the measurable side of that is in what is an NVMe SSD?
4. Ports
| Port | Protocol | Purpose |
|---|---|---|
| 7777 | TCP + UDP | Game traffic and server administration |
| 15000 / 15777 | UDP | Older builds only: query and beacon |
Current builds need the single port, but if you are migrating an installation that stayed on an older version, both UDP ports need opening as well. If you are on Datafex, port management and extra IP requests are handled from the customer panel.
The most common first-boot mistakes
- The server was never claimed. The process runs, players cannot connect, and what is missing is setting the administrator password.
- The save file was copied by hand. On a version mismatch it either does not load or loads corrupted.
- The plan was chosen from the first week's usage. Memory demand multiplies over months as the factory grows.
- The autosave count was never limited. The disk fills quietly and the server stops the moment it cannot write a save.
- Trying to fix stutter by adding vCPUs. The production loop runs on one thread; extra cores give no measurable gain and the fix is a higher clocked processor.
- No backups. The full approach: server backup strategy
On the DDoS side
Satisfactory servers usually serve small, closed groups, so the attack surface is narrower than a roleplay server's. That does not make them immune: game traffic flows over UDP, and because source addresses can be forged in UDP, floods cannot be solved at the application layer. Details: what is DDoS protection?
On Datafex servers, layered Fexwall DDoS protection is included free on every plan.
Next step
As the factory grows, the limit becomes the single-threaded production loop rather than the player count, and at that threshold the right move is upgrading the processor family rather than adding cores. Processor options and the plans recommended by factory scale are on one page: Satisfactory server plans. If you want to compare memory and storage steps, the virtual server plans are your starting point.