B
BlackSpigot Guides
Guest
An update is ready when your server's ordinary gameplay works on it, and you know how to return to the previous state.
1. Write down the baseline
Record the server build, Java runtime used by the startup command, plugin versions and resource-pack version. Choose a few actions that matter to your players: joining, changing worlds, using an essential command, opening a custom menu and interacting with a custom mob. Record the expected results.
2. Make a recoverable copy
Stop the server cleanly for a consistent file copy, or use your host's documented consistent-backup procedure. Keep the worlds, plugin JARs, plugin data and server configuration together. Include external databases in the same recovery plan. Store the backup separately and test restoration into an isolated directory.
3. Test away from production
Use a separate port and private access. Prevent the test copy from sending production webhooks, processing purchases or writing to the production database. Change one planned component at a time. Read the startup log from the first error, then run the baseline actions.
4. Set a go/no-go point
Keep a small checklist: startup clean; player join; permissions; worlds; resource pack; custom mechanics; restart and persistence. A successful startup alone is not a pass. Note failed checks and keep their logs.
5. Publish and observe
Use a maintenance window. Never replace an active server JAR in place. If the update fails, stop it and restore the matching application, data and configuration backup; do not assume an older JAR can safely read newly migrated data.
Reply with your test checklist and the first failed step if you need help. Server update reference
1. Write down the baseline
Record the server build, Java runtime used by the startup command, plugin versions and resource-pack version. Choose a few actions that matter to your players: joining, changing worlds, using an essential command, opening a custom menu and interacting with a custom mob. Record the expected results.
2. Make a recoverable copy
Stop the server cleanly for a consistent file copy, or use your host's documented consistent-backup procedure. Keep the worlds, plugin JARs, plugin data and server configuration together. Include external databases in the same recovery plan. Store the backup separately and test restoration into an isolated directory.
3. Test away from production
Use a separate port and private access. Prevent the test copy from sending production webhooks, processing purchases or writing to the production database. Change one planned component at a time. Read the startup log from the first error, then run the baseline actions.
4. Set a go/no-go point
Keep a small checklist: startup clean; player join; permissions; worlds; resource pack; custom mechanics; restart and persistence. A successful startup alone is not a pass. Note failed checks and keep their logs.
5. Publish and observe
Use a maintenance window. Never replace an active server JAR in place. If the update fails, stop it and restore the matching application, data and configuration backup; do not assume an older JAR can safely read newly migrated data.
Reply with your test checklist and the first failed step if you need help. Server update reference