The GitLab seat model decides how many Users a Premium, Ultimate or GitLab Dedicated subscription must cover. A GitLab subscription is bought for a number of seats in one tier, and every account that holds a billable role in the subscribed top-level group or Self-Managed instance occupies one.[10][3] The contractual unit is the User defined in the GitLab Subscription Agreement. The documentation sets out which accounts are billable users and how the maximum users figure behind overage invoices is built.[1][3]
Editions
Seat rules differ by tier and by offering, so the same organisation can see different counts on GitLab.com and Self-Managed.
| Rule | Premium | Ultimate |
|---|---|---|
| Users with only the Guest role | Billable | Not billable |
| Users who are not a member of any group or project | Billable on Self-Managed | Not billable |
| Administrators on Self-Managed | Billable | Billable |
| Enterprise Agile Planning seats for Planner users | Not available | Available as an add-on |
The table follows the Manage seats page retrieved on 2026-10-07.[3] Premium is listed at USD 29 per user per month billed annually. Ultimate has no public price, and its pricing page entry lists “Unlimited guest users”.[2] Catalog rows: Premium, Ultimate, Enterprise Agile Planning.
On GitLab.com a subscription applies to a top-level group, and members of every subgroup and project in that group use its features and consume its seats. A person can belong to two top-level groups with different subscriptions. A subscription cannot be applied to a personal namespace.[6][10] On Self-Managed the subscription covers the instance and “provides the same set of features for all users”.[10]
Metrics
The Agreement defines a User as “the unique and single Individual, employee, Contractor, or other third-party individual or machine authorized by Customer” that needs a seat and can access the purchased Software, whether or not it actually does.[1] The pricing FAQ gives the same idea in shorter form: a user is “each individual end-user (person or machine)” of the customer and its Affiliates with access to the Software.[2] Catalog row: User.
The documentation defines billable users as “users who occupy seats in a subscription and count toward the number of seats purchased in your subscription”.[3] Billable roles are Guest (on Premium only), Planner, Reporter, Security Manager, Developer, Maintainer, Owner and custom roles. A custom role based on Guest with only the read_code permission is the exception.[3] Auditor users are billable, and so are administrators on Self-Managed Premium and Ultimate.[3] Catalog row: Billable user.
For Enterprise Agile Planning, a user occupies an Enterprise Agile Planning seat when the subscription includes such seats and the user’s highest role across the top-level group, subgroups and projects is Planner.[3]
Counting / floors
Billable and non-billable accounts
A user is not billable if they are pending approval; deactivated, banned or blocked; have only the Minimal Access role; or are a GitLab-created service account. That last group covers the Ghost User, the Support Bot, project and group bot users and other internal users.[3] On Ultimate, users who belong to no project or group, and users whose only role is Guest, are also non-billable.[3] Catalog proof: Minimal Access and inactive accounts are non-billable; Machine users are Users unless GitLab-created.
The “person or machine” wording means that an ordinary account used by a script or integration and holding a billable role counts like any other user. Only the service accounts and bots that GitLab itself creates are listed as non-billable.[2][3] Membership is counted once per top-level group: “If a user is in multiple groups or projects that belong to the same top-level group that holds the subscription, they are counted only once.”[3] Catalog proof: A user counts once per top-level group.
The Agreement counts Users “regardless of whether the User actually accesses, or the frequency with which they access, the Software”.[1] Dormant accounts with a billable role therefore count until they are deactivated or blocked. GitLab recommends reviewing accounts before renewal, noting that inactive accounts “Might count as billable users”.[6] Catalog proof: Users count regardless of actual access.
Guest users on Ultimate
Ultimate does not charge for users whose only role is Guest. The documentation adds a condition: “The user must not be assigned any other role, anywhere in the instance for GitLab Self-Managed or in the namespace for GitLab.com.”[3] A Guest who creates a project in their own personal namespace on GitLab.com still does not use a seat, because that project is outside the subscribed group. On Self-Managed, a user who creates a project becomes its Maintainer or Owner. To stop that, GitLab suggests marking such users as external.[3] When a Self-Managed instance moves from Premium to Ultimate, any higher role a Guest already holds anywhere, including in a personal namespace, takes precedence and keeps the user billable.[3] Catalog proof: Guest users are free on Ultimate, billable on Premium.
Self-Managed specifics
On Self-Managed Premium, users without any namespace access are billable; on Ultimate they are not.[3] Administrators are billable on both paid tiers.[3] The documentation calls the Self-Managed model a “hybrid model”: the customer pays for the maximum number of users enabled during the subscription period, and for connected instances that maximum is checked each quarter.[3] If LDAP is integrated, anyone in the configured domain can sign up, and GitLab warns this “can result in an unexpected bill at time of renewal”.[3] Catalog proof: Self-Managed Premium bills administrators and users without namespace access.
Maximum users and seats owed
Users over subscription, also called seats owed, are calculated as the maximum users during the billing period minus the purchased seats.[3] In the documentation’s example, a 10-seat subscription that peaks at 13 billable users owes 3 seats, even though the count later falls to 9 when users leave.[3] On GitLab.com the subscription is described as a concurrent seat model: users can be added and removed freely as long as the total at any time stays within the purchased seats. The Max seats used and Seats owed figures are updated once a day.[3] Catalog proof: Overage is measured on maximum users.
Floors
The Agreement does not allow the customer to report fewer Users than it purchased during the term, and seats can be reduced only at renewal.[1][3] Seats cannot be added through the Customers Portal if the subscription came through an authorized reseller (including the GCP and AWS marketplaces) or runs for several years. In those cases seats are added through the reseller or GitLab sales.[3] Catalog proof: No reduction of users during the term.
Enterprise Agile Planning
Enterprise Agile Planning lets non-engineering users take part in planning without a full Ultimate licence. To use the seats, the customer assigns the Planner role. A Planner who is given a higher role anywhere in the hierarchy, such as Developer or Maintainer, occupies an Ultimate seat instead.[3] The Agile Planning Terms say that Plan Users “may not use, or otherwise access, any other features within GitLab’s Ultimate Software offering during the Subscription Term”. Customers must also keep the Optional Data usage ping enabled throughout the term.[7] If verification shows Plan Users using other Ultimate features, GitLab may invoice the Upgrade Price for each Plan User, prorated for the rest of the term, “regardless of whether an Order Form has been signed by Customer”.[7] Catalog proof: A Planner with a higher role uses an Ultimate seat; Plan Users are limited to Agile Planning Features.
Seat controls
GitLab provides two settings that stop overages before they happen. A user cap sets the maximum number of billable users; once it is reached, a group Owner or administrator must approve each new user. On GitLab.com the cap cannot be enabled while any group or project is shared outside the namespace hierarchy.[3] Restricted access, generally available in GitLab 18.0, blocks new billable users when no purchased seats remain. It leaves existing members untouched, and the two settings cannot be used together.[3] On Self-Managed, GitLab turns on restricted access automatically when a subscription does not allow overages.[3] With restricted access on and no seats free, users provisioned through SAML, SCIM or LDAP get the non-billable Minimal Access role instead of their configured role.[3] The documentation lists known gaps. Simultaneous additions by several Owners can still exceed the seat count, and renewing through GitLab Sales for fewer users than are active creates an overage for the difference.[3]
Virtualization & partitioning
Seats are counted per top-level group or per instance, not per server, so virtualization does not change the count. For Self-Managed, one activation code can be applied to several instances “if the users are: Identical to your licensed production instance” or “A subset of your licensed production instance”, however they are arranged in groups and projects.[5] GitLab’s licensing policy adds that, when a single code covers several instances, GitLab identifies the instance with the highest billable user count and uses it for billable users, maximum users, quarterly reconciliation and auto-renewal.[4] Two teams of 20 and 30 users on separate instances need either two subscriptions or one 50-user subscription applied to both. A single 30-user subscription is not enough.[4] A production code may also be applied to a development environment, with the same user restrictions.[4] Catalog proof: One activation code for several Self-Managed instances.
Cloud / BYOL
Seats bought for GitLab.com cannot be used on Self-Managed or the other way round; each offering needs its own subscription.[4] The licensing policy also limits deployment by geography. Licences may be used only within the “Geographical Region”, defined as 4,000 miles (6,437 km) of the Sold To address on the quote, unless GitLab agrees in writing.[4] Its example: 25 spare licences bought in India cannot be deployed to a team in California.[4] Affiliates may buy under one master agreement or receive licences bought by another group company, subject to these conditions.[4] Catalog proof: Geographical Region for licence deployment; Separate subscriptions per offering.
Programs
The Free tier on GitLab.com allows up to five users in a top-level group with private visibility. Above that the namespace is placed in a read-only state, in which merge requests, pipelines, package publishing and container image pushes are blocked.[8][9] The limit does not apply to public groups, paid tiers, community programs or Self-Managed Free.[8] GitLab’s licensing policy counts the five-user maximum in aggregate per customer, so a customer cannot split a larger team across several Free groups.[4] Catalog proof: Five-user limit on GitLab.com Free.
Overage billing through quarterly reconciliation or annual true-up is covered in GitLab quarterly reconciliation and true-ups.
Out of scope
GitLab Duo seats are a separate count, covered in GitLab Credits, Duo and Flex. Compute minutes and storage are quotas, not seats; see GitLab offerings, compute minutes and storage. This page does not cover identity provider configuration beyond its effect on seat consumption.