Skip to content

Latest commit

 

History

History
118 lines (79 loc) · 4.74 KB

public_access.md

File metadata and controls

118 lines (79 loc) · 4.74 KB
Raw
stage group info type
Data Stores
Tenant Scale
To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
reference

Project and group visibility (FREE)

Projects and groups in GitLab can be private, internal, or public.

The visibility level of the group or project has no influence on whether members within the group or project can see each other. A group or project is an object to allow collaborative work. This is only possible if all members know about each other.

Group or project members can see all members of the group or project they belong to. Group or project owners can see the origin of membership (the original group or project) of all members.

Private projects and groups

For private projects, only members of the private project or group can:

  • Clone the project.
  • View the public access directory (/public).

Users with the Guest role cannot clone the project.

Private groups can have only private subgroups.

Internal projects and groups (FREE SELF)

For internal projects, any authenticated user, including users with the Guest role, can:

  • Clone the project.
  • View the public access directory (/public).

Only internal members can view internal content.

External users cannot clone the project.

Internal groups can have internal or private subgroups.

NOTE: From July 2019, the Internal visibility setting is disabled for new projects, groups, and snippets on GitLab.com. Existing projects, groups, and snippets using the Internal visibility setting keep this setting. For more information, see issue 12388.

Public projects and groups

For public projects, users who are not authenticated, including users with the Guest role, can:

  • Clone the project.
  • View the public access directory (/public).

Public groups can have public, internal, or private subgroups.

NOTE: If an administrator restricts the Public visibility level, then /public is visible only to authenticated users.

Change project visibility

You can change the visibility of a project.

Prerequisite:

  • You must have the Owner role for a project.
  1. On the left sidebar, at the top, select Search GitLab ({search}) to find your project.
  2. On the left sidebar, select Settings > General.
  3. Expand Visibility, project features, permissions.
  4. Change Project visibility to either Private, Internal, or Public. The visibility setting for a project must be at least as restrictive as the visibility of its parent group.
  5. Select Save changes.

Change group visibility

You can change the visibility of all projects in a group.

Prerequisites:

  • You must have the Owner role for a group.
  • Subgroups and projects must already have visibility settings that are at least as restrictive as the new setting of the parent group. For example, you cannot set a group to private if a subgroup or project in that group is public.
  1. On the left sidebar, at the top, select Search GitLab ({search}) to find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand Naming, visibility.
  4. Under Visibility level select either Private, Internal, or Public. The visibility setting for a project must be at least as restrictive as the visibility of its parent group.
  5. Select Save changes.

Restrict use of public or internal projects (FREE SELF)

Administrators can restrict which visibility levels users can choose when they create a project or a snippet. This setting can help prevent users from publicly exposing their repositories by accident.

For more information, see Restrict visibility levels.

Related topics