Why GitLab sign-up and visibility restrictions matter
A self-managed GitLab instance that must stay closed to outsiders is protected first by its application settings. The controls that stop self-registration are the sign-up restriction setting, hard email confirmation, and the allowed email domains list, which limits who can create an account. The controls that stop public exposure are the default project visibility setting, which can be set to Private, and the restriction on public visibility, which stops users from making projects, groups or snippets public. Together they decide whether an unknown person can create an account, how many email addresses can be used to register, and what an anonymous visitor can see.
Teams need these settings as soon as the instance is reachable from a network that includes people who should not have access, which includes any instance exposed to the internet, a partner network or a shared corporate segment. A fresh installation should be reviewed before users are invited, because the defaults for your GitLab version are the baseline you must verify, not assume. Confirm the exact setting names and their behavior for your release in the GitLab hardening recommendations. These application settings form the first layer of the hardening group, ahead of SSH key restrictions, outbound request controls, secrets handling and runner isolation.
Once the settings are chosen, test them from the outside: open a private browser session, attempt to register, and try to reach a project URL without signing in. Record the results as evidence for your change records. If you plan to federate sign-in through GitLab's authentication options, decide whether self-registration should remain closed while your identity provider controls account creation. Repeat the checks after each upgrade, because a release can change how these settings behave and a new administrator can change them without notice.
Which sign-up and visibility settings to use and when
This table compares the sign-up and visibility settings in scope, what each one does, when it fits a closed corporate instance, and what it can break. Read each row against your collaboration model: who needs an account, who works outside your organization, and which projects must stay private. Confirm exact labels and behavior in the GitLab administration documentation for your version before you change anything.
| Setting | What it does and when it fits | What it can break |
|---|---|---|
| Self-registration disabled | Stops anyone from creating an account from the sign-in page. Fits a closed corporate instance where an administrator or your identity provider creates every user. | Contractors, auditors and open-source contributors who need an account cannot self-onboard. Plan an admin-led request path for them. |
| Sign-up restrictions | Limits who can register when self-registration is on, such as requiring admin approval or restricting sign-up to approved domains. Fits instances that accept some external users but need a gate on each account. | Approval queues can delay onboarding for collaborators. Confirm whether the setting also affects accounts created through external identity providers. |
| Email confirmation (Hard mode) | Requires new users to confirm their email address before they can use the instance. Fits open sign-up that must prove each address is reachable and owned by the registrant. | Requires working outbound mail. Users behind mail filters or with unmonitored addresses can get stuck, so test delivery first. |
| Allowed email domains | Restricts sign-up to addresses from listed domains, such as your corporate domain and named partner domains. Fits organizations that want self-service sign-up limited to known identities. | Blocks external collaborators whose addresses use other domains. Confirm how the list interacts with invitations and with accounts created by SAML or SCIM. |
| Denied email domains | Blocks sign-up from listed domains, such as free mail providers. Fits instances that accept open registration but want to exclude disposable or personal addresses. | Can block legitimate users who happen to use a personal address. Pair it with an approval step or invitations for those users. |
| Default project visibility set to Private | New projects start private, so teams must change visibility on purpose. Fits regulated work where exposure should require an explicit decision. | Teams may assume a project is shared and find it invisible to others. Document the change and check that existing CI/CD and package consumers still have access. |
| Default group visibility set to Private | New groups start private, which keeps organizational structure and membership hidden by default. Fits closed instances with sensitive customer or product work. | Users looking for a group to join may not find it. Publish an internal directory of groups if discovery matters. |
| Restricting public and internal visibility | Limits which visibility levels users can assign to projects and groups, or disables public visibility altogether. Fits organizations that never want code exposed outside a defined audience. | Open-source contributors and public documentation projects cannot publish. Internal visibility also needs a decision about whether all signed-in users see the content. |
How to configure sign-up and visibility in the right order
This sequence locks down who can join the GitLab instance and what anonymous users can see, so that identity, registration, email rules and visibility defaults are set before any project is created or reviewed. Each step closes with a check you can run and record.
Confirm the identity source before changing sign-up
Before touching registration, confirm where your users will come from: SAML, LDAP, OmniAuth providers, SCIM provisioning or local accounts. GitLab Self-Managed supports LDAP, SAML, generic OAuth 2.0, Kerberos, JWT, smart card authentication and SCIM, so the choice decides whether self-registration is needed at all. The administrator confirms this with the identity team and documents it. The step is done when an existing employee can sign in through the chosen source and you have a written list of the accounts that will remain local, such as break-glass administrators.
Disable or restrict self-registration
In the Admin Area, open the sign-up settings and turn off self-registration if your identity source provisions every user. If you must keep it, restrict it so that new accounts require administrator approval or are limited to the domains you approve. Confirm the exact option names and their behavior in your GitLab version, because the labels have changed across releases. Check the result by opening the sign-up page in a private browser session and confirming that no account can be created without the approved path.
Require email confirmation and set allowed domains
Turn on email confirmation, choosing the strictest mode your workflow tolerates, and add the email domains your organization owns to the allowed list. Decide whether addresses on other domains are blocked outright or only prevented from signing up without review. Test this with a test account on an unlisted domain. The check passes when the sign-up is refused and no confirmation email is sent to that address. Record the test in your change log so an auditor can see it was performed.
Set default project visibility to Private
Set the default visibility for new projects and groups to Private. This ensures that a user who creates a repository without thinking about visibility does not expose source code. Make sure the setting applies to both new groups and new projects, and that your internal guidance matches it. Verify by creating a test project as a standard user and confirming that it shows as private on the project page and in the API response.
Restrict public and internal visibility levels
Restrict the visibility levels that users may choose. If your organization does not need public projects or internal projects visible to every signed-in user, remove those levels from the allowed options so that only the levels you intend remain. Restrict the same options for groups and snippets where the settings allow it. The check is a standard user's attempt to set a project to public, which should be refused or unavailable in the form.
Audit existing public and internal projects separately
Changing these settings does not change projects and groups that already exist. Run a separate review of every public and internal project and group, and of any snippets, identify the owner of each one, and decide whether it should stay open or move to Private. Use the administrator's project and group listings and the API to produce the inventory. This review is a distinct piece of work with its own sign-off, because it touches existing content and may involve teams that depend on public access. The step is done when every exception has an owner and a documented reason.
Record the configuration and retest after upgrades
Export or screenshot the final sign-up, email, domain and visibility settings and store them with your configuration records. Add the test accounts and the project visibility test to a repeatable checklist. Rerun the checklist after every GitLab upgrade, since settings can move or change meaning between releases. The step is done when the checklist has a recorded pass for the current version and a named owner for the next run.
How identity providers change the sign-up decision
Once GitLab authenticates users through a corporate identity source, self-registration stops being the way accounts appear. LDAP, SAML, OmniAuth providers and SCIM provisioning each create or link accounts from a system your organization already governs, so the sign-up decision becomes a question of which path is allowed to create a user. In practice, you disable open self-registration and let the identity source be the only door, while keeping the administrator's ability to create accounts for exceptions. Confirm in your environment whether each sign-in method auto-creates accounts on first login or only links to accounts that already exist, because that behavior determines whether a locked sign-up form is actually enough.
The trade-off is between tight control and operational friction. Provisioning through SCIM or group-based LDAP sync means a leaver is removed from identity management and loses GitLab access without a manual step, which is the main reason to route sign-up this way. The cost is that anyone outside the directory, including contractors, partner engineers and some service accounts, needs a documented onboarding route, or they will be blocked or pushed toward workarounds. Decide early which populations sit outside the directory and how their accounts are approved, sponsored and reviewed.
Treat the authentication documentation as the reference for which providers, provisioning options and account-linking behaviors your edition and version support, and do not rely on this page for those details. Before changing sign-up settings, test each identity path with a non-production user, confirm which accounts it creates, and check that disabling registration does not break the sign-in flow your users depend on. Record the final combination in your access design so that auditors and administrators can see which path creates each account.
Security and operational risks to control after lockdown
Locking down sign-up and visibility removes the obvious entry points, but several routes still let people in or expose work after the settings are saved. The cards below cover the risks that remain and the control to put against each one, so the restrictions hold over time rather than only on the day they were changed.
Anonymous view of existing public projects
Restricting public visibility only affects projects and groups set to public from that point on. Projects that were already public, and any snippets or groups created earlier, can still be read without a login. Check every existing project and group, not only the instance defaults, and confirm that the instance-wide visibility restriction is enforced. Then review which projects are listed to anonymous visitors.
Invitations and group links bypass sign-up rules
Sign-up controls stop open registration, but a user can still join through an invitation sent to an address, a group invite link or an approved external identity provider. Domain allowlists and email confirmation do not apply the same way to every path. Review pending invitations, group share links and identity provider settings, and confirm that each path follows the access policy you intended.
Accounts left active after offboarding
A person who leaves the organization may keep a working login, personal access token or SSH key if their account was created outside your identity provider or never disabled. Tie account lifecycle to your directory where possible, and run a recurring review of active users, tokens and keys. Confirm who is responsible for disabling accounts and how quickly that happens.
Settings drift through configuration files
Many sign-up and visibility settings can be set in the admin interface and in configuration files such as gitlab.rb. When both are used, a later reconfigure or an edit in one place can silently change the other. Keep the authoritative configuration in version control, record who changes it, and compare the running values against that baseline after each upgrade or reconfiguration.
Administrator access to these settings
Anyone with administrator rights can reopen sign-up, change visibility defaults or add domains. Keep the number of full administrators small, require re-authentication for administrative actions with Admin Mode, and enforce two-factor authentication for administrator accounts. Review the list of administrators on a schedule, and remove standing rights that are no longer needed.
Audit logging of setting changes
A restriction is only as credible as the record of who changed it. Confirm that audit events cover changes to application settings, visibility, membership and administrator roles, and that logs are forwarded to a store your security team controls. Test the log path by making a harmless change and checking that it appears, and set a retention period that matches your evidence requirements.
Questions buyers ask before configuring GitLab visibility
Can our own team configure GitLab sign-up and visibility without a partner?
Yes, most of these settings sit in the Admin area of a self-managed instance and can be changed by an administrator. The harder part is deciding the values: who may register, which email domains are trusted, whether new projects default to Private, and whether anonymous users may see any content. Teams that already run GitLab usually handle the switches themselves and bring in a partner when they need the decisions written down, tested against their identity setup and rolled out with evidence. Confirm the exact menu paths and setting names against the documentation for your installed version, since they change between releases.
How long does a visibility review take?
The duration depends on how many settings are in scope, how many instances, groups and projects already exist, and whether existing content must be audited. A single instance with clear policy and no legacy public projects is a small task. A multi-group instance with years of mixed visibility, external accounts and integrations takes longer because each exception needs an owner and a decision. DeployOpen plans engagements as fixed scope, so timing follows from the written scope and the inventory agreed before work starts. Ask any provider for the inventory step, the test instance they will use and the change window they expect.
What cost drivers apply to restricting sign-up and visibility?
The main cost is the time of the people who decide policy and check results, not the settings themselves. Cost rises with the number of instances, the size of the existing project estate, the number of identity sources, and the amount of evidence the audit team expects. Recurring cost appears when policy must be re-checked after each GitLab release, because the maintenance policy ships a minor release monthly and patch releases twice a month. Ask a quote to separate one-time configuration and review from any retainer for ongoing checks.
Do Free or Premium tiers change which visibility options are available?
The core sign-up and visibility settings are part of GitLab itself, so they are not what separates tiers. The pricing page lists GitLab Free at no cost, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, and all three are available for self-managed installations. What changes is the surrounding control set, such as SAML, SCIM and compliance features, which often matter once sign-up is tied to corporate identity. Confirm the feature matrix for your tier with GitLab before you assume a setting is present or absent.
What do we need from our identity and admin teams?
You need an owner who decides whether self-registration stays off, which email domains are allowed, and how external users are invited. Identity teams should confirm whether accounts come from LDAP, SAML, OAuth or another provider, because a user who signs in through an external provider may not follow the same sign-up path. Admin teams should agree who holds full administrator rights, since changes to instance-wide settings affect every group. Write these decisions down before the change window so the configuration can be tested against real sign-in paths.
How do we handle external contractors who need access?
Contractors usually need an account that is created by an administrator or invited to a specific group, not open self-registration. Restrict sign-up to approved email domains, then add contractors individually or through a group invitation with an expiry you control. Review contractor memberships on a schedule and remove access when the engagement ends. Ask your identity team whether contractor identities should come from a separate provider, and confirm the invitation and expiry options available in your installed version.
What breaks if we restrict public visibility too early?
Pipelines, mirrors, package consumers, badges and documentation links can fail when projects that used to be public become private or internal. Illustrative example: a team switches a group to Private, and a public build badge in a README stops loading for anonymous readers. Inventory projects, group visibility and any external consumers before changing defaults, then notify owners and test their integrations. Confirm which features depend on anonymous access in the documentation for your version.
Limits to confirm in your own environment
Sign-up and visibility settings look simple in the admin interface, but how they behave depends on your GitLab version, how the instance was installed, whether it runs offline and how existing users are treated. The cards below list what to confirm with your GitLab administrators, your platform team and your security owner before you change anything in production.
Version and install method
Confirm that the setting names, locations and defaults you plan to use exist in your exact GitLab version. The Linux package, Helm chart, Operator and Docker installs each store configuration differently, so a setting documented for one method may be applied through another file or an environment variable in a different method. Ask your platform team which install method you run and where its configuration lives. Check the version against the upgrade stops you already plan to follow.
UI settings and gitlab.rb drift
Some settings can be changed in the Admin Area and also in the configuration file gitlab.rb. Confirm which source is authoritative in your environment, and whether a reconfigure run overwrites a value changed in the UI or the reverse. Without a clear owner, a later reconfigure can silently reopen sign-up or change visibility. Ask your administrators how they track changes and whether the configuration is managed in version control.
Offline and air-gapped behavior
Confirm how sign-up, email confirmation and domain checks behave when the instance cannot reach external mail servers, identity providers or update sources. Email-based confirmation depends on a working mail relay inside your network, and that relay must exist before you enforce it. Ask your network team which services the instance can reach and how offline updates and package sources are delivered.
Effect on existing accounts and groups
Tightening sign-up does not usually remove accounts that already exist, but confirm how changes to visibility defaults affect current groups, projects and snippets. Projects created as public before a restriction may remain public, and users may need to change their own settings. Ask your GitLab administrators for an inventory of public projects and groups and an agreed process for changing them, including who notifies the owners.
Gradual rollout of hardening
GitLab describes its hardening guidance as a work in progress to be rolled out gradually. Confirm which settings your security owner treats as required now and which can wait for a later review, and whether any change needs a test instance first. Agree the rollout order with your GitLab administrators and document each change, the reason for it and the person who approved it so the sequence can be audited later.
How to verify the lockdown and keep it locked
Verification starts with testing each control from the outside, as a user who should be blocked. Create a test account with an email address on an allowed domain and another on a disallowed domain, and confirm that sign-up succeeds only for the first. Repeat the check with self-registration disabled to confirm that the sign-up page offers no path in, and check that a user invited by an administrator still receives access. Record the outcome of each attempt, including the time and the instance version, so the result can be repeated later.
Next, check what an anonymous visitor can see. Open a browser session that is not signed in and try to load the group list, a sample of projects set to Private, and a project you expect to be Internal. Confirm that the instance-wide visibility restriction hides public content and that new groups and projects default to Private. Review each top-level group's visibility setting and its subgroups, because a subgroup can be more open than its parent in some configurations. Confirm the exact behavior for your edition and version against the authentication and visibility documentation, since the Hard email confirmation and domain allowlist options should be tested the same way.
Settings can change between releases, so schedule a repeat of these checks after every upgrade, including the planned stops on the required upgrade path, and after any change to the gitlab.rb file or the Admin Area. Keep the test results and the exported configuration in a dated change record that names the approver and the reviewer. Keeping that record is an internal change management practice that supports your own evidence trail, but it does not by itself establish compliance, and any external assessment is performed by an independent auditor. Ask your partner or your own team to confirm which settings are read from configuration files and which are changed in the interface, because that determines where drift is most likely to happen.
What changes when GitLab is upgraded or scaled
Do sign-up and visibility settings survive a GitLab upgrade?
Settings stored in the instance's application settings generally persist through upgrades, but you should not assume that without checking. Record the values you set for sign-up, email confirmation, allowed domains, default project visibility and public visibility, then re-verify them after every upgrade step. Confirm version-specific behavior for each target release in the release notes, since defaults and setting names can change between versions. Treat the post-upgrade check as part of the change record, not an optional step.
Why do GitLab upgrades stop at specific versions?
GitLab requires upgrades to pass through required upgrade stops, so you cannot jump straight to the newest release from an older one. Since GitLab 17.5, these stops fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11. Plan your path as a sequence of stops, and run the configuration review at each stop because a hardening change that is valid on one version may need adjusting on the next. Check the GitLab upgrade paths documentation before scheduling any step.
How does the maintenance policy affect hardening reviews?
The maintenance policy sets which releases receive fixes, so it determines how often your configuration review must happen. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and it currently maintains 19.5, 19.4 and 19.3. Bug fixes are backported only to the current stable release, while security fixes also reach the previous two monthly releases. If you run an older version, your review window for security fixes is shorter than you might expect, so schedule reviews against the release cadence rather than against a calendar quarter.
Do multi-node GitLab deployments need the same settings on every node?
Yes, the application settings and configuration files must match across nodes that serve the same instance, or users may see different sign-up and visibility behavior depending on which node handles a request. In a multi-node or high availability deployment, the docs generally recommend high availability for 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Application-level settings live in the database, but configuration files such as gitlab.rb must be applied consistently to every node. Use one source of truth for configuration and compare node configs after each change.
Does scaling change how I should configure GitLab?
Scaling changes the topology more than the policy, but the hardening decisions still apply to every component that serves users. GitLab's reference architectures range from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second. As you move up, you add stateful and stateless components, and each must inherit the same sign-up, email and visibility configuration. Confirm the reference architecture that matches your user count and CI load, and document which node owns each setting so that new nodes are configured from the same baseline.
Can Kubernetes-hosted GitLab components hold the same configuration?
The configuration can be consistent, but the placement of stateful services limits your options. The reference architectures documentation states that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. The Cloud Native Hybrid architecture runs stateless components on Kubernetes and stateful services on VMs or managed services. Whatever the layout, keep the configuration in version control, apply it through the same process to every environment, and confirm the supported layout for your release before you build it.
Who should own configuration review after each upgrade?
The platform or DevOps team that operates the instance should own the review, with the security owner approving changes to sign-up and visibility settings. Assign a named person to each upgrade stop, give them the baseline configuration and a checklist, and require sign-off before the next stop begins. Ask any partner for the review steps, the artifacts they produce and how they handle changes to settings during the engagement. Ongoing review can be handled in house or through a retainer, and the scope should be written down before work begins.
What should I ask for in a quote for an upgrade or scaling project?
Ask for a written scope that lists each upgrade stop, the target versions, the nodes or components involved and the configuration review at each step. Cost depends on the number of stops, the size of the topology, the number of environments and how much testing you need before production. Ask who performs backups before each stop, how rollback is handled and what is one-time work versus recurring support. Confirm that the quote follows from the agreed scope, since DeployOpen does not publish a price list and most engagements are fixed-scope.
How DeployOpen scopes and delivers this hardening work
DeployOpen scopes sign-up and visibility hardening in a written, fixed-scope agreement before any setting changes. The agreement names the instance, the identity sources in use (for example LDAP, SAML or an OmniAuth provider), the existing projects and groups that must be reviewed, and the people who approve changes. A written scope also records which controls are in and out, such as whether Hard email confirmation, domain allowlists and Private defaults apply to every group or only to new projects. Quotes follow from that scope, so the questions to ask a partner are the same ones your own team would need to answer: who can register, which email domains are trusted, which projects are public today, and who owns each decision.
Delivery happens inside your infrastructure. DeployOpen makes the changes in the Admin Area and in the configuration files for your instance, records the before and after state of each setting, and checks that anonymous users cannot reach projects, groups or snippets that should be private. Existing public projects need a separate review, because changing a default does not change visibility on projects that already exist. The result is written up as documentation your team can reuse: the setting values, the reasons for them, the test steps used to confirm them, and the open items that depend on decisions only your organization can make. DeployOpen does not issue audit reports or attestations, so any evidence produced here is input for your own assessors.
After the initial work, sign-up and visibility settings tend to drift as new groups, identity providers and projects are added. DeployOpen offers retainers for periodic configuration review, re-checking visibility of newly created projects and reviewing changes to registration rules when the instance is upgraded. Ask any partner to confirm in writing what a retainer covers, how often reviews happen, who receives findings and how changes are approved. Before signing, confirm that the proposed scope matches the GitLab version you run, since settings and their locations can change between releases, and check the GitLab hardening recommendations for the guidance your version provides.
