LuckPerms: Setting Up Ranks and Permissions Properly

LuckPerms decides who is allowed to do what on a Minecraft server, and it works with four building blocks: users, groups, permission nodes and contexts. The rule of thumb is to put permissions on groups rather than on individual players, and to let groups inherit from one another so that every node lives in exactly one place. A setup with five ranks (default, member, vip, moderator and admin) takes very little time to build in the web editor, and when something does not work you will almost always find the cause with /lp user <name> info and /lp user <name> permission check <node>.

How is LuckPerms structured?

A permission is nothing more than a line of text, a node, that a plugin checks before it does anything. If someone asks EssentialsX for /home, EssentialsX looks at whether that player has essentials.home set to true. LuckPerms is the record keeper that supplies the answer: every plugin decides for itself which nodes it recognises, and LuckPerms only decides who holds them.

You manage two kinds of holder. A user is a player, stored internally by UUID so that a name change breaks nothing. A group is a collection of nodes that you drop users into. Everyone who joins is automatically in default; that group cannot be deleted and is the place for everything that genuinely applies to everyone.

Two things are worth getting right immediately: weight and meta. Weight determines the order in a conflict and the sorting in the tab list (/lp group vip setweight 20). Meta covers everything that is not a yes-or-no answer, such as a prefix: /lp group vip meta setprefix 20 "&6[VIP] &f". That prefix only shows up in chat through a chat plugin, usually EssentialsX Chat with Vault.

What is inheritance and why does it save you hours?

Inheritance means a group has another group as its parent and takes over everything from it. You set it with /lp group vip parent add member. If you later decide every paying member should get /back, you add that node once in the right group instead of separately in four groups.

Two rules apply in a conflict. A node set directly on a group beats the same node arriving through a parent. If two parents disagree, the parent with the highest weight wins. That is how you claw something back selectively: /lp group vip permission set essentials.tpahere false removes that command from vip even though it is enabled in member.

The downside is that mistakes travel too. Put something dangerous in default and your entire server has it within a second. So test changes to default with a second account.

What does a working rank setup look like?

The structure below works for most survival and SMP servers, whether you are just starting out with our guide on making a Minecraft server or tidying up an existing setup. Moderator deliberately inherits from default rather than vip, so that donor perks do not automatically land on your staff.

Those nodes come from EssentialsX, CoreProtect and WorldEdit; which ones you need depends on your plugins, so see our overview of the best Minecraft plugins. Here is how you build vip from scratch:

1. /lp creategroup vip
2. /lp group vip parent add member — vip gets everything from member, and through member everything from default as well.
3. /lp group vip setweight 20 — higher than member, lower than moderator.
4. /lp group vip permission set essentials.nick true — repeat per node.
5. /lp group vip meta setprefix 20 "&6[VIP] &f"
6. /lp user Steve parent add vip, or parent set vip to replace his existing groups.

Tracks: promoting without thinking about it

A track is an ordered ladder of groups. Create one with /lp createtrack player and fill it using /lp track player append default, then append member and append vip. After that you move someone up a rung with /lp user Steve promote player and back down with demote, without having to remember which group comes next. Playtime and donation plugins call exactly that. Keep staff ranks off that track: you do not want someone sliding from vip into moderator.

What are contexts and when do you need them?

A context is a condition under which a permission applies; in practice you will use world and server. With /lp group builder permission set worldedit.* true world=creative that group can use WorldEdit in your creative world and nowhere else. With server=lobby you limit a node to a single server within a network.

Two things have to be right for that: every backend server needs its own name in the server: setting of the config, and all servers must share the same database. On a single server with one world you do not need contexts at all; only reach for them when you really have to, because they make debugging harder.

Why should you never give anyone *?

The node * grants everything, including nodes from plugins you will not install until next month and nodes that were only ever meant as exceptions. Think of bypass permissions that let someone build straight through WorldGuard regions, of /lp itself, which lets them grant themselves even more, and of commands that stop the server or wipe half a world with a single WorldEdit selection. One compromised moderator account is then all it takes to lose your map.

