Ownership, collaborators, and danger zone
Delegate operations, transfer accountability, and distinguish wipe from deletion before an irreversible action.
Ownership, collaborators, transfer, wipe, and delete are available in v0.2.0-beta.8, where operator-role users can also run them on servers they don’t own. From v0.3.0, transferring ownership, editing collaborators, wiping data and deleting a server need the server’s owner or an admin. Servers with no recorded owner (for example created with kubectl or GitOps) can then be transferred, wiped or deleted only by an admin.
Ownership controls accountability and destructive authority; collaboration grants operator access to one server. Both require explicit owner decisions before irreversible actions like data wiping and server deletion.
Owner and collaborator access
Ownership controls accountability and destructive authority; collaboration grants operator access to one server.
- Owner can transfer and perform destructive actions — The owner has the highest level of control, including the ability to change who owns the server, wipe all world data, and delete the entire GameServer resource along with its persistent volume.
- Collaborators operate this server but cannot delete or transfer it — Collaborators can start, stop, restart, and clone the server, access the console (RCON or PTY), manage files, view players and logs, and upload mods. They cannot delete the server, transfer ownership, or modify the collaborator list.
- Add exact usernames and remove stale access promptly — Use the Access tab in server settings to grant collaborator access by typing exact usernames. Remove collaborators who no longer need access to keep the server’s access list current.
Transfer ownership
Select an existing user who accepts the server’s data and operational obligations, then verify every downstream access path.
- Confirm current and new owner in the transfer dialog — The dashboard shows the current owner during transfer and requires explicit acknowledgment from the new owner’s account (via a separate confirmation).
- Former owner needs explicit collaborator access to retain control — If a former owner should keep operating the server after transfer, they must be explicitly added as a collaborator in the new owner’s settings.
- Verify audit, backups, notifications, and on-call ownership after transfer — Transfer does not automatically update backup destinations, notification recipients, or on-call assignments. Update these manually in the new owner’s namespace if they differ.
Wipe world or delete server
Wipe keeps configuration and resets world data; Delete removes the GameServer, workload, and data volume.
Both operations require a verified backup and an explicit owner decision:
- Wipe data — Suspends the server, empties the persistent volume (retaining configuration and game templates), and restarts the server with a clean world. Use this when you want to reset the game world but keep your server’s name, settings, and template configuration.
- Delete server — Removes the entire GameServer Kubernetes resource, stops the workload pod, and deletes the data PersistentVolumeClaim (PVC). All game data, configuration, and deployment state are destroyed. Use this only when you no longer need the server.
DESTRUCTIVE ACTION
Next guide: Backup destinations