Dedicated servers/Running as a Service

This page describes how to set up a **dedicated server as a service**.

## Running as a Service

Running the dedicated server as a Service allows your server to auto-restart in the event of a crash, as well as automatically start after booting. How this is handled differs between Linux and Windows operating systems, so make sure you use the correct section for your environment.

### Linux

#### Systemd

Systemd is the service management system installed for many Linux distributions.

Ensure SteamCMD is installed. Once done, some small preparations for Systemd must be made defining the service and configuring it. The following systemd unit file for the Satisfactory service will automatically use SteamCMD to check for updates any time the server is started or restarted. It will also start the server when the host is rebooted. Edit the user and path to reflect the location and owner of the Satisfactory installation. The unit file should be placed at `/etc/systemd/system/satisfactory.service`

```
[Unit]
Description=Satisfactory dedicated server
Wants=network-online.target
After=syslog.target network.target nss-lookup.target network-online.target

[Service]
Environment="LD\_LIBRARY\_PATH=./linux64"
ExecStartPre=/usr/games/steamcmd +force\_install\_dir /home/your\_user/SatisfactoryDedicatedServer +login anonymous +app\_update 1690800 validate +quit
ExecStart=/home/your\_user/SatisfactoryDedicatedServer/FactoryServer.sh -ServerQueryPort=15777 -BeaconPort=15000 -Port=7777 -log -unattended -multihome=0.0.0.0
User=your\_user
Group=your\_user
StandardOutput=journal
Restart=on-failure
WorkingDirectory=/home/your\_user

[Install]
WantedBy=multi-user.target

```

Change `your_user` and adjust the parameters to match your desired configuration. The parameter `'-multihome=0.0.0.0'` is required if you are using IPv4 to connect.

The above configuration will have the server logs written to the system Journal. If you do not wish for this to happen, and would rather have log and error messages sent to files on disk, you can add the following two directives to the [Service] section of the Unit file. Bear in mind that if you do so, the log files will grow without limit if you do not also set up a log rotation scheme such as configuring `logrotated` to archive and rotate logs for you. That configuration is beyond the scope of this article. With that in mind, to log to disk rather than the journal, add these directives:

```
[Service]
...
StandardOutput=append:/var/log/satisfactory.log
StandardError=append:/var/log/satisfactory.err

```

After creating the service, you will need to execute a daemon-reload to load the new service into systemd:

```
$ sudo systemctl daemon-reload

```

To enable and start the service, use the following two commands respectively:

```
$ sudo systemctl enable satisfactory
$ sudo systemctl start satisfactory

```

You can check the status with `sudo systemctl status satisfactory`. If configured correctly the output should look something like:

```
● satisfactory.service - Satisfactory dedicated server
 Loaded: loaded (/etc/systemd/system/satisfactory.service; enabled; vendor preset: enabled)
 Active: active (running) since Tue 2021-11-02 15:30:13 CET; 2min 21s ago
 Main PID: 2529 (FactoryServer.s)
 Tasks: 24 (limit: 7053)
 Memory: 4.4G
 CPU: 4min 5.965s
 CGroup: /system.slice/satisfactory.service
 ├─2529 /bin/sh /home/steam/SatisfactoryDedicatedServer/FactoryServer.sh
 └─2536 /home/steam/SatisfactoryDedicatedServer/Engine/Binaries/Linux/UE4Server-Linux-Shipping FactoryGame

```

If the service times out before its loaded it will continue in a loop. This can happpen if you are testing on older hardware that doesn't reach the minimum requirements for the server hardware. To prevent this you can add the following line to the [Service] section: TimeoutSec=XXX . You replace the XXX with a numerical value in seconds. Normally a service times out after 90 seconds on most distros.

##### Experimental Branch

To have `systemd` pre-fetch the Experimental branch of the Dedicated Server upon restart, adjust the `ExecStartPre` directive to tell SteamCMD to use the `experimental` branch, as follows (truncated for brevity):

```
[Service]
#...
ExecStartPre=/usr/games/steamcmd +force\_install\_dir /home/your\_user/SatisfactoryDedicatedServer +login anonymous +app\_update 1690800 -beta experimental validate +quit
#...

```

