How to Set Up Permission-Based Ranks with LuckPerms

If your staff somehow have permissions they shouldn't and new players can barely move, the fix isn't another round of one-off grants — it's a deliberate rank ladder. Most people install LuckPerms, make a couple of groups, hand out a few nodes, and end up with a tangle nobody can read a month later. A ladder you've thought through means each tier earns more access than the one below it, and you only ever grant a permission once.

The mental model is short: in LuckPerms everything is a group, every player automatically inherits a group called default, and a clean ladder is just groups stacked on top of each other through inheritance. Once that clicks, the commands are easy.

One factual note before we start: this assumes you already run a server and own the base game. Everything here is access control — what a rank can do — and the ranks are earned through playtime or trust, or assigned to staff you pick. Nothing here is something you sell.

What a permission rank actually is in LuckPerms

A group is a named bundle of permissions, plus a prefix and a weight, that any number of players can be added to. When you put a player in the admin group, they get everything that group holds. That's the whole idea, and it's why you manage groups instead of editing players one at a time.

The default group is special: every user inherits it automatically, whether you do anything or not. So default is where baseline player permissions belong — the things literally everyone on the server can do, like chat and basic movement commands. You don't add a player to default; they're already in it.

Start by laying out the earned player ladder, since that's the one most of your community will move through — something like default to member to trusted that players climb by playing. Your staff chain (helper to moderator to admin) is the thing you keep deliberately separate, because you assign it by hand and you don't want it tangled into the player ladder. Keep the two apart so a trusted player never accidentally picks up a moderator's kick command. Mixing the chains is where permission bleed comes from.

Creating your groups

You make a group with /lp creategroup <name>. So for a small ladder:

/lp creategroup member
/lp creategroup moderator
/lp creategroup admin

You don't create default — it already exists, you just edit it for baseline permissions. Name groups in lowercase with no spaces, because you'll be typing them into commands constantly and a space will break things. Pick a small number of tiers to start with, three or four, rather than ten you'll never keep straight. You can always add a rung later.

Run /lp listgroups whenever you want to see everything you've made and sanity-check that the ladder looks the way you think it does.

Building the ladder with inheritance

This is the part that does the heavy lifting. The command is /lp group <child> parent add <parent>, and it makes the child group inherit everything the parent has.

There's one distinction here that trips people up: parent add accumulates parents, stacking them, while parent set replaces all existing parents with a single one. You want add to build a chain. Wire it like this:

/lp group member parent add default
/lp group moderator parent add member
/lp group admin parent add moderator

Now admin inherits moderator, which inherits member, which inherits default — so an admin has everything below them without you granting any of it twice. That's the payoff: you grant a new permission at the lowest tier that should have it, and every tier above gets it for free. No duplication, and no drifting out of sync.

If you wire something wrong, undo it with /lp group <child> parent remove <parent>.

The one caution: don't make your player progression groups inherit staff groups, or the reverse. Keep the two chains separate. If trusted ever inherits moderator, every trusted player on the server quietly gets moderator commands, and you won't notice until someone uses one.

Adding prefixes so ranks show in chat

A prefix is set through meta: /lp group <group> meta setprefix <weight> "<prefix>". For example:

/lp group admin meta setprefix 100 "&c[Admin] &r"

The weight here matters and it's easy to misread. Meta weight is separate from a group's weight — when a player belongs to several groups, the prefix that displays is the one with the highest meta weight, not the one from their highest rank. So give admin a bigger number than member, otherwise a player who's in both could end up showing the member tag. That mismatch is the usual cause of "why is my admin showing the wrong prefix."

Color codes use & — &c is red, &a is green, &r resets back to normal. On most setups, actually rendering that formatting in chat needs a chat plugin that reads LuckPerms meta; LuckPerms stores the prefix, the chat plugin draws it.

To check what's actually applying, run /lp user <name> meta info. It lists every prefix, suffix, and meta value the player has and inherits, ordered by weight, so you can see exactly which one wins. Suffixes work identically through meta setsuffix if you want a trailing tag.

Granting command permissions per tier

You grant a permission node with /lp group <group> permission set <node> true. Setting it to false doesn't just remove it — it's an explicit deny, which is useful when you want to claw back something a group inherited.

It helps to think of three states. true is allowed. false is explicitly denied. undefined is not set at all, which usually behaves as denied. The reason false exists separately is so you can override an inherited true deliberately rather than hoping it just isn't there.

Grant at the right tier and let inheritance carry it up. General moderation nodes go on moderator; admin inherits them, so you don't re-add anything. Only the genuinely admin-only nodes — config edits, restarts — get added at the admin tier.

