Upgrade Checklist
1.0 Private Server Upgrade Checklist
This is not a guaranteed template, but an operation sequence to reduce the risk of server explosion and data damage.
minimum process
Backup → Stop the service → Save a copy of the settings → Upgrade → Verify → Keep the rollback.
Data layer anchor point
| Hierarchy | content | border |
|---|---|---|
| Confirm information | The current version of the official server docs is 0.7.2; the configuration table includes RESTAPIEnabled and RESTAPIPort. REST API is the officially supported server management port. | The docs will be upgraded after 1.0 goes online; 1.0 server fields cannot be claimed before the upgrade. |
| Strategy inference | 1.0 is a major version update, and private server upgrades involve the superimposed risk of changes in setting fields, changes in Global Palbox switch default values, and complete Mod failure; it should be executed according to "Backup first, then upgrade, Mod deactivation and re-verification". | Applicable to dedicated servers and host mode; not applicable to official servers. Counterexample: If the 1.0 server field is fully backwards compatible, only the Mod risk holds. |
Before upgrade (backup four-piece set)
Upgrading
Verification (five small server verifications)
rollback
Acceptance criteria
| Status | Can the server be opened? | Reason |
|---|---|---|
| Only complete backup | It cannot be opened to the outside world. | This only means that it can be rolled back, and it has not yet been verified that players can play it. |
| Login to naked server successfully | Only suitable for small-scale testing. | Mod, Palbox, cross-platform and base information have not yet been verified. |
| All checked and completed | Player acceptance can be entered. | Still need to keep a list of rollback points and known issues. |
Incident handling: character information disappeared/required to seriously injure the character
After upgrading, if the player logs into the server and sees "Create New Character", or the character level, backpack, and Palbox are reset to zero, the first principle isSave the scene first and then troubleshoot. Doing it in the wrong order (create corner first, retry first) will make salvageable data unsalvageable.
| order | action | why |
|---|---|---|
| 1 | Stop the server immediately and stop all players from writing. | If the half-written state continues to operate, the damage surface will only expand. |
| 2 | Don't create new roles. | The new character profile may overwrite the old player profile, which is the most common secondary damage. |
| 3 | Completely copy the current archive directory and save the accident scene. | All subsequent investigations will be done on the copy, and the official information will remain frozen. |
| 4 | Check on the dungeon whether the player file and the world file are complete or misaligned. | "The file exists but has not been read" and "the file is damaged" are two problems with different processing paths. |
| 5 | If the cause cannot be located, roll back to the four-piece backup set before the upgrade. | Bottom line for rollback: It’s better to lose a small amount of progress after the upgrade than to gamble on an unknown fix. |
Other bottom lines
| situation | bottom line |
|---|---|
| Set generator output | It can only be used as a draft; after going online, you still need to check the parameter names and default values according to official documents or actual measurements. |
| Player acceptance | Five things must be looked at: real-person login, base work, save file placement, exit and re-entry, and long-term operation. |
Applicable versionP1 route contract / P2 v2.0 content layer
Updated
SourceSPEC A5 / Official Server Documentation Baseline / A5 wiki Boundary Card
UpstreamConOps current focus: Palworld P2 content-layer rebuild