Comparing Mastodon Default Roles and Staff Permissions
When launching or managing a federated community on Mastodon, assigning operational powers requires a clear grasp of how permissions cascade through the system. During installation, when the database is seeded, roles are derived directly from values defined in ~/config/roles.yml. Community administrators must understand how these assignments split everyday moderation chores from critical server-level oversight. For teams familiar with structuring forum roles to block hidden moderator tool abuse, examining the default access tiers outlined in the Roles - Mastodon documentation ensures that every staff member holds appropriate capabilities without compromising server integrity.
The Hierarchy: Understanding Mastodon Role Priorities
Mastodon controls authority using a strict numerical priority scale. Higher numbers represent higher standing in the operational hierarchy, establishing guardrails for role editing and conflict resolution. When conflicting actions arise, a higher role decides conflict resolution in certain situations, and specific operational actions can only be executed against accounts holding roles with a lower priority value.
The system establishes fixed priority levels across its default accounts:
- Owner: Assigned a priority of 1000, representing absolute administrative control.
- Admin: Assigned a priority of 100, granting broad oversight across moderation and settings.
- Moderator: Assigned a priority of 10, focused on day-to-day community discipline.
- Base role: Assigned a priority of 0, serving as the foundational tier for general site participation.
Base Role vs. Elevated Staff Accounts
The base role, also known as Default permissions, affects all users across the instance, including community members who have no explicitly assigned role. Its priority is permanently fixed at 0, and this value cannot be altered by administrators.
In contrast to elevated staff positions, the permission structure of the base role is heavily constrained. The only permission flag that administrators can alter for the base role is Invite Users. When an administrator enables Invite Users on the base role, all members across the instance gain permission to send invitations. Every other operational and moderation permission flag remains entirely unavailable at this foundational tier.
Moderator vs. Admin: Comparing Operational Powers
The division between the Moderator and Admin roles illustrates the difference between front-line enforcement and instance-wide governance. While both roles permit staff members to modify their own Name, Badge color, and Display badge attributes, their functional capabilities differ sharply.
A user with the Moderator role holds a priority of 10 and receives a specific subset of Moderation permission flags designed for daily content review, as documented in the Roles - Mastodon documentation:
- View Dashboard
- View Audit Log
- Manage Users
- Manage Reports
- Manage Taxonomies
By contrast, the Admin role holds a priority of 100 and possesses all Moderation and Administration permission flags. This grants admins complete oversight of site settings, user accounts, and report handling. However, the DevOps permission flag is disabled by default for the Admin role. An Owner—or a custom role configured with a higher priority value—can explicitly enable the DevOps flag for administrators if server-level tasks require it.
Owner Role: Absolute Control and Safeguards
The Owner role sits at the peak of the Mastodon access model. It is assigned the Administrator permission flag, which bypasses all permission checks across the platform. Users who hold the Owner role have every permission flag enabled automatically.
While an Owner can update cosmetic settings—specifically Name, Badge color, and Display badge—no permissions can be revoked or edited from this role. Furthermore, because role priority for any new or existing role must be less than or equal to 999, no role can ever be created that supersedes the Owner role with its priority of 1000. This design ensures that the server owner retains permanent authority to modify any other role attributes across the platform without risk of being locked out by subordinate staff.
Custom Roles and Priority Constraints
Community administrators who need bespoke access levels can visit the admin/roles/new page or use the Add role button on the Roles page (/admin/roles). When creating custom roles, administrators specify a Name, Badge color, Priority, permissions, and whether to display the role as a badge on user profiles. Multiple roles can share duplicate names because the database discerns them internally by an id that cannot be set from the web interface.
Priority configuration for custom roles introduces several notable boundaries:
- Priority defaults to 0 upon creation.
- Priority cannot be greater than 999.
- Priority can be set to any negative integer value.
- Two distinct roles can be assigned the exact same priority value.
Editing permissions reinforces the hierarchy. Any logged-in user granted the Manage Roles permission can see every role listed in the admin interface. However, that user cannot modify any role that possesses a priority equal to or exceeding their own assigned role priority. For teams building out a tiered moderation team under a comprehensive forum moderation guide, configuring role priorities correctly prevents lower-ranked moderators from altering their own permissions or overriding administrative policies.
Sources
Roles - Mastodon documentation
Published October 30, 2026. No affiliate links on this page. Facts come from the sources linked above; check them for updates.