The one rule that decides everything
Permissions belong to groups. Players belong to groups. Players do not get permissions. Nearly every unmanageable permissions setup started when someone was in a hurry and granted one node directly to one player, and then did it again. Six months later there are forty such grants, no record of why any of them exist, and no way to reason about what a rank can do — because the rank is no longer the answer.
Hold that line and LuckPerms stays comprehensible at any size. Break it and no amount of tooling saves you.
Build the ladder first
Before installing anything, write down your ranks in order and what each one *adds*. Not what it can do in total — what it adds relative to the rank below. That distinction is the whole point of inheritance: each group only declares its own increment, and inherits everything beneath it.
- default — what a brand-new player who just joined can do. This group already exists; every player is in it.
- member — inherits default. Whatever you unlock after a player is verified, has played an hour, or has been whitelisted.
- vip — inherits member. The donor or reward tier, adding only its own perks.
- moderator — inherits member (not vip, unless you mean it). Adds moderation tools.
- admin — inherits moderator. Adds administrative tools.
Note that moderator inherits *member*, not *vip*. Inheritance is a graph you design, not a single line — a staff ladder and a donor ladder are usually two separate branches that both start from member. Getting this right at the start is what stops you accidentally handing every moderator the cosmetic perks people paid for.
The commands worth knowing
| Create a group | `/lp creategroup <name>` |
| Give a group a permission | `/lp group <group> permission set <node> true` |
| Explicitly deny a permission | `/lp group <group> permission set <node> false` |
| Set up inheritance | `/lp group <group> parent add <parentgroup>` |
| Put a player in a group | `/lp user <player> parent add <group>` |
| Inspect what a player has | `/lp user <player> info` |
| Open the web editor | `/lp editor` |
The distinction between `true` and `false` matters more than it looks. Unset means "inherit whatever the parent says". Setting `false` is an explicit denial that overrides inheritance — useful for carving one capability out of an inherited group, and a common source of confusion when someone cannot work out why an admin lacks a permission they clearly granted higher up.
Use the web editor
Running `/lp editor` produces a link to a browser interface showing your whole permission structure — every group, every inheritance relationship, every node — which you edit and then apply back to the server in one operation. For anything beyond a single node change this is faster and much less error-prone than chaining commands, and it is the only practical way to *see* your inheritance graph rather than holding it in your head. Treat the command line as the tool for quick fixes and the editor as the tool for actual structure.
Network setups
On a single server, file storage is fine. On a network behind a proxy, point every backend and the proxy at a shared database instead. Permissions then live in one place and changes are visible everywhere, which is what you want the first time someone is promoted on the hub and finds their rank missing on survival.
The failure mode to watch is inconsistency: one server on local files while the rest share a database is genuinely confusing to debug, because everything works except one machine. Configure them the same way at the same time.
Mistakes that cost you later
- Wildcard nodes on staff groups. Granting a blanket wildcard means every plugin you install in future silently hands that group its permissions too, including ones you would not have granted deliberately.
- Per-player grants. Covered above, and worth repeating — it is the single most common way permission setups rot.
- Flat structure. Ten groups that each list every permission from scratch means ten places to edit when one thing changes. Inheritance exists precisely to prevent this.
- No backups. Back up your permissions data alongside your world. Rebuilding a rank structure from memory is miserable.
- Assuming permissions are security. They govern what a logged-in player may do. They do not govern who reaches your server in the first place.
Permissions are not protection
That last point deserves its own paragraph, because it is a real gap. LuckPerms decides what an authenticated player is allowed to do once they are on your server. It has nothing to say about ten thousand bots opening connections, about a booted client hammering your login flow, or about someone who scraped your backend IP connecting around your proxy. Those are handled before the game logic runs at all — by filtering at the edge and by protecting the connection path itself. A perfectly configured permissions tree on an unprotected server is a well-organised building with no front door.
Common questions
How do I set up LuckPerms for the first time?+
Drop the jar in your plugins folder and restart, then build a group ladder before you touch any individual player: create your groups, give each one only the permissions that tier adds, make each higher group inherit from the one below, and assign players to groups. The default group already exists and is what every new player gets, so start by deciding what a brand-new player is allowed to do.
What is the difference between a group and a track in LuckPerms?+
A group is a bundle of permissions that players belong to. A track is an ordered list of groups that defines a promotion path — for example default → member → vip → vip+. Tracks let you promote and demote along that ladder with a single command instead of remembering which group comes next, which matters once you have more than a handful of ranks.
Should I give permissions to players or to groups?+
To groups, essentially always. A permission set directly on a player is invisible from the group structure, so six months later nobody can explain why one person can do something nobody else can. The rare legitimate exception is a genuinely one-off grant that will never apply to anyone else — and even then, most admins are better served by making a small group for it.
Does LuckPerms work across a BungeeCord or Velocity network?+
Yes, and this is one of its main advantages. Point every server and the proxy at a shared database rather than local file storage and permissions become network-wide, with changes propagating between servers. Configure it on all backends and the proxy consistently, or you get the confusing situation where a rank works on one server and not another.
How do I find out which permission node a command needs?+
Check the plugin's own documentation first — most list their nodes. If that fails, LuckPerms can verify what a player currently has with a permission check command, which tells you whether a node is granted and where it came from. The web editor is often the fastest way to see the whole resolved picture for a user rather than guessing node by node.
Permissions sorted? Close the other gap. Start free with Arvoris — antibot, L4/L7 mitigation and real player IPs on every plan, so your IP bans land on the right address.