By the end of this guide you'll have a Satisfactory dedicated server running on a Linux machine, claimed inside the game, locked down with an admin password, and saving your factory automatically. This is for anyone who wants their world online around the clock so friends can keep building pipes and conveyor belts even when the host has logged off. You don't need to be a Linux expert, but you should be comfortable copying commands into a terminal.
What you need before you start
A dedicated server is a separate program from the game. It has no graphics and no menus. It just holds your save and lets people connect. That means it can sit on a cheap Linux box and run forever without anyone watching it.
Here is a rough idea of what to provision. Satisfactory is a simulation game, and the server has to calculate every machine, belt and pipe on every tick. A tiny starter base barely touches the hardware. A megafactory in the late game is a different animal.
| Factory size | RAM to allocate | CPU |
|---|---|---|
| Fresh world, 2 to 4 players | 6 to 8 GB | 2 to 4 fast cores |
| Mid game, established base | 10 to 12 GB | 4 fast cores |
| Late game megafactory | 16 GB or more | 6 or more fast cores |
The thing to understand about RAM is that it grows with your save. When you start out, the server might use 3 GB. As you add thousands of machines, that figure climbs. So give yourself headroom. A server that runs fine in week one can start swapping to disk and stuttering in month three if you sized it too tight. Single core speed matters more than core count here, because the game's tick is hard to spread across many cores.
You also want fast storage. Saves get written often, and a slow disk shows up as a hitch every time the game autosaves. NVMe is ideal. At Bytte we run these on NVMe by default for exactly that reason.
Step 1: Install SteamCMD
SteamCMD is the command line version of Steam. It downloads and updates game servers. These instructions assume a Debian or Ubuntu server. If you're on another distro, the package names change but the steps don't.
First, add the 32 bit architecture and the non free repo that SteamCMD lives in, then install it. Run these as a normal user with sudo, not as root.
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository -y multiverse
sudo apt update
sudo apt install -y steamcmd
During install you'll be asked to accept the Steam license agreement. Use the arrow keys to highlight "I AGREE" and press Enter.
It's good practice to run game servers under their own user account rather than your login or root. Create one now.
sudo useradd -m -s /bin/bash satisfactory
sudo su - satisfactory
You're now acting as the satisfactory user. Everything from here happens in that user's home folder.
Step 2: Download the server with SteamCMD
The Satisfactory dedicated server has the Steam app id 1690800. You log in to SteamCMD anonymously, point it at an install folder, and tell it to download that app.
steamcmd +force_install_dir /home/satisfactory/server \
+login anonymous \
+app_update 1690800 validate \
+quit
The download is a few GB. When it finishes you'll see a line like this, which tells you it worked.
Success! App '1690800' fully installed.
The validate flag makes SteamCMD check every file after downloading. It's slightly slower but it catches corrupted downloads, so keep it. You'll run this same command later whenever you want to update the server after a game patch.
Step 3: Start the server for the first time
The launch script lives inside the install folder. Start it manually once so you can watch it boot and confirm there are no errors.
cd /home/satisfactory/server./FactoryServer.sh
You'll see a wall of log lines. The server loads its assets, then sits and waits for connections. Once you see it settle and stop scrolling, it's up. To stop it cleanly during testing, press Ctrl+C and give it a few seconds to shut down.
This raw method is fine for a first test, but it dies the moment you close your terminal. The next step fixes that.
Step 4: Run it as a background service
You want the server to start on boot and stay running. On Linux the clean way to do that is a systemd service. Exit the satisfactory user for a moment so you have sudo again.
exit
sudo nano /etc/systemd/system/satisfactory.service
Paste this in. It runs the server as the satisfactory user and restarts it automatically if it ever crashes.
[Unit]
Description=Satisfactory Dedicated Server
After=network.target
[Service]
User=satisfactory
Group=satisfactory
WorkingDirectory=/home/satisfactory/server
ExecStart=/home/satisfactory/server/FactoryServer.sh
Restart=on-failure
RestartSec=10
KillSignal=SIGINT
[Install]
WantedBy=multi-user.target
Save and exit (in nano that's Ctrl+O, Enter, then Ctrl+X). Now reload systemd, enable the service so it starts at boot, and start it.
sudo systemctl daemon-reload
sudo systemctl enable satisfactory
sudo systemctl start satisfactory
Check that it's healthy.
sudo systemctl status satisfactory
You want to see active (running) in green. To watch the live logs, which is handy while you set things up, use this.
sudo journalctl -u satisfactory -f
Step 5: Open the ports
Satisfactory uses a few UDP ports. If they're blocked, nobody can connect and the server won't even appear when you try to add it in game. The ports are 7777 for the main game traffic, 15000 for the beacon, and 15777 for the server discovery query. Modern versions mainly need 7777, but opening all three avoids confusion across game updates.
If you use the UFW firewall, run these.
sudo ufw allow 7777/udp
sudo ufw allow 15000/udp
sudo ufw allow 15777/udp
sudo ufw reload
If your server sits behind a home router instead, forward the same UDP ports to the machine's local IP in your router admin page. And if you're on a host with its own firewall panel, open them there too. A quick way to confirm a port is listening once the server is up is this.
sudo ss -ulpn | grep 7777
You should see a line showing the FactoryServer process bound to 0.0.0.0:7777.
Step 6: Claim the server from inside the game
This part trips up a lot of people, so read it slowly. A brand new Satisfactory server has no name, no password, and no save loaded. You set all of that up from the game client, not from any config file. The server is basically a blank slate waiting to be claimed by the first person who finds it.
- Launch Satisfactory on your own computer.
- Go to Server Manager from the main menu.
- Click Add Server and type your server's public IP address. If it's running on a non default port you add it as
your.ip.address:7777, otherwise the IP alone is fine. - The server will show as offline or unclaimed at first. Click it. The game asks you to set an admin password. Pick a strong one. This is the master password that lets you manage the server.
- Give the server a name so you can recognise it in your list.
Once you've set the admin password, the server is claimed and tied to you. Nobody else can take it over.
Step 7: Configure the server through the manager
With the server claimed, the Server Manager becomes your control panel. From here you handle everything that used to need text files in older games.
- Create Game lets you start a fresh save with your chosen starting location, or upload an existing save file to continue a world you already started in single player.
- Server password (separate from the admin password) is the join password. Set this if you only want friends in. Leave it blank for an open server.
- Admin password can be changed here later if it ever leaks.
- Autosave settings control how often the world is written to disk and how many backups are kept.
On autosave, the defaults are sensible but worth checking. The game keeps a rolling set of autosaves and writes one every few minutes. For an active server with several players, a shorter interval (say every 5 minutes) means less lost progress after a crash, at the cost of slightly more frequent disk writes. Keeping at least 5 rotating backups gives you something to roll back to if a save ever goes bad.
Step 8: Find and back up your saves
Your world files live in the satisfactory user's config folder, not in the install directory. The path looks like this.
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server/
The saves are .sav files. Backing them up is just a matter of copying that folder somewhere safe on a schedule. Here's a small script that makes a timestamped tarball and keeps the last 14 backups.
#!/bin/bash
SRC=/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
DEST=/home/satisfactory/backups
mkdir -p "$DEST"
STAMP=$(date +%Y-%m-%d_%H-%M)
tar -czf "$DEST/save_$STAMP.tar.gz" -C "$SRC".
ls -1t "$DEST"/save_*.tar.gz | tail -n +15 | xargs -r rm
Save that as /home/satisfactory/backup.sh, make it executable with chmod +x backup.sh, and schedule it with cron. Run crontab -e as the satisfactory user and add a line to back up every six hours.
0 */6 * * * /home/satisfactory/backup.sh
Disk space is cheap. A corrupted save with no backup costs you weeks of building. Always have backups.
Updating the server later
When Coffee Stain ships a game update, your clients update through Steam but the server does not update itself. You have to rerun the SteamCMD command. Stop the service first so files aren't locked, update, then start it again.
sudo systemctl stop satisfactory
sudo -u satisfactory steamcmd +force_install_dir /home/satisfactory/server \
+login anonymous +app_update 1690800 validate +quit
sudo systemctl start satisfactory
If the server version and client version don't match, players get kicked or can't join, so keep them in sync after any patch.
Troubleshooting
The server won't appear when I add it
This is almost always a port or firewall issue. Confirm the service is running with systemctl status satisfactory. Then check that UDP 7777 is open and that the process is actually listening with sudo ss -ulpn | grep 7777. If you're behind a router or a host firewall, the port has to be forwarded there too, not just in UFW. Remember these are UDP ports, not TCP. Forwarding TCP 7777 by mistake is a common slip.
I can't claim the server
If the Add Server dialog finds the server but claiming fails, the connection is reaching the server but something is interrupting the handshake. Double check you typed the public IP and not a local one. Make sure the beacon port 15000 and query port 15777 are open as well as 7777. And confirm the server fully finished booting in the logs before you tried, since a half started server can show up but reject claims.
The server lags as my save gets bigger
This is the single core simulation catching up with your factory. Two things help. First, give the machine more RAM if it's near its limit, because a server that's swapping to disk stutters badly. Check usage with free -h and watch the FactoryServer process in htop. Second, faster single core CPU performance helps more than extra cores, so if you're on a shared box with weak cores, a move to faster hardware is the real fix. Late game megafactories are demanding, and there's a limit to what any single machine can simulate smoothly.
The service keeps restarting
Read the logs with journalctl -u satisfactory -e and look at the lines just before each restart. A common cause is the server running out of memory and getting killed by the kernel, which shows up as an "oom-killer" message. The fix is more RAM or a smaller player count. Another cause is a partly downloaded install, so rerun the SteamCMD update with validate to repair files.
My save disappeared or won't load
Check the save folder path is correct and that the .sav files are owned by the satisfactory user. If ownership got messed up after copying files as root, fix it with sudo chown -R satisfactory:satisfactory /home/satisfactory. If the active save is corrupted, restore the most recent backup from your tarballs and load it through the Server Manager.
Wrapping up
You've now got a Satisfactory server that boots on its own, restarts after a crash, is locked behind an admin password, and backs up its saves on a schedule. The two habits that matter most going forward are keeping the server updated in step with the game after every patch, and never trusting a single save file without backups. Do those two things and your factory will keep humming along whether anyone's watching it or not. Now go build something that grows.



