Minecraft Version Update Checklist for Anticheat Servers

Stage the new version before the live server moves

Run the new Minecraft or Paper build on a copy of your live server before production. Clone the world and configuration, confirm every anticheat dependency supports the target release, run an alert-only period with known-legitimate testers, and keep a rollback path you have tested. Promote the update only after the staging gate passes.

This checklist does not assume any anticheat supports a given version. Read each project's release notes for the exact build you plan to run.

Clone the world and configuration first

Stop the live server or pause writes before copying. Keep the copy with a date and the exact Paper build and plugin jar versions in its name or in a notes file. A copy you cannot identify later is not a rollback point.

Copy the whole server directory, including the world folders for the overworld, nether, and end, plus the plugin folders and their configuration. Do not rely on a single world backup.

save-off
save-all flush
# copy the server directory now, for example:
# rsync -a /srv/mc/ /srv/mc-backup-2026-11-07/
save-on

Check release notes for every dependency

An anticheat can depend on more than the server jar. Build a short inventory and check each item against its release notes or documentation before you install anything. Record the version you tested, not the latest version on a download page.

Run an alert-only staging period

Turn on the new build with punishments disabled. Alerts still show what the checks see, so you can compare behavior without enforcement. Use the same settings as production except the punishment and mitigation switches.

Compare alert volume against a baseline from your current live build, using the same kind of play. A number copied from a product page or forum post does not tell you what your players will trigger.

• Snapshot alert counts per check on the current live build for one normal peak period.
• Run the new build on staging with the same settings except punishments.
• Have known-legitimate testers play combat, building, and movement routines for a fixed time.
• Include at least one Bedrock or high-latency test account if your network has those players.
• Export the alert counts per check and compare them with the baseline.
• Have a staff reviewer read a sample of alerts from each check that rose, and record whether each was a true or false positive.

Scan the startup log for errors

Plugin load failures often appear only in the console or latest log. Search the log after every restart, not only the first one. Treat any new exception that names an anticheat, PacketEvents, or a protocol bridge as a blocker.

grep -nE 'ERROR|Exception|Caused by' logs/latest.log | head -n 50

Write the rollback plan before the upgrade

Decide how you will return to the previous build before you start. Assume a world saved by a newer build may not load on an older one. Restore from the pre-upgrade copy instead of downgrading in place, and test the restore on staging once.

• Keep the previous server jar and every previous plugin jar in a dated folder.
• Keep the pre-upgrade world copy until the new build has run in production for an agreed period.
• Write the restore steps in order, with the owner of each step.
• Restore the copy on a second staging server and confirm the server starts and the anticheat loads.
• Set a time limit. If the agreed gate fails by that time, roll back and record why.

Promote only after the gate passes

Promote the build when all of these are true: the server starts with no new anticheat or bridge errors, the alert review found no unexplained spikes, the rollback restore has been tested, and staff know the punishment settings for production.

What we have not verified

This article does not test any Minecraft release, Paper build, or anticheat version combination. It does not state which versions FairPlay or any other plugin supports. Check the current release notes and your own staging results before making claims to players or staff.