Star Rupture Server Requirements and Performance
The current official setup article does not publish a fixed Star Rupture dedicated-server hardware table. The old 8 GB/16 GB charts and exact player-by-player numbers were too precise to present as requirements. Early Access performance depends on build, players, world state, factory activity, and the machine running the process.
Practical sizing rule
Start with a modern fast CPU, SSD storage, and enough memory for the operating system plus the server and its saves/backups. Test the actual world with the largest expected group before calling a plan sufficient.
What changes the load?
| Workload | Why it matters | Measure |
|---|---|---|
| More players | More replicated state and simultaneous actions. | Tick delay, CPU, network loss, join stability. |
| Large factories | Production, conveyors, and construction differ from a fresh world. | CPU during peak production and building/deconstruction. |
| Long-running saves | World state affects save, restart, and backup work. | Save duration, disk latency, free space, restore time. |
| Updates | Early Access builds can change performance and save behavior. | Before/after comparison on a copy. |
Choose hardware without fake precision
- CPU: prioritize strong per-core performance and avoid oversold shared CPU.
- Memory: leave headroom for OS, logs, backups, and the world; use observed peak memory.
- Storage: SSD/NVMe helps startup, saves, and backups but will not repair a CPU bottleneck.
- Network: stable routing and a reachable endpoint matter more than a headline Mbps number for small co-op.
- Isolation: avoid unrelated heavy jobs during play and backup windows.
Measure before upgrading
- Record CPU, memory, disk, warnings, and player count during a quiet session.
- Repeat while the factory is producing and the group is connected.
- Compare a fresh test world with the established save.
- Change one variable and repeat.
- Keep the pre-change backup around updates and config edits.
Symptoms and next checks
| Symptom | First checks |
|---|---|
| Everyone sees delay | Process CPU, logs, packet loss, and swapping. |
| One player lags | That player's route, client performance, and region distance. |
| Base activity lags | Reproduce around production/building and compare with a lighter area. |
| Restart is slow | Save size, disk latency, backup jobs, and free disk. |
For persistent availability, compare hosting options and the safe setup workflow. See current Supercraft resources and pricing.