How do large organizations deal with 1,500 team cap? #126547
Replies: 3 comments 3 replies
-
| Hey @tuisk909 - thanks for posting this is a great question - I'm going to make sure it is highlighted in June's Enterprise roundup so you're more likely to get a few perspectives here ❤️ | 
Beta Was this translation helpful? Give feedback.
-
| Hi, I'm very keen on this discussing this to get other peoples perspectives on this. Feel free to reach out to me directly using the e-mail in my profile. We've discussed doing all the role mapping in Entra ID, where every repository role mapped to a unique team, which was mapped to a unique Entra ID group. But this doesn't really scale with the limit of 1500 teams per organization. It's also unknown how well this would work with IdP team synchronization. | 
Beta Was this translation helpful? Give feedback.
-
| 👋 @tuisk909, This is a common challenge for large organizations using GitHub Enterprise, especially when following a “one repo → one team” model. A few approaches that can help manage the 1,500 team limit efficiently: 
 Instead of creating separate write/admin teams per repo, create departmental or functional teams (e.g., frontend-devs, backend-admins, qa-team) and then assign these teams to multiple repositories as needed. Use nested teams to manage finer-grained access. For example, a parent team (e.g., engineering) can have sub-teams (e.g., engineering/projectA, engineering/projectB) that inherit base permissions but allow specific overrides. 
 Custom roles let you define specific permissions beyond the basic read/write/admin levels, reducing the need to create multiple teams just for access segmentation. 
 Manage access groups in your identity provider (like Azure AD or Okta) and sync them with GitHub. This reduces the need to handle everything at the GitHub team level. 
 For high-turnover or temporary projects, use repo collaborators instead of new teams. For stable, long-lived projects, use teams with well-defined roles. 
 You may need to split into multiple orgs eventually (e.g., Company-Engineering, Company-Labs, etc.) and manage them via GitHub Enterprise Cloud or Enterprise Server with Enterprise Managed Users (EMU) for unified identity and audit. In short — go for a hierarchical team structure + identity provider integration instead of per-repo teams. It keeps things scalable and compliant without hitting the 1,500-team ceiling. | 
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Body
Hi,
I work with a large organization that has recently started using GitHub enterprise and we looking for suggestions of how other organizations deal with the 1,500 team limit.
We were planning on setting it up so that each new repo created will automatically be assigned a new write and admin team but are worried that over time this will see us exceed the 1,500 team limit.
Another option would be to have a single write/admin team for multiple repos based on company departments or teams. However issue with this is that it means that some users could have access to repos that we they really don't need access to.
So basically we are trying to find out what's the best way for assigning access essentially without requiring multiple orgs?
Thanks
Beta Was this translation helpful? Give feedback.
All reactions