How do large organizations deal with 1,500 team cap?

[tuisk909]

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

[queenofcorgis]

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 ❤️

[vegardx]

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.

[jankreuz-ext59276]

Hello,
was there any further discussion on this topic? We are dealing with similar decision (i.e. how to organize big enterprise structure in GHE) so any recommendations/thoughs/best practices would be welcome

[Denoroy737]

👋 @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:

1. Adopt a layered access model

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.

2. Use Repository Custom Roles (if available in your plan)

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.

3. Leverage external identity management (SSO/SCIM)

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.

4. Consider a hybrid structure

For high-turnover or temporary projects, use repo collaborators instead of new teams.

For stable, long-lived projects, use teams with well-defined roles.

5. If you expect rapid growth

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.

[Denoroy737]

Hope this was helpful 👍

[jankreuz-ext59276]

well, your reply provides enough info for our further analysis and internal discussions for now. Thanks for that 👍