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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。