Booster roles
Give every booster a personal colour role they create, style, icon and share themselves.
A booster role is one role that belongs to one booster. They pick its colour, its name and its icon, and they do it without asking staff. Where autorole hands the same role to everybody who joins, this hands a different role to every member boosting the server. Staff run one setup command and then stay out of it.
Two gates stack here, and the difference matters. The whole command needs
Server Premium, staff setup included: without it nothing
under ,boosterrole (aliases ,boostrole and ,br, or /boosterrole, default ,) answers at
all. Five subcommands additionally need you to be boosting the server right now: style,
icon, rename, mentionable and random. Creating or recolouring needs it too.
,br info deliberately does not: a lapsed
booster can still look at what they had, they just cannot change it. The bot needs Manage
Roles, and its own highest role must sit above the base role.
Set the base role: the one setup step
,br baserole set (Manage Roles) is the
whole of setup.
Syntax
,br baserole <set|remove> <role>
Example
,br baserole set @Community
The base role is a position anchor, not a role anyone is ever given. Every booster role is created one slot below it, so the whole band lands in a predictable place in the role list without staff hand-placing each one. Pick a role that already sits where you want that band to start.
Without it, most of the command refuses with Invalid Base Role
Creating, recolouring, style, icon, rename, mentionable and random all read the anchor
before doing anything, and so does offering your role to a member. The two read-and-switch halves
of share do not: share on, share off and share status never touch the anchor, so they answer
normally in a server that was never set up: a moderator can switch sharing on today and only find
out at the first actual request that there is nothing to hang a role under. The refusal names the
base role, not the missing setup step, so a server where nobody ever ran baserole set looks broken
rather than unconfigured.
baserole remove deletes every booster role in the server
It does not just forget the anchor. It clears the anchor first, then walks every booster role in the server, deletes each one from Discord, and clears the rows: a role somebody already deleted by hand is skipped rather than stopping the sweep, so the pass always finishes. The word "remove" does not suggest any of that, and there is no undo. Members lose the roles they built.
Create and recolour a role
There is no color keyword on the prefix form: the hex goes straight after the command.
Syntax
,br <hex> [hex2]
Example
,br #fd9864
The first run creates the role, names it after you, places it under the anchor and gives it to you.
Every run after that recolours the role you already have: same command, no separate edit. A colour
can be a six-digit hex, a three-digit hex, or a name like red. A second hex makes it a
gradient; give one hex to a role that is already a gradient and only the primary is repainted.
,br random does the same with a colour
picked for you, useful for a first role when you do not care yet.
Syntax
,br random
Creating is refused if you already hold a coloured role above the anchor: a booster role sits in its own band, not above a staff colour somebody placed on purpose.
Switch between solid, gradient and holographic
,br style changes the shape of the
colour without asking for new hex values: solid flattens to one colour and clears the extra slots,
gradient blends two, holographic writes Discord's own fixed holographic set.
Syntax
,br style <solid|gradient|holographic>
Example
,br style gradient
gradient on a role that has never had a second colour derives one for you, from the colour you
already have, and tells you it did. Refine it with a second hex if the guess is wrong.
Gradient and holographic need enhanced role colours
A second hex, style gradient and style holographic all need the server to have the perk
unlocked. Without it the bot refuses before it calls Discord at all: "This server doesn't have
Gradient & Holographic Role Colors unlocked — that's a Server Boost perk." Solid colours are
unaffected.
Put an icon on the role
Syntax
,br icon <emote|attachment|reset>
Example
,br icon :sparkles:
| Input | Means | Accepts |
|---|---|---|
| A custom emote | Uses that emote | Emotes this server owns, one pasted from elsewhere is refused |
| A unicode emoji | Uses the emoji itself | Any single emoji, skin tones and flags included |
| An attachment | Uploads an image | PNG, JPEG or WEBP, up to 256KB. GIFs are refused, role icons are static |
reset (or r) | Clears the icon | None |
,br icon always clears the other kind of
icon as it sets one, so an emoji replaces an uploaded image cleanly. Around 64×64 is plenty.
Icons need Role Icons unlocked
The bot checks the server before uploading anything and says so plainly: "This server doesn't have Role Icons unlocked — that's a Server Boost level 2 perk."
Rename it, and decide whether it can be pinged
Syntax
,br rename <name>
Example
,br rename midnight
,br rename changes the name only:
position, colour and icon all stay.
Syntax
/boosterrole mentionable
,br mentionable (aliases pingable,
ping, mention) is a toggle: it flips whatever the role is on now. There is nothing to pass
it, which is why the slash form is cleaner here. See Common issues for the prefix form's quirk.
Share your role with up to three people
Sharing is off until a moderator turns it on, because it hands a real Discord role to somebody who is not boosting. Both halves live on both surfaces: the prefix form takes a word, the slash form takes named options.
Syntax
,br share <on|off|status>
Example
,br share on
Syntax
/boosterrole share [member] [setting]
Example
/boosterrole share setting:On
,br share on needs Manage Roles, and so
does the setting: option that mirrors it. status is read-only: whether sharing is on, how many
slots you have used, and who holds your role. Naming a member instead posts a request that pings them
with Accept and Deny buttons: only they can answer it, and nothing happens to your role
until they do.
Syntax
,br share <@member>
Example
,br share @friend
The slash form deliberately makes both options optional, because the command genuinely has two audiences: a moderator flipping a server switch has no member to name, and a booster offering their role has no setting to pick. So it enforces the rule itself rather than in Discord's picker: give it one of the two. Bare, it asks you to name either a member or a setting; with both at once, it tells you one at a time.
| Rule | Value |
|---|---|
| Slots per booster | 3 members at a time |
| Cooldown between requests | 120 seconds, spent when the request is sent |
| Request expiry | 2 minutes, then the buttons go dead |
| Who can receive | Someone with no booster role of their own and no share already |
Accepting re-checks everything against live state: sharing still on, you still boosting, the role still there, the slot still free. Two minutes is long enough for any of those to change. A member who leaves never costs you a slot: only members still present count against the three.
Syntax
,br unshare [@member|all]
Example
,br unshare @friend
Syntax
/boosterrole unshare [member] [all]
Example
/boosterrole unshare
,br unshare has two directions. Naming a
member (or an ID, which still works for somebody who has left) removes that person from your
role, and all (the all:True option on slash) clears every share at once. Run bare, with no
argument at all, it is the recipient's form: it drops a share somebody gave you and leaves your own
role alone.
That is why a bare /boosterrole unshare is a valid command while a bare /boosterrole share is
not: one of them means something specific, and the other would be a guess. A booster who holds no
share and runs it bare gets told to name a member or use all; it will not pick a recipient for you.
Look at what exists
Syntax
,br info
,br info shows your own role: colours,
derived style, position, whether it is mentionable, and how many share slots are used. If you are
wearing somebody else's shared role instead of owning one, it names whose.
,br list (Manage Roles) is the staff view:
every booster role in the server and who owns it, paginated.
Syntax
,br delete [member]
Example
,br delete
,br delete with no argument deletes your
own role; naming someone else deletes theirs, and that half needs Manage Roles: without it the
command falls back to deleting your own.
,br reset (Manage Roles) deletes every
booster role in the server but keeps the base role, so members can start again immediately. That
is the difference between it and baserole remove, which takes the anchor with it.
When a boost ends, the role goes with it
A booster role is deleted (not kept, not archived) the moment its owner stops boosting, and the same happens if they leave the server. Anyone it was shared with loses it in the same instant, because the role and its shares are one thing. The reverse direction is handled too: delete a booster role by hand in Discord and the bot forgets it; delete the base role by hand and the anchor clears itself, putting the server back to needing setup.
A perk that outlived the boost would not be a perk.
Common issues
Everything answers "Invalid Base Role". Nobody has run ,br baserole set <role>. The message
names the base role rather than the missing setup step, so it reads like a bug in a server that was
simply never configured.
"Bot Needs Higher Hierarchy" or "Bot Role needs to be higher". Move the bot's own role above the base role in Server Settings. The bot cannot create or edit a role that outranks it, and the check runs before every action rather than failing halfway through one.
"Higher Color Role Hierarchy" when creating a role. You already hold a coloured role above the anchor, so a new booster role would be invisible beneath it. Move or drop that colour first.
,br mentionable answers with the syntax help. The prefix form expects a word after it even
though it ignores what the word is: ,br mentionable on toggles exactly as ,br mentionable off
does. /boosterrole mentionable has no such quirk.
Sharing says it is not enabled. It is off by default. A moderator with Manage Roles turns it on
with ,br share on or /boosterrole share setting:On; nobody can share until they do.
/boosterrole share answers by asking for a member or a setting. Both of its options are
optional so that a moderator and a booster can each fill in only their half, so a bare run has
nothing to act on. Name a member to make a request, or pick a setting to switch the feature. Bare
/boosterrole unshare is the one that is meaningful on its own.
Someone's booster role disappeared with no warning. They stopped boosting, or they left. Both delete the role outright, and the colour and icon are not stored anywhere, so boosting again means building it from scratch. See what a lapse takes with it.
Nothing here fixed it. The shared common issues page works the same ground from the symptom end.