Published on: July 6, 2026
5 min read
Learn how GitLab's restricted access feature prevents seat overages, integrates with your identity provider, and keeps license costs predictable.
GitLab restricted access for instance admins, group owners, and billing managers enables predictable seat costs with less manual gatekeeping. The feature has been significantly improved and is now more complete for the workflows that commonly affect seat usage. This update closes the gaps around identity provider provisioning, dormant user reactivation, and sign-in flows so organizations can use restricted access with more confidence in real-world environments.
In this article, you'll learn what restricted access does, what changed, and how to turn the feature on.
Restricted access is a seat control feature available on GitLab.com and Self-Managed. When it is enabled and all licensed seats are already in use, GitLab blocks new billable users from being added.
Organizations, therefore, can avoid unexpected seat growth before renewal and keep seat usage aligned more closely to the number of seats they have purchased. Restricted access is designed to prevent new overages going forward, not to undo overages that already exist.
Users who do not need project or group access, such as users who authenticate through GitLab as an OpenID Connect (OIDC) provider, can be assigned the non-billable Minimal Access role. Those users can still authenticate without consuming a paid seat.
Restricted access is forward-looking. If you enable it on a group or instance that is already over its seat limit, GitLab does not downgrade, remove, or block existing billable members. Current memberships stay as they are. If there is already an overage, administrators still need to bring usage back within the purchased limit by removing billable members or purchasing additional seats.
Once seat usage is back within the subscription limit, restricted access helps prevent additional billable growth beyond that limit.
A major part of the recent feature completion work was improving how restricted access behaves with identity-driven provisioning.
When restricted access is enabled and no seats are available, users provisioned through SAML, SCIM, or LDAP are no longer added directly into billable roles. Instead, GitLab assigns them the non-billable Minimal Access role. Synchronization can continue while avoiding an immediate billable overage.
This behavior is especially helpful for organizations that rely on automated provisioning and want tighter cost controls without giving up centralized identity management.
If you use GitLab as an OIDC provider and some users only need authentication rather than project or group access, assigning Minimal Access at the top-level group remains a useful pattern. Those users do not consume billable seats, and users with only Minimal Access can still be reactivated even when no seats are available.
GitLab can automatically deactivate users who have had no activity for a configurable period, freeing up seats. Previously, when those users signed back in through OIDC or single sign-on (SSO), they could be silently reactivated as billable users, bypassing restricted access and creating license overages.
Now, when restricted access is active and no seats are available, dormant users who sign back in are placed in a pending approval state. Their group and project memberships are preserved, and an administrator can approve them when a seat opens up.
Restricted access is also easier to operate day to day.
Recent improvements added more guidance directly into the product so administrators understand what will happen before and after they hit their seat limit. Depending on the scenario, that includes:
The goal is not just to block new billable additions, but to make that behavior easier to understand and manage.
On GitLab Self-Managed, application settings are cached for 60 seconds by default for performance reasons.
As a result, if you switch between restricted access and user cap, some UI changes or seat-control behavior might not appear immediately. The cache refreshes automatically, and behavior becomes consistent once it does. If needed, administrators can adjust the cache interval.
See the application settings cache documentation.
Restricted access and user cap are related, but they solve different problems.
User cap puts new users into a pending approval flow for administrators or group owners to review, regardless of whether seats are still available. Restricted access is tied directly to the number of licensed seats and blocks new billable additions only when no seats remain.
In other words, user cap is an approval control. Restricted access is a seat-limit control.
They also cannot be enabled at the same time. When you enable restricted access, user cap is disabled automatically. On GitLab.com, switching from user cap to restricted access can also affect pending members, so it is worth reviewing the documented behavior before making the change.
Restricted access is available on GitLab.com and Self-Managed.
If your team wants tighter control over seat growth, fewer billing surprises, and a clearer operational model for provisioning and reactivation, restricted access is worth a closer look.
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback
Facts Only
* Restricted access is a seat control feature available on GitLab.com and Self-Managed.
* When enabled and all licensed seats are in use, GitLab blocks new billable users from being added.
* The feature is designed to prevent new overages going forward, not to undo existing overages.
* Users without project or group access, such as those authenticating via OpenID Connect (OIDC), can be assigned the non-billable Minimal Access role.
* If restricted access is enabled and there are no available seats, users provisioned through SAML, SCIM, or LDAP are assigned the non-billable Minimal Access role instead of billable roles.
* GitLab can automatically deactivate users with no activity for a configurable period to free up seats.
* Dormant users signing back in when restricted access is active and no seats are available are placed in a pending approval state.
* Restricted access and user cap cannot be enabled at the same time; enabling restricted access automatically disables user cap.
* Application settings on GitLab Self-Managed are cached for 60 seconds by default for performance.
Executive Summary
GitLab offers a restricted access feature on GitLab.com and Self-Managed environments designed to control seat usage, prevent overages before renewals, and align license costs with purchased seats. When enabled and all licensed seats are in use, the feature blocks new billable users from being added. The system is designed to prevent future overages rather than reverse existing ones, meaning current memberships remain unaffected by the activation of this control. Users who only require authentication, such as those using OpenID Connect providers, can be assigned the non-billable Minimal Access role without consuming paid seats.
The feature has been enhanced to improve integration with identity provisioning, specifically addressing scenarios involving SAML, SCIM, or LDAP provisioning. When restricted access is active and no seats are available, users provisioned via these methods are assigned the non-billable Minimal Access role instead of directly entering billable roles, allowing synchronization to continue while avoiding immediate overages. Additionally, GitLab can automatically deactivate dormant users; when a previously inactive user signs back in, they are placed in a pending approval state rather than being reactivated as billable users, which prevents inadvertent license overages during periods of low activity.
Administrators have improved operational clarity through added guidance on expected outcomes before and after hitting seat limits. The feature functions alongside user cap, where user cap controls approvals regardless of seat availability, while restricted access specifically manages the boundary defined by licensed seats. A key distinction is that restricted access is a seat-limit control, whereas user cap is an approval control; they cannot be simultaneously enabled in the same configuration.
Full Take
The narrative centers on shifting administrative responsibility from manual gatekeeping to automated, identity-driven controls, focusing on predictable cost management tied directly to licensing. The mechanism described—separating the control of *who can access* (user cap) from the control of *seat consumption* (restricted access)—introduces necessary conceptual clarity regarding system constraints versus approval workflows. The evolution of how dormant users handle sign-ins is particularly interesting; moving from silent reactivation to a pending approval state reflects an attempt to reconcile security/automation needs with financial predictability, acknowledging that automated systems can fail in real-world asynchronous environments.
The distinction between user cap (an approval mechanism) and restricted access (a seat-limit mechanism) highlights how complex organizational policies must be segmented into specific operational controls. This structure suggests a pattern of complexity management: creating distinct layers for different types of governance (approval vs. consumption). The inherent friction lies in the interaction described where caching delays behavior, implying that perfect, instantaneous consistency between identity systems and billing constraints is not achievable without trade-offs. The implicit assumption being challenged is whether increasing automation inherently reduces the necessary human oversight; here, it appears to be a restructuring of that oversight—from constant checking to approving exceptions when capacity permits.
What are the downstream consequences if administrators rely solely on the automated state changes? If the pending approval queue is rarely addressed when seats are available, the system successfully prevents overages but creates administrative latency regarding provisioning and reactivation cycles. The pattern suggests that control systems aim for maximal efficiency while creating new friction points where human intervention is required—specifically, managing the transitional states of users or capacity releases. The missing inquiry centers on whether the improved interface guidance fully addresses this latent tension between automated flow and necessary human accountability when dealing with asynchronous identity events.
Sentinel — Human
This text reads like high-quality, detailed technical documentation or an in-depth feature announcement written by someone with direct access to the GitLab platform, focusing on precise operational mechanics.