Satisfactory Server

This is a Dockerized version of the Satisfactory dedicated server with OpenShift compatibility.

Deployment Options

OpenShift with ArgoCD (Recommended for Production)

For OpenShift deployments using GitOps with ArgoCD, see the OpenShift ArgoCD Deployment Guide.

Quick start:

1. Build and push the OpenShift-compatible image
2. Update image references in the manifests
3. Deploy via ArgoCD: oc apply -f openshift/argocd-application.yaml

Standard Docker/Kubernetes

For traditional Docker or Kubernetes deployments, see the original deployment methods below.

Setup

The server may run on less than 8GB of RAM, though 8GB - 16GB is still recommended per the the official wiki. You may need to increase the container's defined --memory restriction as you approach the late game (or if you're playing with many 4+ players)

You'll need to bind a local directory to the Docker container's /config directory. This directory will hold the following directories:

• /backups - the server will automatically backup your saves when the container first starts
• /gamefiles - this is for the game's files. They're stored outside the container to avoid needing to redownload 8GB+ every time you want to rebuild the container
• /logs - this holds Steam's logs, and contains a pointer to Satisfactory's logs (empties on startup unless LOG=true)
• /saved - this contains the game's blueprints, saves, and server configuration

Before running the server image, you should find your user ID that will be running the container. This isn't necessary in most cases, but it's good to find out regardless. If you're seeing permission denied errors, then this is probably why. Find your ID in Linux by running the id command. Then grab the user ID (usually something like 1000) and pass it into the -e PGID=1000 and -e PUID=1000 environment variables.

Run the Satisfactory server image like this (this is one command, make sure to copy all of it):

docker run \
--detach \
--name=satisfactory-server \
--hostname satisfactory-server \
--restart unless-stopped \
--volume ./satisfactory-server:/config \
--env MAXPLAYERS=4 \
--env PGID=1000 \
--env PUID=1000 \
--env STEAMBETA=false \
--memory-reservation=4G \
--memory 8G \
--publish 7777:7777/tcp \
--publish 7777:7777/udp \
--publish 8888:8888/tcp \
wolveix/satisfactory-server:latest

Explanation of the command

• --detach -> Starts the container detached from your terminal
  If you want to see the logs replace it with --sig-proxy=false
• --name -> Gives the container a unqiue name
• --hostname -> Changes the hostname of the container
• --restart unless-stopped -> Automatically restarts the container unless the container was manually stopped
• --volume -> Binds the Satisfactory config folder to the folder you specified Allows you to easily access your savegames
• For the environment (--env) variables please see here
• --memory-reservation=4G -> Reserves 4GB RAM from the host for the container's use
• --memory 8G -> Restricts the container to 8GB RAM
• --publish -> Specifies the ports that the container exposes
  

Docker Compose

If you're using Docker Compose:

services:
  satisfactory-server:
    container_name: 'satisfactory-server'
    hostname: 'satisfactory-server'
    image: 'wolveix/satisfactory-server:latest'
    ports:
      - '7777:7777/tcp'
      - '7777:7777/udp'
      - '8888:8888/tcp'
    volumes:
      - './satisfactory-server:/config'
    environment:
      - MAXPLAYERS=4
      - PGID=1000
      - PUID=1000
      - STEAMBETA=false
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          memory: 4G

Updating

The game automatically updates when the container is started or restarted (unless you set SKIPUPDATE=true).

To update the container image itself:

Docker Run

docker pull wolveix/satisfactory-server:latest
docker stop satisfactory-server
docker rm satisfactory-server
docker run ...

Docker Compose

docker compose pull
docker compose up -d

SSL Certificate with Certbot (Optional)

You can use Certbot with Let's Encrypt to issue a signed SSL certificate for your server. Without this, Satisfactory will use a self-signed SSL certificate, requiring players to manually confirm them when they initially connect. If you're experiencing connectivity issues since issuing a certificate, check the link below for known issues.

