2019-09-04 21:01:54 +05:30
---
2021-01-29 00:20:46 +05:30
stage: none
group: unassigned
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2019-09-04 21:01:54 +05:30
type: reference
---
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
# Project visibility
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
GitLab allows [Owners ](../user/permissions.md ) to set a project's visibility as:
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
- **Public**
- **Internal**
- **Private**
2015-12-23 02:04:40 +05:30
2021-09-30 23:02:18 +05:30
These visibility levels affect who can see the project in the public access directory (`/public`
for your GitLab instance). For example, < https: / / gitlab . com / public > .
## Public projects
2014-09-02 18:07:02 +05:30
2019-12-21 20:55:43 +05:30
Public projects can be cloned **without any** authentication over HTTPS.
2014-09-02 18:07:02 +05:30
2021-02-22 17:27:13 +05:30
They are listed in the public access directory (`/public`) for all users.
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
**Any signed-in user** has the [Guest role ](../user/permissions.md ) on the repository.
NOTE:
By default, `/public` is visible to unauthenticated users. However, if the
[**Public** visibility level ](../user/admin_area/settings/visibility_and_access_controls.md#restricted-visibility-levels )
is restricted, `/public` is visible only to signed-in users.
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
## Internal projects
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
Internal projects can be cloned by any signed-in user except
[external users ](../user/permissions.md#external-users ).
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
They are also listed in the public access directory (`/public`), but only for signed-in users.
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
Any signed-in users except [external users ](../user/permissions.md#external-users ) have the
[Guest role ](../user/permissions.md ) on the repository.
2014-09-02 18:07:02 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2019-09-30 21:07:59 +05:30
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. You can read more about the change in the
2020-06-23 00:09:42 +05:30
[relevant issue ](https://gitlab.com/gitlab-org/gitlab/-/issues/12388 ).
2019-09-30 21:07:59 +05:30
2021-09-30 23:02:18 +05:30
## Private projects
2018-11-18 11:00:15 +05:30
2019-10-12 21:52:04 +05:30
Private projects can only be cloned and viewed by project members (except for guests).
2019-09-04 21:01:54 +05:30
2021-02-22 17:27:13 +05:30
They appear in the public access directory (`/public`) for project members only.
2018-11-18 11:00:15 +05:30
2021-09-30 23:02:18 +05:30
## Change project visibility
2014-09-02 18:07:02 +05:30
2019-12-21 20:55:43 +05:30
1. Go to your project's **Settings** .
1. Change **Visibility Level** to either Public, Internal, or Private.
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
## Restrict use of public or internal projects
2014-09-02 18:07:02 +05:30
2021-09-30 23:02:18 +05:30
You can restrict the use of visibility levels for users when they create a project or a snippet.
This is useful to prevent users from publicly exposing their repositories by accident. The
restricted visibility settings do not apply to admin users.
2019-09-04 21:01:54 +05:30
2019-12-21 20:55:43 +05:30
For details, see [Restricted visibility levels ](../user/admin_area/settings/visibility_and_access_controls.md#restricted-visibility-levels ).
2019-09-04 21:01:54 +05:30
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X` .
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
