The short answer
GitLab offers a Private profile option in profile settings. That switch is a visibility control for your profile page, not a global privacy mode for everything tied to your account. Private profile settings do not make all public resources or API-visible information private, and commit email identity has separate settings. Treat the switch as one step in a review, not the finish line.
GitLab offers a Private profile option in profile settings. Source
Private profile settings do not make all public resources or API-visible information private. Source
Commit email identity has separate settings. Source
Step 1: Capture a before snapshot
Before changing anything, record what a logged-out visitor can see. Use a private window or a browser profile that is not signed in to GitLab, and save screenshots with dates. This gives you a baseline you can compare against after the switch.
Record these views:
- Your profile page as a logged-out visitor: display name, avatar, bio, location, website links and any listed social handles.
- Your public projects list: names, descriptions, visibility labels and last-activity dates.
- Contribution activity shown on the profile, if any is visible.
- A sample commit page from a public project, to see which name and email are attached.
- Your profile as a signed-in non-member if you can arrange it, since some views differ between anonymous and authenticated visitors.
Keep the snapshot factual. You are not trying to judge whether the information is sensitive; you are trying to know what exists before you change settings.
Step 2: Change the profile visibility setting
In GitLab, profile privacy is controlled from your profile settings. The exact menu labels can change between releases, so navigate by function rather than memorising a path: open your account settings, find the profile section, and look for the Private profile option described in GitLab’s own documentation.
GitLab offers a Private profile option in profile settings. Source
When you enable it, do not assume the rest of your account follows. The setting governs the profile presentation; it does not reclassify projects, issues, merge requests, comments or API responses that are already public.
Private profile settings do not make all public resources or API-visible information private. Source
Step 3: Review public projects separately
Project visibility is its own setting, per project. After enabling a private profile, open each project you own or maintain and check its visibility. A project set to public remains reachable by anyone with the link, and its repository, issues and commit history can stay visible regardless of your profile setting.
Use this decision table to sort what you find:
| What you found | Where the control lives | What to check after changing it |
|---|---|---|
| Profile page details (bio, links, location) | Profile settings | Reload the profile logged out and confirm what a visitor sees |
| A project’s repository and issues | The project’s own visibility setting | Open the project URL in a private window |
| Commit author name and email | Commit email / identity settings | Inspect a commit page in each affected project |
| API responses containing your data | The resource’s visibility, not the profile switch | Re-request the same endpoint logged out |
| Cached or indexed copies elsewhere | Outside GitLab’s settings | Search for the profile URL and project names |
Two honest limits belong here. First, changing a project from public to private affects everyone who relied on that URL, including people who starred or forked it, and GitLab’s documentation on project visibility is the place to understand those effects. Second, search engines and third-party mirrors may retain copies of pages that were public earlier; a settings change does not reach into those copies.
Step 4: Separate your commit identity
Commit metadata is a frequent surprise. A commit records an author name and email, and those values can differ from what your profile now displays. Commit email identity has separate settings, so changing profile visibility does not rewrite existing commits or necessarily change what future commits expose.
Commit email identity has separate settings. Source
A practical review sequence:
- Open a commit page in each public project you contribute to.
- Note the author name and email shown.
- Check your commit email settings and confirm which address is used for new commits.
- Decide whether existing commits need attention; rewriting history is a separate operation with its own consequences, and it is not part of the profile switch.
Do not assume that enabling a private profile hides commit metadata. The two are governed by different settings.
Step 5: Verify the after state
Repeat the before snapshot exactly: same browser mode, same pages, same commit samples. Compare side by side. A useful check is to ask what changed and what did not. If your profile page is now restricted but a public project still lists your commits with an email, the review is not finished.
Also check API-visible information where you can. If you previously fetched a public endpoint that returned your profile or project data, request it again while logged out and compare. The private-profile option is not a promise that API responses change.
Private profile settings do not make all public resources or API-visible information private. Source
Common mistakes
- Treating the private-profile switch as account-wide privacy. It is a profile setting; projects and API-visible resources have their own visibility rules.
- Forgetting commit email. Commit identity is configured separately, and old commits keep the metadata they were created with.
- Checking only while signed in. Your own view is not the visitor’s view. Always verify logged out.
- Assuming a deleted or renamed project vanishes everywhere. Search indexes and mirrors can outlive the original page.
- Changing everything at once. Without a before snapshot you cannot tell which change produced which result.
- Confusing a hidden profile with deleted data. A restricted or edited profile does not establish that stored data has been removed.
- Ignoring linked handles. A bio link or social handle on the profile can lead to accounts elsewhere that you have not reviewed.
Checking the handles that remain
A GitLab profile often lists a personal site, a social handle or a username reused on other services. Those links are outside GitLab’s settings, and they are exactly the kind of public footprint a profile review should surface. If you want to see where a known handle appears across other communities, a username lookup can help you map the public matches; our guide on finding social media accounts by username explains the technique. TraceSeek covers 3,000+ platforms and offers a free first scan, with a stated scan time of 20-30 seconds. Public matches are leads, not proof of ownership, and a lookup does not change any platform setting or reveal private records.
Protecting your own footprint
Privacy on a code host is a set of independent controls, not a single toggle. A workable routine is to review profile visibility, project visibility and commit identity together, then re-check them after any change in role, employer or public activity. Keep a dated snapshot so future reviews start from evidence rather than memory. Where a platform documents its own settings, read that documentation rather than relying on secondhand summaries, because menus and defaults change between releases. And when you find a handle that appears on several services, review each account on its own terms; one platform’s privacy setting has no effect on another’s.
Key facts
- GitLab offers a Private profile option in profile settings.
- Private profile settings do not make all public resources or API-visible information private.
- Commit email identity has separate settings.
- TraceSeek covers 3,000+ platforms and offers a free first scan, with a stated scan time of 20-30 seconds.
- Public username matches are leads, not proof of ownership.