Minecraft permissions plugin: ranks, prefixes and groups

Groups, permission nodes, prefixes, inheritance

Three separate things hide behind the word rank. A group sorts players into buckets: guest, member, VIP, mod, admin. A permission node is just a string that a plugin checks before it allows an action, something like myserver.kit.vip. A prefix is cosmetic only: it is what other players see in front of your name in chat or in the tab list. A player can have a shiny prefix and zero extra powers, and that is normal.

Inheritance wires the groups together. VIP inherits from member, mod inherits from VIP. You never retype the whole permission list at every level, you only add what the tier above gains. When two groups disagree, a weight decides the winner, and a node can be explicitly denied instead of simply missing. That denial mechanic is behind most of the confusion when a permission refuses to apply.

• Group: which rank a player belongs to
• Permission node: the string your code checks, like myplugin.command.use
• Prefix and suffix: display only, separate from real access
• Inheritance: a group automatically picks up the permissions of the tier below it
• Context: permissions that change per world or per server

LuckPerms is the standard, and often it is all you need

Straight answer first: if you want to create groups, hand them permissions, show a prefix and set up inheritance, LuckPerms already does that, and it does it better than something written from scratch for one server. It covers groups and per-player overrides, temporary permissions, per-world contexts, flat file or database storage, editing through in-game commands, and editing in a web editor. It also exposes an API that other plugins know how to talk to.

Cloning LuckPerms would be a waste of your time, and Minax has no reason to sell you that. Install it, create your groups, set the inheritance, and your hierarchy is done. The interesting question starts right after: what does your server actually do with those ranks?

• Groups, inheritance, weights, negated nodes: already solved
• Prefixes and suffixes as metadata, read by most chat plugins
• Temporary permissions and per-world contexts: already solved
• A stable API your own plugin can query

When a custom rank plugin is genuinely worth it

A permissions manager answers exactly one question: is this player allowed to do this? It does not answer the next one, which is the one you actually care about: when and why does a player move up a rank on my server, and what does that unlock for them? That part is your server logic, and no download contains it, because it belongs to you.

That is where writing a plugin pays off, and it is what Minax generates: a plugin that holds your rules and leans on LuckPerms or the Bukkit permissions API for the access checks. You replace nothing, you add the layer that was missing.

• Ranks that promote automatically on playtime, votes, or objectives you define
• Kits, extra homes or specific perks attached to each rank, with your numbers
• An in-game shop where a rank is bought with your server currency
• Chat format, tab list and join message that follow the rank, in your styling
• Temporary event ranks that expire on their own
• Staff commands built for your team, with your confirmations and your logging

Making your plugin work alongside LuckPerms

A well written plugin does not replace the permissions manager, it talks to it. In code, checking access is player.hasPermission(...), which belongs to the Bukkit API: LuckPerms answers behind it and your plugin never needs to know which manager is installed. To move a player between groups or read their prefix, your plugin goes through the LuckPerms API or through Vault, depending on what your server already runs.

Declare your nodes in plugin.yml with a sensible default too. A node left at default: op is true for every operator, which is where most of the "works for me but not for my players" reports come from. The habit that saves the most time is testing on an account without OP.

• Say in your description whether LuckPerms is installed, so the code hooks into it
• Pick a permission prefix that is yours, for example myserver.ranks.*
• Handle the player who has no rank at all, or you will get odd behaviour
• Vault is the bridge if you want to stay compatible with your current economy and chat

How to describe your rank plugin to Minax

The output tracks the quality of your description. Write it the way you would brief a friend who is going to code it for you, but leave nothing vague: your ranks in order, what each one gains, the command that grants it, the condition that triggers a promotion, and the exact chat messages players see, including the refusals.

Minax then writes the Java code, generates plugin.yml and pom.xml, compiles with Maven and reviews its own output. If the build breaks, it fixes and rebuilds itself in a self-correction loop. You get a .jar, you launch it on an online server and you check in game that /rank does what you meant before your real server sees it.

• List your ranks in order, with the prefix and colour of each
• Spell out the promotion condition: staff command, playtime, purchase, objective
• Name your commands, for example /rank, /ranks, /setrank
• Say which permissions come with each rank
• Write your chat messages word for word
• State your Minecraft version, your platform, and whether LuckPerms is present

Versions, platforms and testing before install

Minax compiles for Paper, Spigot, Bukkit and Folia, from Minecraft 1.12.2 to 26.2. Put the version and the platform in your description and the build targets the matching API. Before your real server is involved, you can start the plugin on an online Paper server, join it and run your rank commands for real. Only then does the file go into the /plugins folder, with a server restart. The source code stays yours: read it, edit it, have it recompiled.

Frequently asked questions