Direct answer
Pinning a Minecraft server version means choosing a tested build deliberately rather than automatically installing every new release on production. Pinning is temporary risk management, not a reason to ignore security patches.
Recommended procedure
- Record the exact server software, Minecraft version, build identifier, Java major version and critical plugin/mod versions in an administrator-only change log.
- Keep the verified server JAR or a trusted source URL plus checksum in a protected artifact store; do not use generic “latest” download URLs for unattended production updates.
- Monitor release notes and known security issues, and schedule a tested update when a fix is needed.
- For each proposed build, test startup, plugin dependencies, world load, permissions and player connection in staging.
java -version
# Record exact server JAR build and checksum in the private change log
Why this matters
Pinning preserves reproducibility but can leave vulnerabilities unresolved if the team never revisits the choice. Pair a pinned production version with an explicit review/update schedule.
How to verify the result
After each planned rollout, verify the live build and Java runtime agree with the recorded release checklist; keep the immediately previous full backup for rollback.
Version and compatibility notes
Server build naming and update channels differ by Paper, Purpur, Folia, mod loaders and proxies. Only promote builds that your stack supports.
Official references
Related guides
Help us improve this article
Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.