Direct answer

Operator access gives broad built-in server control. Assign it only to trusted administrators and use a permission plugin for limited staff roles instead of making every moderator an OP.

Recommended procedure

  1. Run op <username> from the server console only for a verified administrator account.
  2. Use deop <username> promptly when access is no longer required; check the effective identity and UUID when changing authentication or proxy modes.
  3. Keep online-mode=true on a standalone authenticated Java server; secure proxy forwarding and backend access on networks.
  4. Set up a permission manager such as LuckPerms for commands that can be delegated narrowly.
  5. Review console and staff action logs after changes and verify unauthorized users cannot run administration commands.

Why this matters

An OP can bypass important restrictions and often override plugin controls. A whitelist is not a privilege boundary, and turning off account authentication exposes permissions to impersonation risks.

Practical example: Example: a moderator who needs to teleport players does not need unrestricted OP just for that task. Assign the documented permission nodes in a manager and test from a separate moderator account. If a staff member leaves, remove both OP and any plugin permissions, then audit proxy and panel credentials as well.

How to verify the result

  • Use a non-OP test account to confirm restricted commands are denied.
  • Confirm an administrator can perform the exact maintenance tasks they need.
  • Revoke access and rotate relevant credentials if an account may be compromised.

Version and compatibility notes

  • ops.json stores trusted identities and should be backed up and protected from accidental edits.
  • Do not paste all staff permission nodes into a global wildcard without understanding consequences.

Related topic: How to Separate Player and Administrator Responsibilities. Compare the two guides when choosing the right diagnostic or configuration step.

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.

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