Namespaces and namespace administration

A namespace groups repositories and the people who work with them. As an organization grows, each product group can run its own namespace without receiving control over the whole organization.

For example, the payments namespace can have its own members, administrators, Teams, base permission, grants, and automation tokens, while platform has different ones. Being a member of payments gives no access to platform.

Open a namespace

Open organization settings and select Namespaces. Organization administrators see every namespace with its administrators, attached Teams, and auto-join setting; members see the namespaces they belong to. Select Open for the namespace workspace:

Section	Purpose
Members	Namespace members and why they belong, namespace administrators, Add members, Invite, the base permission, and auto-join
Teams	Namespace Teams and the organization Teams attached to this namespace
Access	Grants on every repository in the namespace, and a summary of grants on individual repositories
Private mirrors	Whether namespace members can install directly from private mirrors, shown when the organization lets each namespace decide
Automation tokens	Organization-owned tokens permanently restricted to this namespace
Danger zone	Rename or delete the namespace

Namespace members can view Members and Teams. Namespace and organization administrators can use every section except Danger zone, which is for organization administrators.

Namespace administrators

A namespace administrator runs one namespace. They are always a member of it and have full access to all of its current and future repositories.

Organization administrators appoint them: open Members in the namespace workspace, open the member’s actions, and choose Make namespace admin. Choose Remove namespace admin to end it; the person keeps their other namespace membership sources and any access granted to them or their Teams.

A namespace administrator can:

• add organization members to the namespace and remove direct memberships;
• invite new people into the namespace when the organization allows it;
• set the namespace base permission and auto-join switch;
• create namespace Teams and manage their members;
• grant roles to namespace members and Teams on the namespace or its repositories;
• create and manage repositories in the namespace;
• turn private-mirror use on or off for the namespace, when the organization lets each namespace decide; and
• create automation tokens restricted to the namespace.

They cannot rename or delete the namespace, appoint namespace administrators, change organization Teams or which namespaces they are attached to, define custom roles, manage remote caches, or manage organization members, billing, or policies.

Rename or delete a namespace

Organization administrators use the namespace’s Danger zone. Rename namespace changes name-based registry URLs unless only capitalization changes; ID-based targets keep working. Delete namespace requires that every repository in it has been deleted first.

See namespace membership and base and effective access for the access rules inside a namespace.