What the setting actually does
GitLab’s follow feature is a social connection graph: it records who you follow and who follows you. The preference that controls it is separate from the visibility of the projects, issues, comments and other resources you create.
GitLab preferences include Enable follow users. Source
Treat that checkbox as an on/off switch for the graph itself, not for your public footprint. Before you touch it, decide which of two different goals you actually have:
| Your goal | Is the follow setting the right tool? |
|---|---|
| Stop appearing as someone’s follower, or stop new followers | Yes, this is the setting that controls those connections |
| Remove all public activity from view | No, this setting does not do that |
| Keep current connections but stop new ones | Not established by the reviewed facts; check the current interface rather than assuming a pause option exists |
The irreversible part most people miss
Clearing the checkbox is not a temporary pause. Saving the change removes the connections that already exist.
Clearing Enable follow users and saving deletes the existing following and follower connections. Source
The reviewed facts do not describe any automatic restoration of those connections. If the owner wants to keep the current follower and following list, the safe decision is to leave the setting alone until they are sure. Rebuilding a graph means asking people to follow again; plan for that as manual work, not as a setting you can flip back.
Why “private profile” is not a blanket
A common mistake is to assume that a private profile hides everything. The reviewed facts say otherwise.
A private GitLab profile does not hide every public resource or public contribution. Source
So if the real concern is a specific public project, issue or comment, the follow setting is the wrong lever. Those items need to be reviewed on their own terms. The reviewed facts do not establish which visibility controls exist for each resource type, so check the current interface for the specific item rather than generalizing from the profile setting.
A checklist before you save
- Write down the goal. Is it the connection graph, or the visibility of particular content? These are different tasks.
- Export or note your current connections if they matter. The reviewed facts do not promise any way to restore them after saving.
- Ask the owner. If the account belongs to someone else, confirm whether losing current followers and following is acceptable.
- Check the exact label in the current interface. This guide relies on the reviewed preference name; menu locations can change and are not established here.
- Clear the setting and save only after steps 1–4. Saving is the step that deletes the connections.
- Verify the result in the profile. Do not assume that other public activity has changed.
- Handle content visibility separately. Use the controls for the specific resources you are worried about, and do not describe the follow change as making the account private.
Failure paths to plan for
- You wanted to pause, not delete. There is no documented pause in the reviewed facts. Skipping the save is the only reliable way to keep the graph.
- You expected followers to come back after re-enabling. The reviewed facts do not describe automatic restoration; treat the connections as gone.
- You assumed the profile is now hidden. Public resources and contributions may still be visible, so review them individually.
- You are acting for someone else. Confirm their preference first; an irreversible change made on their behalf is hard to justify afterward.
A related next step
If the account you are reviewing is one of several places a person appears, the connection graph is only one signal. A username lookup can surface public profiles as leads, not proof of ownership, and it is not a complete account inventory. See finding social media accounts by username when the question shifts from GitLab settings to mapping a public presence.
Where this guide stops
The reviewed facts cover the follow preference and the limits of a private profile. They do not establish current menu paths, notification behavior, or what happens to follow requests in flight. Demand for this specific task is an editorial hypothesis, not a measured trend. Check the live interface before acting, and keep the decision about connections separate from the decision about content visibility.