Direct answer

A staging server is a separate environment where you can test updates and configuration changes using representative worlds and plugins before publishing them to players.

Recommended procedure

  1. Stop production or use a consistent snapshot mechanism to copy the world, plugin configs and matching JARs to a separate staging directory.
  2. Use a different port and isolated networking. Do not expose a copied authentication configuration, credentials or plugin API keys.
  3. Ensure staging never writes to the same database, player-data store, backup path or world folder as production.
  4. Run smoke tests: start logs, connect as a test player, teleport, access permissions, write/save data and profile a realistic load if needed.
java -version
/spark tps

Why this matters

If staging shares database credentials or storage with production, a “test” plugin or migration can alter live player data. Use separate credentials and services where possible.

How to verify the result

After changes pass staging, build a rollout checklist and take a fresh production backup. Compare production post-deploy logs and behavior with the staging results.

Version and compatibility notes

A host control panel may provide a clone feature, but check whether it actually isolates database connections and schedules. Be especially careful with online-mode and private player information.

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