Self-Hosting a Satisfactory Dedicated Server on Linux with Docker
Published 2026-07-20 · SameOS Tools
I have been running a Satisfactory dedicated server (a multiplayer server you host yourself instead of renting) on a home Linux box for several months. Satisfactory suits a dedicated server especially well, because the whole point is that your factory keeps producing while you are logged off. The config I started with and the config I run today are noticeably different, and those differences are exactly what running it taught me, so I wrote them down as they are.
Requirements - memory is the deciding factor
A Satisfactory server eats more memory than most game servers, because the bigger your factory grows, the more machines it has to simulate. Mine reserves 4GB and is capped at 12GB, and a four-player world well into the late game stayed inside that. Worth knowing: four players is the officially supported cap. A dedicated server can be raised to 8 through configuration alone - no mods needed - but the server is tuned around four, so anything above that carries no performance guarantee. If you plan to run five or more, 16GB of RAM is the safer floor. For disk, the game files alone are 2.8GB before saves and backups, so leave about 10GB free. Four CPU cores is plenty. Software-wise you only need Docker (a tool that runs programs in isolated boxes); the server files download automatically and do not require a Steam login or a copy of the game.
Installing Docker
If Docker is not on the server yet, install it first. Connect over SSH (the channel you use to send commands to a remote machine) and run the following in order. If Docker is already there because you run other game servers, skip to creating the working folder.
# 1) Official Docker install script (Ubuntu, Debian, etc.)
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
# 2) Verify - both lines should print a version
docker --version
docker compose version
# 3) (Optional) run docker without sudo - takes effect after re-login
sudo usermod -aG docker $USER
# 4) Create the working folder - config and saves all live here
mkdir -p ~/satisfactory && cd ~/satisfactoryThe compose file - the three ports do different jobs
Save the following as compose.yaml in your working folder and you are set up. Ports are where most people get stuck: Satisfactory uses the same number, 7777, over both UDP and TCP. UDP 7777 carries actual gameplay traffic, while TCP 7777 is how the game client registers and manages the server. Open only one and the server either shows up but refuses connections, or never appears at all. Port 8888 was added in game version 1.1 and should be opened too. If you are behind a router, forward all three (port forwarding sends incoming connections to a specific machine on your home network) or your friends will not get in.
# compose.yaml
services:
satisfactory-server:
image: wolveix/satisfactory-server:latest
container_name: satisfactory-server
restart: unless-stopped # auto-recover from crashes and reboots
stop_grace_period: 90s # give it time to save - explained below
environment:
- MAXPLAYERS=8 # 4 is the supported cap; 8 works via config alone (no mods)
- PUID=1000 # file ownership - 1000 is fine for most setups
- PGID=1000
- STEAMBETA=false # true switches to the experimental build
volumes:
- ./config:/config # saves, backups and settings all land here
ports:
- "7777:7777/udp" # gameplay traffic
- "7777:7777/tcp" # server registration (must be open alongside UDP)
- "8888:8888/tcp" # added in game version 1.1
mem_reservation: 4g # memory floor
mem_limit: 12g # ceiling - keeps the host out of memory troubleFirst start and connecting from the game
Now start the server. The first run downloads 2.8GB of game files and takes 10-20 minutes, so watch the log while it works. Once it is ready, open the game and add your server address in the server manager. Use the internal address when testing from the same house, and your public IP (the address that points to your home from the internet) when friends connect. On first connection the game asks you to set an admin password - that is set from inside the game, so there is nothing to write into a config file beforehand.
# Start the server (-d = run in the background)
docker compose up -d
# Check readiness - "healthy" means it is accepting players
docker ps
# Watch the first-run log (Ctrl+C exits the log, the server keeps running)
docker compose logs -f
# Addresses to connect from the game
# Same house : 192.168.0.x:7777 (server's internal address)
# Friends : PUBLIC-IP:7777 (requires port forwarding on the router)The trap that cost me the most - shutting down wrong loses progress
This is the one that hurt. When the Satisfactory server receives a shutdown signal it writes your progress to a save file, and the bigger the factory, the longer that write takes. Docker, however, waits only 10 seconds by default before killing the process outright. If it is cut off mid-save, the world rolls back to the last autosave and everything built since then is gone. That is why the config above sets stop_grace_period: 90s. Helpfully, this image also keeps backups on its own: a clean shutdown leaves shutdown-DATE.sav, a restart leaves restart-DATE.sav, and autosaves accumulate while the game runs. Copying that folder to another disk on a schedule is cheap peace of mind.
# Shut down safely - waits up to 90s for the save to finish (never kill it)
docker compose stop
# Check that backups are accumulating - newest 5
ls -lt ~/satisfactory/config/backups/ | head -6
# sameos_autosave_1.sav in-game autosave
# restart-20260718-005827.sav backup written on restart
# shutdown-20260718-042049.sav backup written on clean shutdown
# Copy the save folder to another disk (daily is a good rhythm)
cp -a ~/satisfactory/config/saved /mnt/backup/satisfactory-$(date +%Y%m%d)Adding mods - one command on the server side
In single-player you just toggle mods in the launcher, but a dedicated server needs the same mods installed on the server too, or clients get kicked for a mod mismatch. Satisfactory ships an official mod manager command called ficsit, which works on servers as well. Mine runs a production-efficiency mod, and installing one mod pulls in whatever it depends on (the SML mod loader and so on) automatically. Restart the server after adding or removing mods, and make sure everyone connecting has the same set.
# 1) Download the ficsit command (from your server working folder)
mkdir -p ~/satisfactory/bin && cd ~/satisfactory/bin
curl -L -o ficsit https://github.com/satisfactorymodding/ficsit-cli/releases/latest/download/ficsit_linux_amd64
chmod +x ficsit
# 2) Register where the game is installed (gamefiles inside config)
./ficsit installation add ~/satisfactory/config/gamefiles
# 3) Install a mod - dependencies are pulled in automatically
./ficsit mod install EfficiencyCheckerMod
# 4) Verify and restart
ls ~/satisfactory/config/gamefiles/FactoryGame/Mods
docker compose restartWhat months of uptime changed
Comparing my first config with the current one, three things moved: the player cap went from 4 to 8, a memory ceiling appeared, and the shutdown grace period grew to 90 seconds. The player cap was headroom rather than a tested figure - I have never had eight people connected at once, and as noted above four is the supported number, so treat that value as a placeholder. The grace period is different: I only learned it by losing progress, so if you take one line from this article, take that one.
Once the server is stable, the next problem becomes factory design - working out how many machines you need for a target output per minute. That math gets tedious by hand, so I built a browser calculator for it, linked below.