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

  1. Record the exact server software, Minecraft version, build identifier, Java major version and critical plugin/mod versions in an administrator-only change log.
  2. 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.
  3. Monitor release notes and known security issues, and schedule a tested update when a fix is needed.
  4. 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

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000