Star Rupture Admin Commands and Server Controls
The current official dedicated-server article explains installation and launch, but it does not publish a complete command list. A long table of /kick, /ban, /tp, or /save examples is therefore unsafe: those commands may belong to another game or an older experiment.
What is safe to claim
- The dedicated-server feature is experimental.
- The current package or manager is the source of truth for exposed admin controls.
- Administrative changes should be tested privately and recorded with the build.
Admin workflow without invented syntax
- Set a private password and restrict access before testing.
- Use the current manager or server console to identify the available control surface.
- Grant the smallest permission that lets a helper do their job.
- Test a harmless operation with a second account.
- Record the exact command or UI action and server build.
- Back up the world before destructive actions or experiments.
Moderation checklist
| Need | First response |
|---|---|
| Keep strangers out | Use the current access/password controls; do not publish the endpoint. |
| Remove a disruptive player | Use the control exposed by the current manager/console and test reconnect. |
| Change world rules | Back up, change one supported setting, restart, and test. |
| Recover after a crash | Capture logs, confirm the selected save, and restore only after checking the active path. |
Why copied command lists fail
Unverified lists often assume a different executable, config file, or server framework. If a command is not shown by the current package, manager, or an official article, label it unconfirmed rather than presenting it as a supported Star Rupture API.
Related guides
- Configuration and supported-setting checks
- Dedicated-server setup
- Backups before admin changes
- Connection troubleshooting
Need access controls and restart tools in one panel? Host Star Rupture with Supercraft.