The same goes for op: with many plugins, operators skip the permission check entirely, which means LuckPerms can no longer protect you at all. So the rule is to deop everyone, yourself included, and arrange everything through groups. Do make sure you can always reach the console as a back door; in the Pterodactyl panel that comes as standard with Minecraft hosting at MC-Node it sits right there in your browser. If you want broad access as the owner, hand out a per-plugin wildcard such as worldedit.*, with CoreProtect alongside it to undo mistakes.

Is the web editor worth it?

Yes, it is by far the biggest time saver LuckPerms offers. Type /lp editor in the console or in chat, open the link you get back, and you will see your whole permission structure as an editable overview: groups side by side, nodes to tick or drag, and parents, weights and contexts in the same view. Click Apply and you get an /lp applyedits <code> command back to paste into the server; nothing changes until you do. Spreading fifty nodes across five groups takes a couple of minutes this way instead of half an hour of typing.

Two warnings. The link is a secret URL pointing at your permission data, so do not paste it into a public Discord channel. And do not work from two tabs at once, because you will overwrite your own changes. For a backup, use /lp export backup, which writes a file into the LuckPerms folder that you can restore with /lp import.

How do you debug a permission that will not work?

Work from the top down and you will usually have it within four steps.

1. /lp user Steve info — shows the primary group, all parents, the prefix and the nodes set directly on the player. Most of the time the mistake is already here: the player is in a different group than you assumed.
2. /lp user Steve permission check essentials.home — gives you not only true or false, but also where that value comes from.
3. /lp verbose on — you see live which nodes are genuinely being checked the moment someone tries the command, including typos and nodes that are named differently than you assumed. Switch it off again with /lp verbose off: on a busy server it is a waterfall.
4. If the node is correct and it still does not work, look outside LuckPerms: is the player op, is a WorldGuard flag in the way, or does the plugin have its own switch in its config?

The classics this turns up: a second permission plugin still running, a false higher up the chain, a forgotten context, and a node that was renamed in a newer plugin version.

Where do you find a plugin's nodes?

Almost every plugin documents its permissions in three places: the project wiki, the download page on SpigotMC or Modrinth, and the file plugin.yml inside the jar. That last one is the most reliable source when the documentation lags behind: a jar is simply a zip file, so you can open it and read plugin.yml, which lists the commands, their node and the default value. Dynamically built nodes such as essentials.sethome.multiple.<group> are not in there; for those you need the documentation or /lp verbose.

Frequently asked questions

Does LuckPerms only work on Paper and Spigot? No. Alongside Bukkit, Spigot, Paper and Purpur, LuckPerms is also released for Fabric, Forge and NeoForge, Sponge and for the proxies Velocity and BungeeCord. It works on a modpack server too, although mods tend to document their permissions less tidily and some fall back on op status entirely.

Do I need Vault alongside LuckPerms? Not for LuckPerms itself. Vault is the glue layer other plugins use to read your ranks and prefixes, for instance a chat plugin that puts [VIP] in front of your name. If your prefix shows up nowhere, what is usually missing is Vault or a chat plugin, not the permission.

Where does LuckPerms store my ranks? By default in a file-based database in the plugins/LuckPerms folder, which is perfectly fine for a single server. If you run several servers behind a proxy, move LuckPerms to MySQL or MariaDB so all servers read the same data and a promotion applies everywhere at once.

Does LuckPerms cost performance? Barely; a permission check is answered from memory. If you do see lag, measure where it comes from with spark first rather than fiddling with your permissions; our article on optimising your Minecraft server explains how to go about that.

Can I migrate from an older permission plugin? Yes, LuckPerms has migration commands for predecessors such as GroupManager and PermissionsEx. Afterwards, genuinely remove the old plugin: two permission plugins running at once produces unpredictable results and is one of the hardest faults to trace.

Further reading

• WorldEdit and WorldGuard: Build and Protect on Your Server
• CoreProtect: Roll Back Griefing and See Who Did What
• Setting up an RLCraft server: hardcore survival, no surprises