Wildcards are a trailing *, which grants everything under a prefix, like worldedit.*. One verified behavior makes these safer than they look: an explicit non-wildcard node overrides a wildcard. So you can grant essentials.* and then set a single dangerous sub-node to false to carve it back out, and the specific false wins over the broad *.

What you should not do is hand a bare * to anyone but a real owner account. That grants every permission on the entire server, including the ones that can wipe a world or rewrite core config. There's no reason a moderator needs it.

When you don't know the exact node a command checks, don't guess — find it. Run /lp verbose on <player>, have that player try the command, then /lp verbose paste. That generates a report showing which node was checked and whether a group granted it. It reports what the plugin actually checks on your version, which is more reliable than reading a wiki page that might be out of date.

Promotion and demotion with tracks

A track is a promotion route: an ordered list of groups that lets you move a player up or down with one command. Worth being clear on this, because it's a common mix-up — tracks do not affect inheritance at all. They don't grant anything. They only define the path.

You set one up like this:

/lp createtrack progression
/lp track progression append member
/lp track progression append trusted
/lp track progression append veteran

Then /lp user <name> promote progression bumps the player to the next group on the track and removes them from the old one, and /lp user <name> demote progression moves them back down. Because it swaps groups rather than adding, the player stays in exactly one progression group at a time, which keeps things tidy.

This is what makes earned progression painless. A staff member, or a playtime or voting automation, runs a single promote command instead of manually adding the new group and remembering to remove the old one. Tracks are worth setting up for the earned player ladder; staff promotions are better kept manual, so a track there is optional.

Editing faster with the web editor and saving your work

When chat commands get tedious, run /lp editor. It opens a session in your browser with a visual interface for groups, inheritance, prefixes, and nodes, and you apply the changes back to the server when you're done. For bulk restructuring it's far faster than typing.

For auditing, /lp group <group> info and /lp user <name> info show what a group or player actually holds right now. LuckPerms saves automatically to its storage, but back up that storage or config before a large restructure, just so you have a clean point to return to.

All of this is server-side. Players need no client mods — they just see the prefix and the access they've earned.

A sane starting ladder (worked example)

Here's a five-group setup that ties it together:

• default — baseline chat and movement, what everyone gets.
• member — earned after a first session, slightly more chat or warp access.
• trusted — claim and region perks for players who've stuck around.
• moderator — mute, kick, teleport, the moderation toolkit.
• admin — everything a moderator has plus server management.

And the wiring:

/lp group member parent add default
/lp group trusted parent add member
/lp group moderator parent add member
/lp group admin parent add moderator

Notice moderator branches off member rather than off trusted — staff and player ladders share the baseline but split above it, so a moderator doesn't inherit player-only region perks and a trusted player never inherits moderation. Add each permission once, at the lowest tier that should have it, and let inheritance carry it upward from there.

A tiered rank setup like this is one of the things that keeps active players coming back, and an active, well-moderated server tends to climb the monthly board. If you want the full picture of what that climb depends on, here's how the rankings and voting work, and the live survival server rankings are a good place to see communities running ladders like this.

FAQ

Does a player need to relog for a rank change to take effect?

Usually not. LuckPerms applies group changes, promotions, and permission edits live, so a player gets the new access without leaving. The thing that often looks like a rank that "didn't apply" is a prefix or a feature handled by another plugin that only reads permissions on join — chat formatting is the common one. If the access works but the tag is stale, that's the chat plugin catching up, and a relog refreshes it.

Where does LuckPerms keep all this, and can I move it between servers?

By default it stores everything in a flat file inside the LuckPerms plugin folder, but you can point it at a database like MySQL instead. That database option is the real reason to bother: if you run several servers and want one player to carry the same rank everywhere, you put them all on the same shared storage rather than rebuilding groups on each box. Either way, copy that storage when you back up — it's the whole permission setup in one place.

What happens to a player's groups if I delete a group they're partway up a track?

Deleting a group removes it from any user who had it and from any track it sat on, so a player sitting in that group simply loses it and drops to whatever they still inherit. The track keeps working with the remaining groups, but a future promote or demote skips the gap you left, which can surprise you later. If you're reshaping a ladder, it's cleaner to move players off a group first, then delete it, so nobody is left mid-rung.

Can I give a single player a permission without putting them in a group?

Yes. /lp user <name> permission set <node> true grants a node straight to one player, and it works the same way group nodes do, including the explicit false deny. It's fine for a one-off, like letting one trusted builder use a specific command. But if you find yourself doing it for more than a person or two, that's a sign the access belongs in a group instead — per-player grants are exactly the tangle a ladder is meant to replace.