#### OpenRC

OpenRC is a service management system for Gentoo Linux.

Install SteamCMD using Portage, and accept it's license. Its installation directory by default is `/opt/steamcmd`.

The recommended way to get it set up is to link to the already existing SteamCMD init file with `ln -s /etc/init.d/steamcmd /etc/init.d/steamcmd.satisfactory` and then copying the default config from `/etc/conf.d/steamcmd` to `/etc/conf.d/steamcmd.satisfactory`.

The completed `/etc/conf.d/steamcmd.satisfactory` would look something like this:

```

# Options for your server binary.
STEAMCMD\_OPTS=""

```

### Windows

#### NSSM

You can use Non-Sucking Service Manager to easily set up auto-restart for the dedicated server.

Once you've downloaded and installed NSSM, navigate to the directory containing nssm.exe and run the below command:

```
nssm.exe install SatisfactoryServerService

```
This will pull up a GUI for configuration. Set the "**Path**" to the location of FactoryServer.exe, Set the "**Arguments**" to "-unattended". You can modify other settings if you want, but that's the only required step. Click "install", then run this command.

```
nssm.exe start SatisfactoryServerService

```
Other useful `nssm` commands:

```
nssm.exe status SatisfactoryServerService # Checks the status of the Service
nssm.exe stop SatisfactoryServerService # Stops the service, and prevents it from auto-restarting

```

### Docker

Docker is a cross-platform utility designed to run services in virtual machines in a compartmentalized fashion. This is an example `dockerfile` you can use to run the Satisfactory dedicated server inside a docker container

```
FROM cm2network/steamcmd:root
#BUILD: docker build -t satisfactory .
#RUN: mkdir data; docker run -p 15000:15000/udp -p 7777:7777/udp -p 15777:15777/udp -d --name=satisfactory -v $(pwd)/data:/home/steam/Satisfactory-dedicated satisfactory
ENV STEAMAPPID 1690800
ENV STEAMAPP Satisfactory
ENV STEAMAPPDIR "${HOMEDIR}/${STEAMAPP}-dedicated"
RUN echo -e "export LD\_LIBRARY\_PATH=${STEAMAPPDIR}/linux64:$LD\_LIBRARY\_PATH\n\
bash ${STEAMCMDDIR}/steamcmd.sh +login anonymous +force\_install\_dir ${STEAMAPPDIR} +app\_update ${STEAMAPPID} validate +quit\n\
test -d ~/.config/Epic/FactoryGame/Saved || mkdir -p ~/.config/Epic/FactoryGame/Saved\n\
test -d ${STEAMAPPDIR}/saves || mkdir ${STEAMAPPDIR}/saves\n\
test -L ~/.config/Epic/FactoryGame/Saved/SaveGames || ln -s ${STEAMAPPDIR}/saves ~/.config/Epic/FactoryGame/Saved/SaveGames\n\
${STEAMAPPDIR}/FactoryServer.sh" >> ${HOMEDIR}/entry.sh
RUN chmod +x "${HOMEDIR}/entry.sh" && chown -R "${USER}:${USER}" "${HOMEDIR}"
USER ${USER}
VOLUME ${STEAMAPPDIR}
WORKDIR ${HOMEDIR}
CMD ["bash", "entry.sh"]
EXPOSE 15777/udp 15000/udp 7777/udp

```
The `$STEAMAPPDIR` is declared as a volume so that the savegames and the config of the server can be accessed and modified from outside the container. If that is not mapped to a host directory as done with -v, it will go into `/var/lib/docker/volumes`. You can find exactly where using docker inspect on the running container. More information here.

#### Docker-Compose

 Use the following example docker-compose file in parallel with the Dockerfile and run `docker-compose up -d` for a detached background server.

```
version: "3"
 build: .
 restart: always
 ports:
 - 15777:15777/udp
 - 15000:15000/udp
 - 7777:7777/udp
 volumes:
 - ./data:/home/steam/Satisfactory-dedicated

```