Updating Paper: When to Reopen or Restore Your Server
Reopen a Paper server after an update only when the agreed player workflows pass, the installed versions match the tested release, and a named operator accepts any remaining limitations. Decide the recovery deadline before maintenance starts. A server that accepts connections can still have broken permissions, missing plugin data or an unusable community feature.
This guide gives established community owners a release decision they can use with their technical team or a commissioned operator. It covers planned Paper and plugin updates. It is a proposed procedure, not a report of tests performed by Mineando, and it does not establish compatibility for any particular plugin.
Define one change that you can review
Write a short change record: current Minecraft version, Paper build, Java runtime, plugin versions, target versions, reason for updating and maintenance owner. Include dependencies and external storage used by critical plugins. Avoid a target described only as “latest”: another build may appear between rehearsal and deployment.
Separate a Paper build update within the same Minecraft version from a Minecraft version upgrade. Both need checks, but the second can involve a broader compatibility review. If a dependency forces several components to change together, treat them as one documented release. Leave unrelated tuning and new features for another change.
Check the target runtime against Paper's Java version table. It currently lists Java 21 for Minecraft 1.20–1.21.11 and Java 25 for 26.1+. Record the actual runtime used by the service, not just the Java version in an administrator's terminal.
For every essential plugin, record the maintainer's compatibility statement and release notes for the proposed version. Mark missing evidence as unknown. A download page remaining accessible is not evidence that a plugin supports your target combination.
Set the decision deadline backwards from reopening
Reserve time for recovery and verification before you allocate time to troubleshooting. Use this planning rule:
Latest recovery decision = planned reopening time − rehearsed recovery duration − verification allowance − contingency.
Suppose, purely as an example, reopening is planned for 20:00, a representative recovery rehearsal took 25 minutes, verification needs 15 minutes and the team reserves 10 minutes of contingency. The recovery decision belongs at 19:10. Those durations are invented planning inputs, not benchmarks or a Mineando availability promise.
At the deadline, an unresolved blocking check means either start the agreed recovery or explicitly extend maintenance. Do not silently spend the recovery reserve trying one more configuration change. Tell the community how the next status update will be communicated, and name the person who can change the reopening plan.
If you have never restored this environment, the recovery duration is unknown. Complete an isolated backup restore rehearsal before relying on a tight maintenance window. This article uses that result; it does not replace the recovery procedure.
Rehearse the exact candidate on a separate copy
Prepare a copy with representative worlds and plugin data. Restrict access to testers and prevent it from writing to production databases, webhooks or other live integrations. Record anything disabled for isolation so it cannot accidentally be marked as tested.
Run the candidate release, including the intended configuration changes, against that copy. Keep the software manifest and results together. If you change a plugin after the rehearsal, repeat the affected checks and their dependencies; yesterday's result does not approve today's different candidate.
Paper's update guide warns against replacing active JARs and recommends watching the logs during updates. For this maintenance plan, use a controlled shutdown and restart, with an operator present. Keep the tested candidate files separate from the preserved recovery set.
Do not start by applying every possible improvement. First establish whether the proposed release works. If a failure requires a broader redesign, take it out of the maintenance window and revise the plan.
Test community workflows, not just startup
Agree the checks with the people who operate those features. Select a small set that would actually block reopening:
| Check | Evidence required before reopening |
|---|---|
| Normal player joins | Expected identity, inventory and location are retained |
| Access control | Player is denied a staff action; moderator can perform the agreed task |
| Protected build | An unauthorized player cannot alter the selected protected area |
| Critical plugin workflow | A representative claim, score or registration can be read and changed correctly |
| Persistence | The controlled change survives a clean restart |
| External dependency | A controlled request reaches the intended system and its result is reconciled |
Use known expected values from the rehearsal copy. “Looks fine” is not a comparison. Record the account role, steps, expected result, actual result and evidence for each check. Leave a result as not run until someone has performed it.
Paper's plugin troubleshooting documentation identifies logs/latest.log as a starting point for load errors and describes missing dependencies. A plugin appearing enabled is only a loading check. It does not prove the workflows in your acceptance record.
Compare a representative gameplay session with your existing performance baseline under comparable conditions. Agree any blocking limits in advance. This procedure supplies no universal player count, tick-time result or guarantee that an update improves performance.
Preserve a coherent way back
Before changing production, restrict new activity, stop the server cleanly and coordinate other writers to shared state. Capture the recovery set using the supported backup methods for the actual storage systems. Identify the files, databases, versions and timestamp that belong together.
Ask each critical plugin maintainer how that release changes stored data and whether returning to the previous release is supported. Do not assume that putting the old JAR back reverses a database or configuration migration. Plan around restoring the preserved pre-change state unless a different recovery path has been documented and rehearsed.
Keep public access closed while completing the production acceptance checks. If you reopen and players create new progress, restoring the earlier state can discard that progress. A later recovery decision therefore needs a fresh assessment of data loss and any external actions already completed.
Make the release decision explicit
Use three outcomes: reopen, remain closed for a defined correction, or restore the agreed recovery set. Missing essential data, unexpected privileges and a failed critical workflow should block reopening. An optional cosmetic defect may be accepted only with an owner, documented impact and follow-up date.
After reopening, assign an observation period and an operator who can respond to the issues you have agreed to monitor. Record what happened, including failed checks and the final release manifest. Scheduled monitoring or live coverage must have an agreed scope; a successful rehearsal does not imply someone is available indefinitely.
For managed Minecraft infrastructure, bring the change record, critical workflows and acceptable maintenance window. Mineando scopes and quotes paid projects individually. Where the blocker is a custom plugin, include its update and recovery requirements in the development brief; ongoing maintenance and support are agreed separately.
