Direct answer
A staging test should exercise gameplay, authentication, data persistence and a clean recovery path before the first public announcement.
Step-by-step procedure
- Restore a production-like copy to an isolated test instance with distinct ports and database credentials.
- Join with a normal account and check spawn, whitelist, permissions, economy and protections without relying on OP exemptions.
- Test plugin commands, world saving, player relogging, planned restart and a representative high-load location while collecting MSPT.
- Run a backup and restore test; verify that the staging system can return to its previous state after a deliberately failed update.
Common mistakes and trade-offs
Do not point staging and production at the same writable world directory or SQL tables. Avoid sharing real player secrets in public bug reports.
How to verify it worked
Write a pass/fail checklist with dates, Minecraft/server versions and test-account results; do not publish until critical failures have been resolved.
Version and platform differences
A feature that loads without console errors may still fail under multi-player use, proxy switching or Folia scheduling.
Official references
These sources were checked for the current MSH revision. Version-sensitive details should always be confirmed against the project documentation for the release you run.
Related guides
Help us improve this article
Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.