Inhalt dieses Guides
Satisfactory Dedicated Server automatisch aktualisieren und starten: SteamCMD, systemd, Windows-Service, Save vor Restart und Versionswechsel sauber planen.
Server-Arbeitsmodus
Arbeite den Guide kontrolliert ab und ändere immer nur eine Variable. Dein Fortschritt bleibt nur in diesem Browser gespeichert.
Wo hängt dein Server gerade?
Netzwerkdiagnose bringt nichts, solange der Server lokal nicht sauber startet oder lauscht.
Wenn localhost/LAN funktioniert, liegt der nächste Prüfbereich bei Host-Firewall, Router, öffentlicher Adresse und NAT.
Bei Lag, Abstürzen oder Update-Problemen sind Logs, Ressourcen, Mods und ein sauberer Rollbackpfad wichtiger als weitere Portregeln.
Ein Satisfactory-Server sollte nach einem Reboot wieder starten können und nach Spielupdates zeitnah kompatibel sein. Automatisierung ist dabei nützlich, darf aber nicht dazu führen, dass der Server ohne Save oder Backup unkontrolliert neu startet.
SteamCMD als Updatebasis
Die offizielle Server-App 1690800 lässt sich mit app_update 1690800 validate aktualisieren. Für stabile und Experimental-Zweige können unterschiedliche Branch-Parameter verwendet werden.
Linux mit systemd
Das offizielle Wiki zeigt einen systemd-Dienst, der vor dem Serverstart SteamCMD ausführt. Restart=on-failure sorgt für Neustart bei Crash. Der Dienst sollte unter einem eingeschränkten Benutzer laufen.
SIGINT statt harter Kill
Für systemd wird KillSignal=SIGINT empfohlen. Allerdings weist das Wiki darauf hin, dass auch ein sauberer Prozessstopp nicht automatisch einen frischen Spielstand garantiert. Deshalb sollte vor geplanten Restarts explizit gespeichert werden.
Save vor Update
Ein robuster Ablauf lautet: Spieler informieren → Save auslösen → Backup kopieren oder herunterladen → Server stoppen → Update durchführen → Server starten → Status prüfen.
Windows-Service
Unter Windows kann beispielsweise NSSM verwendet werden, um die Server-EXE als Service zu betreiben. Auch hier sollte Update- und Startlogik voneinander getrennt werden, damit ein fehlerhaftes Update keinen Restart-Loop erzeugt.
Experimental nicht versehentlich aktivieren
Produktive Server sollten nicht automatisch zwischen Stable und Experimental wechseln. Branch-Auswahl ist eine bewusste Entscheidung und sollte zum Clientstand der Gruppe passen.
Rollback vorbereiten
Ein echtes Rollback benötigt nicht nur ein altes Savegame, sondern gegebenenfalls auch kompatible Serverdateien. Vor großen Versionswechseln lohnt sich daher ein kompletter Snapshot der Umgebung.
Health-Check nach dem Neustart
Ein erfolgreich gestarteter systemd-Dienst bedeutet noch nicht, dass die Welt geladen und der Server spielbereit ist. Prüfe nach Updates Prozessstatus, Logs und - wenn vorhanden - Query/API-Status. Erst danach sollte der Wartungsvorgang als erfolgreich gelten.
Updatefenster kommunizieren
Bei Gruppenservern verhindern feste Wartungszeiten, dass Spieler während Save oder Restart überrascht werden. Besonders bei automatischen Updates sollte eine Vorwarnung oder ein vereinbartes Zeitfenster existieren.