Skip to main content

Choosing an enterprise type for GitHub Enterprise Cloud

To decide how people will access your company's resources on GitHub Enterprise Cloud, ask yourself some questions about the needs and workflows of your company, administrators, and users.

About types of enterprises

Before you start using GitHub Enterprise Cloud, you must decide how members of your enterprise will access your company's data, such as organizations, repositories, issues, and pull requests.

On GitHub Enterprise Cloud, your enterprise account is a central place for your users to collaborate. An enterprise account is also where you secure, administer, and govern access to your company's data. For more information, see "About enterprise accounts."

The features and functionality available to your users depend on which type of enterprise you create. You can choose one of the two following types of enterprises:

Type of enterpriseUser identityAuthenticationProvisioning
Enterprise with personal accounts on GitHub.comExisting personal account on GitHub.com
  • Username and password for GitHub.com
  • Optionally, additional Security Assertion Markup Language (SAML) authentication through your external identity management system
  • None; users own accounts, and enterprise and organization owners grant membership manually
  • Optionally, use System for Cross-domain Identity Management (SCIM) from your identity management system to provision access to individual organizations that use SAML authentication
Enterprise with managed usersManaged by your external identity management system
  • SAML
  • OpenID Connect (OIDC), if you use Microsoft Entra ID (previously known as Azure AD)
  • SCIM from your identity management system

If your company is new to GitHub Enterprise Cloud, enterprises with personal accounts and Enterprise Managed Users are equally easy to adopt.

To maintain a presence in the open source community while practicing innersource in a managed environment, some companies maintain repositories within an existing enterprise with personal accounts on GitHub.com, and also create a separate enterprise with managed users.

To choose the type of enterprise that will best serve you and your users, ask yourself the following questions.

Do you want to control the user accounts for your users?

Enterprise Managed Users may be right for your enterprise if you don't want enterprise members to use their own personal accounts on GitHub.com to access your enterprise's resources.

Enterprise Managed Users provides a true SSO experience for users. If you choose Enterprise Managed Users, you will provision the accounts for your users, and users will not need to sign into a separate user account. You can also ensure that these user accounts conform with your company identity by controlling usernames and the email addresses associated with the accounts.

If you do not choose Enterprise Managed Users, each user must create, manage, and sign in to a personal account on GitHub.com. You can configure SAML authentication so that users must authenticate to your external identity management system in addition to signing in to a personal account. After successful SAML authentication, GitHub links the user's personal account to an external identity on the identity management system.

If you currently require your users to create a new personal account on GitHub.com to contribute to your company's resources, Enterprise Managed Users might be a better alternative. If using your external identity management system as the source of truth for your user and access management would add too much complexity, creating an enterprise that allows you to configure additional SAML access control for existing personal accounts on GitHub.com may be a better option. For example, perhaps your enterprise does not have an established process for onboarding new users in your identity management system.

Is your external identity management system supported?

If you choose to create an enterprise that uses personal accounts on GitHub.com, you can configure additional authentication with an external identity management system that adheres to the SAML 2.0 standard. GitHub also officially supports and tests some identity management systems. For more information, see "Configuring SAML single sign-on for your enterprise."

GitHub partners with some developers of identity management systems to provide a "paved-path" integration with Enterprise Managed Users. To simplify your configuration and ensure full support, GitHub recommends that you use a single partner IdP for both authentication and provisioning. If you use a partner identity provider (IdP), you can configure one application on your IdP to provide authentication and provisioning. The IdP must support the SAML 2.0 standard. Alternatively, if you use Entra ID (previously known as Azure AD), you can configure OpenID Connect (OIDC) authentication. If you don't use a partner IdP, or if you only use a partner IdP for authentication, you can integrate IdPs that implement the SAML 2.0 and System for Cross-domain Identity Management (SCIM) 2.0 standards. For more information, see "About Enterprise Managed Users."

Do your users work in public repositories, gists, or GitHub Pages sites?

To prevent enterprise members from accidentally leaking corporate-owned content to the public on GitHub.com, Enterprise Managed Users imposes strong restrictions on what users can do. For example, managed user accounts cannot create public repositories, gists of any visibility, or GitHub Pages sites that are visible outside the enterprise. For a full list of restrictions, see "Abilities and restrictions of managed user accounts."

These restrictions are unacceptable for some enterprises. To determine whether Enterprise Managed Users will work for you, review the restrictions with your users, and confirm whether any of the restrictions will hinder your existing workflows. If so, an enterprise with personal accounts may be a better choice for your enterprise.

Do your users rely on collaboration outside of your enterprise?

Managed user accounts can only contribute to repositories within your enterprise. If your developers must contribute to repositories both within and outside of your enterprise, including private repositories, Enterprise Managed Users may not be right for your enterprise. An enterprise with personal accounts may be a better solution.

If your company maintains repositories within an existing enterprise with personal accounts on GitHub.com, and also creates a separate enterprise with managed users, users who contribute to repositories owned by both enterprises from a single workstation must switch between the accounts on GitHub.com within their browser. The user may also need to customize the workstation's Git configuration to accommodate the two accounts. The complexity of this workflow can increase the risk of mistakenly leaking internal code to the public.

If you choose Enterprise Managed Users but require that users contribute to resources outside of the enterprise from a single workstation, you can provide support for switching between the accounts in a user's local Git configuration. For more information, see "About Enterprise Managed Users."

Can your enterprise tolerate migration costs?

If you already have an enterprise that uses personal accounts on GitHub.com, adoption of Enterprise Managed Users requires migration to a new enterprise account. For more information, see "About Enterprise Managed Users."

Although Enterprise Managed Users does not differ in cost from an enterprise that uses personal accounts, the migration process may require time or cost from your team. Confirm that this migration process is acceptable to your business and your users. If not, an enterprise with personal accounts may be the better choice for you.

Further reading