Learn more.

Kubernetes/OpenShift

For OpenShift deployments with ArgoCD (recommended), see the OpenShift ArgoCD Guide.

For standard Kubernetes clusters, basic manifests are available in the cluster directory:

• service.yaml - LoadBalancer service
• statefulset.yaml - Basic StatefulSet
• values.yaml - Helm values example

For Helm deployments, charts are available on ArtifactHUB.

Environment Variables

Parameter	Default	Function
AUTOSAVENUM	5	number of rotating autosave files
DEBUG	false	for debugging the server
DISABLESEASONALEVENTS	false	disable the FICSMAS event (you miserable bastard)
LOG	false	disable Satisfactory log pruning
MAXOBJECTS	2162688	set the object limit for your server
MAXPLAYERS	4	set the player limit for your server
MAXTICKRATE	30	set the maximum sim tick rate for your server
MULTIHOME	::	set the server's listening interface (usually not needed)
PGID	1000	set the group ID of the user the server will run as
PUID	1000	set the user ID of the user the server will run as
SERVERGAMEPORT	7777	set the game's server port
SERVERMESSAGINGPORT	8888	set the game's messaging port (internally and externally)
SERVERSTREAMING	true	toggle whether the game utilizes asset streaming
SKIPUPDATE	false	avoid updating the game on container start/restart
STEAMBETA	false	set experimental game version
TIMEOUT	30	set client timeout (in seconds)
VMOVERRIDE	false	skips the CPU model check (should not ordinarily be used)

Experimental Branch

If you want to run a server for the Experimental version of the game, set the STEAMBETA environment variable to true.

Modding

Mod support is available. This Docker container functions the same as a standalone installation, so you can follow the excellent technical documentation from the community here.

For file access to install mods, you can:

• Use kubectl cp or oc cp to copy files to/from the container
• Mount the game files directory on a host for direct access
• Use container exec to access the shell: kubectl exec -it satisfactory-0 -- /bin/bash

How to Improve the Multiplayer Experience

The Satisfactory Wiki recommends a few config tweaks for your client to really get the best out of multiplayer:

• Press WIN + R
• Enter %localappdata%/FactoryGame/Saved/Config/WindowsNoEditor
• Copy the config data from the wiki into the respective files
• Right-click each of the 3 config files (Engine.ini, Game.ini, Scalability.ini)
• Go to Properties > tick Read-only under the attributes

Running as Non-Root User

By default, the container runs with root privileges but executes Satisfactory under 1000:1000. If your host's user and group IDs are 1000:1000, you can run the entire container as non-root using Docker's --user directive. For different user/group IDs, you'll need to clone and rebuild the image with your specific UID/GID:

Building Non-Root Image

1. Clone the repository:

git clone https://github.com/wolveix/satisfactory-server.git

2. Create a docker-compose.yml file with your desired UID/GID as build args (note that the PUID and PGID environment variables will no longer be needed):

services:
  satisfactory-server:
    container_name: 'satisfactory-server'
    hostname: 'satisfactory-server'
    build:
      context: .
      args:
        UID: 1001  # Your desired UID
        GID: 1001  # Your desired GID
    user: "1001:1001"  # Must match UID:GID above
    ports:
      - '7777:7777/tcp'
      - '7777:7777/udp'
      - '8888:8888/tcp'
    volumes:
      - './satisfactory-server:/config'
    environment:
      - MAXPLAYERS=4
      - STEAMBETA=false
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          memory: 4G

3. Build and run the container:

docker compose up -d

Known Issues

• The container is run as root by default. You can provide your own user and group using Docker's --user directive; however, if your proposed user and group aren't 1000:1000, you'll need to rebuild the image (as outlined above).
• The server log will show various errors; most of which can be safely ignored. As long as the container continues to run and your log looks similar to the example log, the server should be functioning just fine: example log

Star History