StarRupture Server Settings That Actually Make a Difference

The honest answer to "what are the best StarRupture server settings?" is that StarRupture has a refreshingly small number of settings to tune, and most of the performance work happens at the hardware level, not in DSSettings.txt. This post walks through the config keys that actually exist, how we recommend setting them, and where to put your effort if you want your server to run well – especially after Update 1 (9 April 2026) made worlds bigger.

This is written from the hosting side: the stuff we see in tickets from LOW.MS StarRupture customers, and the stuff that's actually made a difference for groups I've helped set up. Your mileage may vary.

What's actually in DSSettings.txt

StarRupture's dedicated server reads a single JSON file called DSSettings.txt from the server root (next to StarRuptureServerEOS.exe). As of Update 1, the supported keys are still:

{
  "SessionName": "YourServerName",
  "SaveGameInterval": "300",
  "StartNewGame": "false",
  "LoadSavedGame": "true",
  "SaveGameName": "AutoSave0.sav"
}

If you see random guides claiming support for MaxPlayers, DifficultyLevel, TickRate, PvPEnabled or similar – ignore them. Those keys don't exist in the real server. The dedicated server tooling is still flagged experimental by the devs and the config surface is genuinely small.

SessionName

Choose something you'll recognise in File Manager a month from now. Alphanumeric is safest – some builds have been picky about special characters. Your save folder lives under /StarRupture/Saved/SaveGames/<SessionName>/, so if you swap the name you effectively get a fresh world; swap it back and the old one reappears.

SaveGameInterval (the one that actually matters)

Autosave frequency in seconds, passed as a string. "300" is 5 minutes. This is the one value you'll probably want to change based on how your group plays:

• Casual 2–4 players, mixed activity: "300". Default-sensible.
• Heavy builders, complex factories: "180". More protection against losing a session's worth of work if the server crashes. The save spike is barely noticeable on a modern CPU.
• Long exploration runs: "600". Fewer save spikes, a bit more tension per run.

If you find yourself chasing save spikes below the 3-minute mark, the problem is probably RAM or CPU, not the save interval.

StartNewGame / LoadSavedGame

These are a pair. Stable state – the one you want 99% of the time once your world exists – is StartNewGame=false, LoadSavedGame=true. If you leave StartNewGame=true after the first boot you will nuke your world on every restart. This is the single most common support ticket for StarRupture.

SaveGameName

The autosave file to load on boot. Normally AutoSave0.sav. If a recent save looks corrupted, flipping to AutoSave1.sav or AutoSave2.sav is a zero-cost recovery attempt.

Hardware is where the real tuning happens

StarRupture's simulation is overwhelmingly dependent on hardware rather than configuration. The game ticks the conveyor belt network, creature AI, and environmental systems on a single main thread, which means you can't "add more cores" your way out of a factory lag problem. You make it faster by giving the server a better single-thread CPU, and you make it more stable by giving it more RAM.

RAM

Rough guide based on what we see on LOW.MS:

Check the RAM graph in your LOW.MS control panel. If you're consistently above 80% of your allocation, you're overdue for a bump. Post-Update-1 bases are meaningfully larger than EA-launch ones, so don't be surprised if an existing 10 GB server needs to step up to 15 GB once you start using the new zones and higher-tier buildings.

CPU

StarRupture's main-thread load scales with conveyor belt count and mob density. The LOW.MS Premium CPU upgrade puts you on a guaranteed Ryzen 7950X or 9950X, which materially improves tick rate on heavy bases. It's overkill for a two-person casual save, worth the money on a full 4-player factory group.

Disk

10 GB of SSD ships as standard and is plenty. StarRupture saves are small – you're not going to fill that.

Ports and network

UDP port 7777 handles the game traffic. There's a separate query port allocated per server – on LOW.MS it's shown in your control panel alongside the game port, and you should just use whatever the panel tells you. Hardcoding a specific query port number in guides gets out of date quickly, so the safest advice is always "use the one your panel gives you".

A Dedicated IP (+£5/mo) gets you guaranteed default ports and a unique IP, which is a nice quality-of-life upgrade for a private group that cares about a clean connection string. Not a necessity for most customers – shared IPs work fine.

What actually causes "my server is laggy"

Ordered by what we fix most often:

1. RAM pressure at 80%+ – bump the plan. This is the #1 cause by a mile.
2. Over-frequent autosaves (SaveGameInterval below ~180) – extend it.
3. A specific factory area with a big multi-line conveyor mess – known EA bug, simpler single-lane layouts are more reliable.
4. Single-thread CPU bottleneck on a 4-player factory base – upgrade to Premium CPU.
5. Missing restarts – if the server has been up for a week and nobody's restarted it, a lot of EA crashes are just accumulated state. Schedule a nightly restart in the Scheduled Tasks panel section.

Restart schedules

Honestly underrated. Head to Scheduled Tasks in your control panel and set a nightly restart during your group's off-hours. Updates apply, memory clears, and any weird half-stuck states get reset. It's a one-minute setup that prevents a lot of future tickets.

Update 1 considerations

Update 1 landed on 9 April 2026 and it does make worlds noticeably heavier – a bigger map, new higher-tier buildings, more resources, more recipes – without changing the dedicated server's config format. What this means for tuning:

• If your existing server was comfortably running on 10 GB pre-Update-1, it may start to feel tight as you explore the new zones and rebuild with the new Tier 2 buildings. The first thing to try is a RAM bump.
• The new ziplines and Development Station don't have any server-side tuning knobs as far as we can tell.
• Nothing in Update 1 changes DSSettings.txt. Your existing config carries over untouched.

Worked examples

Reference configs for three common group types.

Casual duo, relaxed evenings. Default 10 GB RAM, standard CPU, shared IP. SaveGameInterval at "300". Nothing fancy. This is about 80% of our StarRupture customers.

Four-player factory group, regular sessions. 15–20 GB RAM, Premium CPU, shared or dedicated IP depending on whether you like a clean connection string. SaveGameInterval at "180" to keep autosave intervals short enough to protect against the occasional mid-session crash.

Long-running exploration group, low churn. 10–15 GB RAM, standard CPU, shared IP. SaveGameInterval at "600" for less disk activity. The bigger post-Update-1 map makes this group type more viable than it was.

For a price, pick whatever combination you want on /game-servers/starrupture-server-hosting – we don't lock any of this behind tiers beyond the RAM / CPU / IP add-ons.

Related reading

• Getting Started with your StarRupture server – the first-run Manage Server flow
• DSSettings.txt Configuration Guide – per-key reference
• Managing saves
• Troubleshooting