We run a closed self-hosted instance for a language school whose members include minors. Desired model:
Teachers/staff can create and run their own communities (classrooms, clubs)
Students can join communities they are invited to, but cannot create communities, and this must be enforced server-side (hiding client buttons is not enforcement for a child-safety posture)
Current options are all-or-nothing
single_community_enabled blocks community creation for everyone and limits the instance to one community — too restrictive for the teacher-communities model
Otherwise, any claimed, email-verified user can create communities up to max_guilds
Observation
The limits system already resolves max_guilds through trait-matched rules (LimitMatcher / createLimitMatchContext with user traits), and GuildOperationsService.createGuild already consults it. What seems missing is an admin-manageable way to segment users so a rule like "default 0 owned communities, elevated for staff/teacher accounts" can be expressed.
Suggested shapes (any would work for us)
An instance policy default of max_owned_guilds: 0 plus a per-user admin override (count or trait/badge assignable from the admin dashboard)
Admin-assignable user traits that participate in limit rule matching
An explicit "may create communities" user flag checked in createGuild
We are happy to contribute a PR if maintainers indicate a preferred direction.
Merged posts
These posts were merged into this one. Their comments are now part of the conversation below, marked with where they came from.
We run a closed self-hosted instance for a language school whose members include minors. Desired model:
Teachers/staff can create and run their own communities (classrooms, clubs)
Students can join communities they are invited to, but cannot create communities, and this must be enforced server-side (hiding client buttons is not enforcement for a child-safety posture)
Current options are all-or-nothing
single_community_enabled blocks community creation for everyone and limits the instance to one community — too restrictive for the teacher-communities model
Otherwise, any claimed, email-verified user can create communities up to max_guilds
Observation
The limits system already resolves max_guilds through trait-matched rules (LimitMatcher / createLimitMatchContext with user traits), and GuildOperationsService.createGuild already consults it. What seems missing is an admin-manageable way to segment users so a rule like "default 0 owned communities, elevated for staff/teacher accounts" can be expressed.
Suggested shapes (any would work for us)
An instance policy default of max_owned_guilds: 0 plus a per-user admin override (count or trait/badge assignable from the admin dashboard)
Admin-assignable user traits that participate in limit rule matching
An explicit "may create communities" user flag checked in createGuild
We are happy to contribute a PR if maintainers indicate a preferred direction.
This is now available on self-hosted instances as of #3055..
In the admin panel, go to "Instance config" → "Community creation" and set "Who can create communities" to "Restricted". From then on, only admins with the wildcard ACL and users matched by a limit rule that grants "Community Creation Access" can create communities. Everyone else gets a "You don't have permission to create communities on this instance" error, enforced server-side.
To let specific people create communities, give those users a trait on their admin user page, then add a rule under "Limit config" that matches that trait and turns on "Community Creation Access".
1 comment
Comment by Hampus