For Server Owners
Roles and permissions, without the headache.
Color coded roles, a clear permission model, and per-channel overrides. Powerful enough for fifty thousand members, simple enough for five. This page explains how the model actually works, and how to set yours up so it never gets in your way.
One model, three layers.
Roles decide who can do what. Overrides decide where. The owner sits above it all.
Most permission systems fail in one of two ways. Either they are so coarse that every helper becomes an all-powerful admin, or they are so intricate that nobody on your staff can predict what a change will do. We built ours around three layers you can hold in your head at once, and the role editor keeps them separate: how a role looks, what it can do, and who holds it are three different tabs, so changing one never accidentally changes another.
Roles are named bundles of abilities
A role couples a name, a look, and a set of permissions. Moderator might grant the ability to manage messages, move voice members, and edit channels. Supporter might grant nothing at all and exist purely as a color in the member list. Both are roles. Both are fine. The point is that you decide what each name means in your community, instead of inheriting somebody else's idea of what a moderator is.
Permissions add up, they never subtract
When a member holds several roles, their abilities are the union of everything those roles grant. Adding a role can only give; removing a role takes back exactly what that role gave and nothing more. This sounds like a small design choice, but it is the reason the system stays predictable at scale: you can reason about any single role in isolation, and you can build with several small, focused roles instead of one bloated one that you are afraid to touch.
Overrides are exceptions, written per channel
Role permissions apply across your whole server by default. Per-channel overrides let you carve out exceptions: lock a staff channel so only moderators can see it, or open a channel to everyone in a server that is otherwise restricted. The general rules apply everywhere, except where you say otherwise. Overrides are deliberately channel-shaped rather than a second permission system, so when you look at a channel you can answer the only question that matters there: who is in this room?
The owner stands above the ladder
The server owner always has full control. No combination of roles, permissions, or overrides can lock an owner out of their own server, and ownership never moves through a permission: handing a server over is a separate, deliberate, confirmed act by the current owner. That guarantee is what makes it safe to experiment with everything else on this page. Whatever you misconfigure, you can always get back in and fix it.
The pieces, at a glance.
Everything here lives in your server settings. No plugins, no external dashboard, nothing to install.
Granular permissions
Each role grants exactly the abilities it should: manage messages, move voice members, edit channels, and more. Nothing is all or nothing, so you never hand out more power than a job needs.
Colors and gradients
Give roles solid colors or gradients so staff and supporters stand out in the member list and in chat. A glance tells your members who is who, before anyone reads a word.
Per-channel overrides
The general rules apply everywhere, except where you say otherwise. Lock a channel to staff or open one to everyone, per channel, without rebuilding your role ladder.
Every change on the record
Role edits, permission grants, and channel changes land in the audit log with who did it and when. When something looks off, you check the record instead of interrogating your staff.
Status without power
A role does not have to grant anything. Supporters, event winners, and long-time regulars can carry a color or a gradient as pure recognition, with zero permissions attached.
The same model at any size
Five friends and a single server of 50k+ members use the exact same three layers. You never migrate to a different permission system as you grow; you just add rungs to the ladder.
From blank server to a working ladder.
Five steps. Do them in order, and do the sketch before you touch a single toggle.
Sketch the ladder before you open settings
Write down the tiers your community actually has, not the ones you imagine it might need someday. Most servers need three: everyone, a trusted circle, and staff. Every role you add later should answer a real question, like who cleans up spam at night or who runs events. If you cannot name the job, do not create the role.
Create the roles and give them a look
Name each role and pick a solid color or a gradient in the role editor. Make power visible: staff should be recognizable at a glance in the member list and in chat, because half of moderation is members knowing who to ping when something goes wrong.
Grant permissions, starting from nothing
Open the permissions tab and grant the least power that does the job. A helper who answers questions needs no permissions at all. Someone who tidies channels needs manage messages, not the ability to edit channels. Resist the urge to grant everything to save a future trip to settings; that trip is cheap, and an incident is not.
Add the channel overrides
Now carve the exceptions. Lock a staff channel so moderation talk stays private. Make an announcements channel everyone can read but only staff can post in. Overrides are where the ladder meets the floor plan, and a handful of them usually covers everything.
Assign members, then test the edges
Hand out the roles, then check the result from the other side: what does a brand-new member see, and what can a moderator actually do? The edges are where mistakes hide, like a staff channel that is visible to everyone or an announcements channel anyone can post in. Ten minutes of checking now saves an awkward cleanup later.
What roles govern, and what they never touch.
A permission model should have hard outer walls. Here are ours.
Roles decide
- Who can manage messages, pins, and cleanup in your channels
- Who can create, edit, and organize channels and categories
- Who can move and manage members in voice channels
- Who can use the moderation tools, from kicks to bans
- Which channels a member can see and post in, via overrides
Roles never touch
- Your direct messages, which stay private and outside every server
- Your other servers: every role is scoped to the server it was created in
- Your account: losing a role, or even being banned, never deletes anything you own
- The owner: no role, and no combination of roles, can lock an owner out
One rule of thumb covers most of it.
Grant the least power that does the job.
Start every role with the fewest permissions that let its members do their job, and add more when reality asks for it. Walking permissions back after an incident is much harder than granting them was: the member feels demoted, the community notices, and you end up litigating trust instead of adjusting a toggle. Granting late is a two-minute favor. Revoking early is a conversation nobody enjoys.
Separate status from power
The most common setup mistake is fusing recognition and authority into one role. A long-time supporter deserves a color; they do not automatically need manage messages. Keep cosmetic roles and power roles separate, and you can celebrate people freely without every celebration widening your attack surface. When someone earns real responsibility, that is its own decision, made on its own merits.
Prefer a locked room to a broad grant
When a small group needs a private space, lock a channel to their role instead of promoting them up the ladder. An override is scoped, visible, and trivially reversible. A server-wide permission follows the member into every channel you have, including the ones you were not thinking about when you granted it.
Let the quiet tools carry the load
Not every problem needs a person with power. Slow mode takes the heat out of a busy channel without anyone touching a role, and automated filters catch the obvious junk before a moderator ever sees it. The fewer judgment calls your permission ladder has to absorb, the smaller and calmer that ladder can be. The moderation tools page covers what runs on its own.
Review on a rhythm, not after a crisis
Once a month, read your role list and ask two questions: does every permission on every role still have a job, and does every member with a power role still do that job? Permission creep is silent, and the audit log makes the review honest, because it shows you what was actually changed and by whom rather than what everyone remembers. The moderation guide shows how roles, filters, and the audit log work together day to day.
Three servers, three ladders.
Copy the shape that matches your size today. You can add rungs later without rebuilding anything.
A private server for friends
Skip the ladder almost entirely. One cosmetic role for fun, one trusted person with moderation permissions so the server is never unattended when you are asleep, and per-server nicknames doing most of the personality work. Resist building bureaucracy for twelve people; you can always add structure the day you actually need it.
Servers for friend groupsA growing community
Three tiers: everyone, trusted regulars, and a small moderation team with manage messages and kick rights. Add a locked staff channel, slow mode on your busiest channel, and automated filters for the obvious junk. This shape comfortably absorbs growth from dozens to thousands of members without a redesign.
Read the moderation guideA large public server
Split staff into tiers so trainee moderators cannot ban, keep announcements read-only for everyone below staff, and hold a scheduled audit log review instead of hoping someone notices problems. At this size the ladder is policy, so write down what each role means and hold the line. Discoverable servers live and die on this.
The Owner HandbookScale is the whole point.
A permission model is only as good as the platform underneath it. Ours is checked on every message, on hardware we own and tune ourselves.
Questions about roles and permissions.
Who can create and edit roles?
The server owner, and any member whose role grants the ability to manage roles. Treat that particular permission as the most powerful one you can hand out, because whoever holds it can reshape everyone else's power. In most servers it belongs to the owner and at most one or two deputies, and every use of it is recorded in the audit log.
What happens when a member holds several roles?
Their abilities are the union of everything their roles grant. Roles only ever add; none of them can cancel out another. That means stacking a cosmetic supporter role on top of a moderator role changes how someone looks, not what they can do, and removing any single role takes back exactly what that role granted and nothing else.
Can I make an announcements channel only staff can post in?
Yes, and it is the single most useful override there is. Open the channel to everyone for reading and restrict posting to your staff role. Members get one quiet, authoritative place to check, and nothing important gets buried under conversation. Pin the messages that must stay findable and the channel runs itself.
Do roles have any effect on direct messages?
No. Direct messages on Vronify.chat are private and live entirely outside the server system, so no role, override, or moderator can see, restrict, or manage them. Community channels are a different matter by design: they are visible to their community and its moderators precisely so your moderators can keep public spaces safe.
Can members pick their own roles?
Self-service is coming. Reaction roles, where members grab cosmetic roles like pronouns or interests by reacting to a message you set up, ship as part of the bot engine, which is in active development and not live yet. Until then, a member with role-management rights assigns roles. Even after launch, keep self-service to cosmetic roles; power should always pass through a person.
What happens to someone's roles when they are banned?
A ban ends their participation in that server, nothing more. Their account is untouched: they keep it, they keep every message they ever sent, and they keep the DMs they received. Roles are a server-side arrangement, so losing them costs a member nothing they own. That separation is deliberate, and the account ownership page explains why we hold that line.
Can a role ever outrank the owner?
No. The owner has full control of their server at all times, and no permission grant, however generous, changes that. Ownership itself only moves through a deliberate, confirmed handover by the current owner. If you are ever unsure whether a configuration has gone wrong, remember that as the owner you can always open settings and unwind it; if you get stuck, support can help you trace what changed.
Your community. Your rules. Your data.
Create a server, invite your people, and see what chat feels like when your account actually belongs to you.
Free to start. Live in under a minute. No install required.