StarRupture Dedicated Server Autoload Save On Restart

StarRupture Dedicated Server: Autoload Save On Restart

One of the most common complaints about StarRupture dedicated servers in Early Access is that they do not automatically load your save after a restart. If the server process crashes, if the host machine reboots, or if the hosting panel cycles the service, the server comes back up serving a blank Arcadia-7 map. Players who join see a fresh world and assume everything was wiped. This guide explains the exact DSSettings.txt flags that fix the problem, plus the startup-script pattern that keeps the save loaded across crashes and kernel restarts.

Why the Default Server Ignores Your Save

StarRupture's dedicated server tooling ships with settings tuned for a first-time launch rather than for steady-state hosting. Out of the box, the DSSettings.txt file contains StartNewGame=true. That flag tells the server to create a new world every time it starts. If the previous save existed at the same name, it is quietly overwritten. If the flag is not explicitly flipped, your first crash or reboot destroys your base.

On top of that, the server GUI ("Manage Server") has a manual Load Game button that must be clicked after connecting to a running server. The button selects a save file and boots the map. If nobody clicks it, the server sits idle on a blank map, which is why players who join see an empty world even though the process is healthy. Neither the flag nor the Manage Server button remembers its state across a restart, which is what produces the complaint that "the server wipes every reboot".

The fix is to configure the server to skip the Manage Server step entirely and boot straight into your save. It is a single flag flip plus an explicit save name, but the default value catches almost every new admin.

Symptom Fingerprint

• Players reconnect after a reboot and see a completely fresh Arcadia-7 map.
• Your save folder (/StarRupture/Saved/SaveGames/<SessionName>/) still contains .sav files with recent timestamps.
• Server log shows LogStarRupture: Starting new game session instead of Loading save.
• Opening Manage Server and clicking Load Game restores the correct save, confirming it is not actually lost.
• The problem reoccurs on the next crash or restart.

The Core Fix: DSSettings.txt Flags

Open /StarRupture/Saved/Config/<Platform>/DSSettings.txt on your server. Find or add the following lines:

[Session]
SessionName=MainCrew
StartNewGame=false
SaveGameName=MainWorld
LoadMostRecentSave=true

What each flag does:

• SessionName - identifies the save directory on disk. Choose a stable name for your crew and never change it, otherwise the server starts looking in a different folder.
• StartNewGame - the critical flag. Set to false so the server does not wipe the save on boot.
• SaveGameName - the specific save file to load. Match it to the file in SaveGames/<SessionName>/, without the .sav extension.
• LoadMostRecentSave - if set to true, the server will fall back to the most recently modified save if the named one is missing or unreadable. Useful during testing; leave it on true by default.

Restart the server after saving the file. The log should now contain a line like LogStarRupture: Loading save "MainWorld" (SessionName=MainCrew) early in startup. If you still see Starting new game session, double-check the file path (Windows hosts use WindowsServer, Linux via Proton uses LinuxServer), and ensure the save file exists under the correct SessionName.

Watchdog Script for Crash Recovery

Even with the right flags, the server process can crash - Early Access is Early Access - and some hosting panels will not auto-restart binary processes that exit non-zero. A simple watchdog wrapper guards against this. Here is a Linux-friendly example that also writes a rolling log:

#!/bin/bash
set -euo pipefail
SERVER_DIR="/home/starrupture/server"
LOG_DIR="/home/starrupture/logs"
BINARY="StarRuptureServer"
mkdir -p "$LOG_DIR"
cd "$SERVER_DIR"
while true; do
    TS=$(date -u +%Y-%m-%dT%H-%M-%SZ)
    ./"$BINARY" -log -server \
        > "$LOG_DIR/server-$TS.log" 2>&1 || true
    echo "$(date -u): server exited, restarting in 10s" \
        >> "$LOG_DIR/watchdog.log"
    sleep 10
done

Save as run-server.sh, mark it executable, and register it as a systemd service (or an equivalent supervisor on your OS). On crash, the script waits 10 seconds - long enough for EOS to forget the stale session - and then restarts with the same config. As long as the DSSettings.txt flags are correct, the restart will automatically reload your save.

On Windows, achieve the same pattern with NSSM (Non-Sucking Service Manager) or with a PowerShell loop that wraps the binary. The principle is identical: keep the process running, do not interfere with the save-loading path, and let the DSSettings.txt flags do their job.

Recovering From a Broken Save

Sometimes the most recent save itself is broken - a crash during save, corrupted state, or a mod that left the world in an inconsistent shape. In that case, the server may refuse to finish loading and will either hang or bail out. The recovery pattern:

1. Stop the server cleanly.
2. Navigate to SaveGames/<SessionName>/ and list the .sav files. You should see MainWorld.sav, AutoSave1.sav, AutoSave2.sav, AutoSave3.sav, and possibly more.
3. Edit DSSettings.txt and change SaveGameName from MainWorld to AutoSave1.
4. Start the server. If it boots, your autosave is healthy. Play briefly, then stop the server and rename the working save back to MainWorld.sav.
5. If AutoSave1 is also broken, step through AutoSave2, AutoSave3, then backups from your hosting provider's daily snapshot if available.

This recovery flow saved several Supercraft-hosted crews during the Update 1 rollout, when a handful of saves were left in an inconsistent state by the deconstruction crash that the patch fixed. Keeping the DSSettings.txt editable - and not locked behind a panel that only exposes "start" and "stop" - is what makes this recovery possible.

Supercraft Panel Integration

Supercraft's StarRupture plan applies these flags at install time. New deployments ship with StartNewGame=false already set, the session name bound to the customer's selected crew name, and a systemd watchdog that restarts the process on crash. Admins still see the full DSSettings.txt file in the panel's config editor and can tune any flag, but the dangerous defaults do not bite because Supercraft's provisioning script flips them before the server first boots.

If you are self-hosting and want to mirror the behaviour locally, copy the four-line config block from earlier in this article and wrap the process in the watchdog script. That gets you most of the way to a production-grade setup. Add a daily rsync or rclone of the SaveGames folder to off-host storage and you have survived every common failure mode that an Early Access server produces.

Decision Table

FAQ

Next Steps

• Save file management reference
• DSSettings.txt full configuration guide
• SaveSync host migration

Sources

• Steam Discussions - Dedicated Server thread with Manage Server workflow complaints
• Steam Discussions - "Dedicated Server Keeps Crashing"
• Steam Discussions - "It doesn't save the game"
• SteamDB - UPDATE 1 patch notes April 9, 2026