A GitLab profile is addressed either by its username or by its user ID, and it always belongs to one specific host. A profile on gitlab.com and a profile on an independently hosted instance are separate account contexts, so a matching local name across hosts should be recorded as two host-specific records until a voluntary, current link connects them. Record the host first, then the username or ID.
Find public social profile clues with our TraceSeek app.
Why the host is part of the name
A GitLab profile lives on a particular host, and that host is part of what you are looking at. GitLab.com and independently hosted instances are separate account contexts, and GitLab documents that a profile can be addressed by username or by user ID on its specific host. Two pages that both show a local name are therefore two separate account contexts until you show otherwise. The practical habit is to write the host down first and the name second, so a later search or note never silently drops the distinction. [GitLab Docs: public profile, account ID and owner settings]
Comparing a shared profile with a self-hosted one
When someone shares a gitlab.com profile and also mentions a self-hosted instance, treat the two as parallel records rather than one record seen twice. Compare display names, stated context and public links, but remember that consistency is only consistency. A matching local name on the second host does not confirm that the same person holds both accounts. If you cannot reach the self-hosted page at all, record that as unavailable and stop at the access boundary instead of substituting guesses. [GitLab Docs: public profile, account ID and owner settings]
- Write the full host next to every GitLab profile you note, and keep the two hosts on separate lines.
- Mark any profile you could not open as unavailable, and say why rather than filling the gap.
The ID-based format and what it changes
GitLab documents that a profile can be addressed using its username or its user ID on its specific host, so an ID-based profile address is a route to the same account context, not a different person. An ID is a second way to point to one account on that host, but it does not make the account global and it does not carry across hosts. Treat the ID as an additional identifier tied to the host, not as a master key. When comparing two profiles, put the host and the identifier type side by side so you can see whether you are comparing like with like. [GitLab Docs: public profile, account ID and owner settings]
Reading the profile without overclaiming
Public profile material is thin evidence. Making a profile private hides profile sections but does not hide every resource that was previously public, and a user-entered status may remain public; administrators can also impose visibility restrictions. Owners can choose to show private contribution actions without publishing all the underlying private project information, so a contribution graph is not a real-time presence or identity record. External social-account fields can hold different kinds of identifiers, such as a Discord user ID or a GitHub username, so treat each field as the kind of identifier it is rather than as a display name. These details describe a page, not a person's intent or honesty. [GitLab Docs: public profile, account ID and owner settings]
A worked comparison, explicitly hypothetical
Suppose a hypothetical contact shares a gitlab.com profile whose stated context is a public project, and in the same conversation mentions a self-hosted instance. You note the two hosts separately, note that the local names happen to match, and find no shared self-link between the pages. The right conclusion is not that the accounts are one identity; it is that you have two host-specific records with a name overlap. You might ask, in the same channel where the profiles were shared voluntarily, whether both belong to the same context. If you cannot open the self-hosted page, mark it unavailable rather than assuming it matches.
- Keep an observation column and a limit column in your notes, so a match never quietly becomes a conclusion.
- Ask a clarifying question only in the channel where the material was shared with you.
Stop at the access boundary
If a documented profile page or permitted public artifact is unavailable, record it as unavailable and stop there; do not infer the missing page from the one you can see. Ask for a voluntary current link only in the channel where the profile was originally shared. Keep a record of what you could and could not open, so a missing host never turns into an assumed identity. [GitLab Docs: public profile, account ID and owner settings]
A couple more questions
Is the same username on gitlab.com and on a self-hosted instance the same account?
GitLab.com and independently hosted instances are separate account contexts, and a profile is addressed by username or user ID on its specific host. A matching local name across hosts is a name overlap, not proof of one identity.
Does an ID-based GitLab profile address prove who the person is?
It only points to one account on one host. GitLab documents username and user ID as two ways to address a profile on its specific host, which helps keep records straight but says nothing about identity beyond that account context.
Is a contribution graph a reliable sign that someone is active right now?
No. An owner can show private contribution actions without publishing all underlying private project details, so the graph should not be read as a real-time presence or identity record.
What should I do if I cannot open the self-hosted profile?
Record it as unavailable and stop at the access boundary. Do not infer the missing page from the other profile; ask for a voluntary current link only in the channel where the profile was originally shared.
Sources & editorial notes
Official references checked on October 23, 2026. Checklists, comparison tables and example wording are DateClues editorial tools, not official tests or validated risk scores.
General information. No guide or tool can certify a person’s identity, intentions or safety. Read our editorial standards.