Appearance
Hosted requests
A community on a plan with hosted servers asks for a server that RustyThrones runs for it. Hosted requests is the inbox where the operator or a platform admin approves it (the server is then created in the community) or rejects it with a reason. Capability: operations. A badge on the sidebar entry counts the requests waiting.
How requests arrive
Hosted servers are currently available by request. The community fills the form described in Hosted servers: a Server name (up to 64 characters), a Size and optional Notes (up to 1,000 characters).
| Size | RAM reserved | Slots |
|---|---|---|
| Small | 6 GB | 50 players |
| Medium | 8 GB | 100 players |
| Large | 12 GB | 200 players |
Before a request is accepted the platform checks that the plan includes the Hosted servers feature, that the community has a free hosted slot, that billing is not restricted, that the name is not used by another server or request, and that the community has fewer than 3 open requests and fewer than 5 requests in 24 hours.
The inbox
Requests are listed oldest first. Each row shows the server name, the size chip, the phase chip, the community (name and address), the date, and the community's notes. A line "Last attempt failed: message" appears when an approval failed.
| Phase | Meaning |
|---|---|
| Requested - pending review | Waiting for a decision. Only these rows have actions. |
| Provisioning | Approved; the server is being created (see Jobs). |
| Ready | The server exists. |
| Declined | Rejected, with a reason. |
| Failed / Removed | The server could not be created or was removed afterwards. |
Approve
- Click Approve... on a pending row.
- Choose Placement: Automatic (VM scheduler) or a named VM (see VMs).
- Click Approve and provision.
The platform creates the server inside the requesting community with the requested size (memory and player slots), a generated RCON password and the community's name for it, and starts the provisioning job. Community owners and admins are emailed. The request leaves the pending list ("Provisioning name").
Rules:
- Placement is required. Automatic placement needs the VM scheduler to be enabled and at least one VM; otherwise the dialog says to choose a VM.
- The plan is checked again: a community that lost the hosted feature cannot be approved.
- Provisioning never runs on the API host.
- If the creation fails (quota, port conflict, ...) the request returns to pending with the error shown; fix the cause and approve again.
- Two staff cannot approve the same request: the second sees "Request was just decided".
- A request stuck "approving" for 15 minutes without a server goes back to pending on its own (or is completed if the server did get created).
Reject
- Click Reject....
- Write the Reason (shown to the community; at least 3 characters, up to 500).
- Click Reject request. Owners and admins are emailed.
Troubleshooting
| Problem | Fix |
|---|---|
| "Hosted requests are switched off" | The platform mode for hosted servers is off. |
| "Automatic placement needs ... choose a VM" | Pick a VM by name, or enable the VM scheduler. |
| Request stays Provisioning | Open Jobs and look at the provisioning job; Retry it after fixing the VM. |
| Community says the card is disabled | Plan lacks hosted servers, or the slot is used: see Communities. |