Summary

  • GitLab Premium counts Guests as billable. Ultimate exempts qualifying Guests, including a custom Guest role whose only added permission is read_code.
  • “Read-only” is an inadequate purchasing specification. Reporter is billable, and a higher role elsewhere in the relevant subscription scope can defeat a local Guest exemption.
  • A newly billable person can fill an already purchased vacant seat. Above purchased capacity, the period’s maximum matters; removing access later does not erase that peak.

Guest is a wonderfully hospitable name for a software role. It suggests a visitor with a modest appetite. At GitLab, the bill depends on what the visitor is allowed to do after arriving.

The company’s seat-management rules, checked on 30 October 2026, count Guests as billable on Premium. Ultimate provides an exemption for Guests who satisfy its conditions. The same person can move outside the paid population because the customer bought a different plan.

That is a useful wrinkle in enterprise software pricing. A vendor can sell a higher tier by adding capabilities and by changing who enters the multiplication. Procurement negotiates the price of a seat. Access administrators help determine how many seats the organisation needs. Their screens belong to the same transaction.

Reading the code can have two price tags

An ordinary Guest has limited participation rights, including work around issues and epics. GitLab’s Guest explanation and permissions table describe a role without ordinary access to private repository code or permission to push code. Reporter can read the code but is billable, even though it cannot push changes.

“Only needs to look” is therefore a conversation starter. The purchasing specification still needs a technical role.

Ultimate has a precise exception. Its custom-role documentation says a role based on Guest, with read_code as its sole additional permission, does not consume a seat. Code-reading access can arrive through a paid role or through that narrowly defined exemption.

Add other permissions beyond the exception and the custom role consumes a seat. A reassuring role name buys nothing. Custom roles extend their base role; they do not subtract its existing powers. Calling a broad role “occasional observer” leaves the capabilities rather less occasional than the label.

Employment status is a poor shortcut too. A contractor may need billable capabilities. An employee may have a task that limited access can satisfy. The productive question is what the person must actually do: comment on an issue, inspect code, or carry out further operations. The answer supplies both the access requirement and the relevant commercial boundary.

Where broader access is needed, the paid seat has a job to perform. Denying it simply to keep the count low can push work into shared identities or unauthorised copies. Making private code public to avoid a permission problem would be an especially extravagant way to save on software. The worthwhile economy is to stop granting capabilities that the work never needed.

The guest may have another badge

A Guest label in one project does not establish exemption across the subscription. On GitLab.com, the relevant namespace has to be examined. A higher, billable role elsewhere in that scope can change the person’s status even while the local project still shows a Guest.

Nor should every project membership be counted as a separate seat. A person in several projects or subgroups within the same subscribed top-level group is counted once. The task is to reconcile a person’s roles within the proper boundary, rather than add up rows from membership lists.

For Self-Managed, the boundary is the whole instance. The documentation flags project creation that can assign the creator Maintainer or Owner and consume a seat. A procedure written to inspect one GitLab.com subscription group cannot simply be carried across to an installation and declared complete. Similar screens can conceal different accounting perimeters.

These rules give a project administrator a small piece of commercial authority. The administrator knows why someone needs access locally. Establishing that person’s billing status may require a view beyond the local project. A permission decision can travel further through the organisation than the person making it realises.

Removing the permission cannot unfill yesterday’s seats

Becoming billable and creating an additional charge are separate events. An organisation may have purchased seats that are still vacant. A newly billable person can occupy one of those seats within existing capacity.

The excess arises when the billable population exceeds the purchased quantity. Then the maximum during the billing period matters. Removing the person or reducing the role afterwards does not erase the maximum already reached. A tidy current membership list can coexist with a less tidy reconciliation history.

The system also allows seats to be reused within purchased capacity. It does not keep adding every distinct person who ever appeared to an eternal guest list. Current occupancy, the relevant peak and the historical list of participants measure different things. A spreadsheet that treats them as interchangeable can manufacture either a saving or an alarm.

GitLab’s overage reconciliation is quarterly or annual according to eligibility. Quarterly reconciliation uses the quarter’s maximum and the documented proration for the remaining subscription term. Annual true-up charges the annual subscription fee for added users. A universal assumption that a brief grant will cost only a few days’ fees has no place in this calculation.

The subscription-management rules put reductions in purchased seat quantity at renewal. Access can be withdrawn now; reducing the contracted purchase follows another clock. The administrator’s ability to reverse a click is faster than procurement’s ability to reverse the quantity.

The higher tier sells a different denominator

GitLab’s public pricing lists Premium at US$29 per user per month, billed annually. Ultimate requires a custom quote. A net saving calculation needs that actual Ultimate quote and the organisation’s distribution of required roles.

The commercial structure is visible without an invented customer invoice. A higher tier can admit a wider fringe of limited participants without charging a seat for each one. When their work expands beyond the exemption, paid capabilities become relevant again. The buyer purchases features and a rule for deciding which participants count.

A suitably narrow role can serve security and cost at once. A broader role can be exactly what the task requires. Both deserve an explicit decision. Handing out the most convenient role by habit and refusing every expansion for budgetary reasons are equally poor substitutes for identifying the work.

The familiar negotiation over “price per user” should linger on its last word. GitLab defines the billable user. The customer helps create that user by assigning permissions. A discount on the first number offers limited comfort if nobody owns the second.