Skip to main content
This article shows how to configure repository creation and related member privileges for a GitHub organization, and demonstrates how those settings affect what organization members and owners can do. These controls help enforce governance and protect sensitive code while enabling collaboration.
Note: “Internal” repository visibility is available only for GitHub Enterprise and some paid organization plans. If your organization plan does not include Internal repositories, members will only see Public and Private options.

​
Why control repository creation?

Restricting repository creation by visibility can prevent accidental public exposure of private code and maintain consistent governance across your organization. Common policies include allowing members to create only Private repositories or disallowing creation entirely for non-owners.

​
Where to change these settings

  1. Go to your organization on GitHub.
  2. Navigate to Settings -> Member privileges.
  3. Under “Repository creation” select which repository types members can create (Public, Internal, Private, or a combination).
  4. Optionally prevent outside collaborators from creating repositories.
These settings apply to organization members. Outside collaborators (users who are not members) can be blocked from creating repositories entirely.

​
Demonstration: member vs owner experience

I demonstrate using the Game Dev Studio organization:
  • First, I log in as a regular member user (siddh-dev2) and start creating a new repository. When the organization allows all types, the member sees all three visibility options: Public, Internal, and Private.
  • Then I update the organization policy to allow only Private repositories for members.
  • After enforcing the policy, a member attempting to create a repository in Game Dev Studio sees only the Private option; Public and Internal choices are disabled for them.
Even with these restrictions in place, organization owners retain the ability to create repositories with any visibility and thus can override member restrictions when necessary. As an owner, I create a repository named “app-backend” under Game Dev Studio and manually choose the visibility.
A dark-themed GitHub "Create a new repository" page is shown, with the owner set to "game-devstudio" and the repository name "app-backend" entered. The visibility dropdown (Public/Internal/Private) and other configuration options are visible.
I select Private, enable the README initialization, and create the repository. This demonstrates that organization owners can choose any visibility while member creation remains constrained.
Organization owners retain the ability to create repositories with any visibility and can override member repository creation restrictions. Use this authority deliberately so visibility choices stay consistent with your organization’s security policies.

​
Member privileges — key options

In the Member privileges area you can configure several important settings that affect collaboration and security. Review these to align with your governance model.

​
How these settings affect workflows

  • Members: Limited to creation options you allow; default repository permissions determine initial access to new repos.
  • Owners: Full control to create any visibility and change organization policies.
  • Outside collaborators: Can be prevented from creating repositories or given restricted abilities.
  • Review your organization’s compliance and IP policies.
  • Set “Repository creation” to the minimal set of visibility options required.
  • Configure a conservative “Base permission” for members (start with Read).
  • Decide whether forking of private/internal repositories is acceptable.
  • Periodically audit owner activity and repository visibility.
A dark-themed screenshot of a GitHub organization settings page showing "Member privileges" options like repository forking, outside collaborators, repository discussions, and projects/pages permissions with checkboxes and Save buttons. The left sidebar shows other settings categories (Codespaces, Actions, Webhooks, etc.).
Take a moment to review each Member privileges option and align them with your organization’s security and collaboration policies.

Watch Video