Match this symptom
A dashboard or script depends on RCON, disconnects unpredictably, or requires the administrator to forward a management port to the public Internet.
The answer first
Remove public forwarding for RCON and REST, keep in-game commands as the safe fallback, and migrate one read-only operation at a time to authenticated REST on a trusted LAN. Do not retire the old path until save and shutdown have passed a copied-world test.
Treat deprecation as an operational risk, not an outage
Pocketpair says RCON is deprecated and planned to stop functioning in an upcoming update. That means a new product should not add deeper dependencies, but it also should not replace a working control path with an untested REST workflow during live play.
Before migration, record which actions the current integration performs, which credentials it uses and how it confirms success. Back up the world and active settings so a failed shutdown experiment cannot become the recovery test.
- Inventory player listing, broadcast, kick/ban, save and shutdown separately.
- Rotate any credential that was stored in a command line, screenshot or plain-text support bundle.
- Retain documented in-game commands as the maintenance fallback.
Keep both management interfaces off the public Internet
The REST examples use HTTP and Basic Authentication. Authentication does not turn a service into a safe public endpoint; Pocketpair warns that the management interfaces are not designed for direct Internet exposure.
Bind or firewall REST to the host/trusted LAN, reach it through a private management path, and never list its port in the player forwarding table. The only ordinary public join rule is the configured UDP player port.
- 1Remove router mappings for legacy RCON and REST.
- 2Allow the REST port only from the local manager/service identity or trusted management subnet.
- 3Confirm that an outside network cannot reach the management endpoint before testing commands.
Migrate from observation to mutation
Start with the REST server-info and player-list operations because they do not change the world. Compare status, player identifiers and error handling with the running server. Then test broadcast and moderation against consenting test accounts.
Save and shutdown are the final migration gates. Run them on a copied test world, wait for the documented response, confirm process exit and restart into the expected state before enabling the buttons in a production UI.
- 1Verify authenticated server information on the trusted LAN.
- 2Verify player-list semantics without inventing names for missing identities.
- 3Test one broadcast and one reversible moderation action.
- 4Test REST save, then a countdown shutdown, followed by world-integrity verification.
Make failures honest and recoverable
An HTTP timeout is not proof that a save failed, and a 2xx response is not proof that the disk write completed. Log the endpoint, status category and server build without logging Basic Authentication credentials, then confirm state through server logs and a restart test.
When REST is unavailable, tell the operator the action did not receive reliable confirmation. Do not silently fall back to killing PalServer.exe; use the documented in-game /Save and /Shutdown workflow instead.
- Redact Authorization headers and administrator passwords.
- Distinguish request accepted, process exited and world verified.
- Keep RCON disabled once every required REST/fallback path has a dated pass result.