# Set up SuperVanish for a limited staff role

SuperVanish lets authorised staff hide from ordinary players. Treat it as a moderation tool, not a security boundary or a guarantee that every third-party plugin conceals every trace. Test the actual chat, tab list, map and gameplay integrations your server uses. Keep an ordinary-player test account available after each integration update.

## Install without changing existing staff access

Check the supported server and Minecraft releases in the official project. Review integrations listed for your installed build, including any optional ProtocolLib functionality. Do not assume the requirements of an old tutorial still match the current release.

Stop the server, take a completed backup and keep the current staff permission configuration. Upload the compatible JAR through Files or SFTP, keeping one copy in `plugins/`. Start and inspect Console. If the plugin fails to enable, investigate that startup error before granting additional permissions.

## Separate who can vanish from who can see staff

The plugin declares `sv.use` for ordinary vanish use and `sv.see` for seeing vanished players. Grant only the permissions needed by a named staff role. Avoid `sv.*`: it includes administrative capabilities and behaviour changes that a junior moderator may not need.

Using LuckPerms Console commands, a limited example for an existing moderator group is:

```
lp group moderator permission set sv.use true
```

Confirm the group name before running it. Decide separately which senior role should have `sv.see`. Existing inheritance or operator status can already grant visibility, so test with accounts whose effective permissions you understand.

## Check behaviour with three accounts

1. Join as the authorised moderator and run `/sv` in Minecraft chat. Read the feedback instead of assuming the command succeeded.
2. From an ordinary player account, check the tab list, nearby entities, join or leave announcements and public player lists.
3. From the intended senior staff account, confirm whether visibility matches your policy.
4. Review the generated configuration for join-vanished, notifications and interaction rules. Change one setting at a time and test again.

Commands entered through the game panel Console omit the leading slash, but toggling your own player visibility is most clearly tested in-game. Do not use another player's account or share panel credentials to perform these checks.

## Review integration leaks and interaction risks

A web map, placeholder, Discord bridge or separate player-list plugin may have its own visibility rules. Check their documented SuperVanish integrations rather than assuming the vanish plugin controls them all. Be explicit with staff about which interactions they may perform while hidden; moderation visibility should not accidentally alter player builds or inventories.

If a staff member becomes visible unexpectedly, record the time, world switch or reconnect, effective permissions and related plugin versions. Restore the prior configuration if a change caused it. See [LuckPerms groups](https://help.cloudexa-hosting.com/books/game-hosting/page/create-minecraft-ranks-and-inheritance-with-luckperms) and [ProtocolLib diagnosis](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/install-protocollib-and-diagnose-dependent-plugin-failures). Further reading: [official project](https://github.com/LeonMangler/SuperVanish), [permissions](https://github.com/LeonMangler/SuperVanish/blob/master/src/main/resources/plugin.yml) and [configuration](https://github.com/LeonMangler/SuperVanish/blob/master/src/main/resources/config.yml).

Looking for another plugin? [Browse the Minecraft plugin guide directory](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/find-a-minecraft-plugin-setup-or-troubleshooting-guide).