Licensing and subscription FAQ
Subject to certain conditions, yes. Please see Acceptable Use of User Licenses Policy.
No. The license is stored in the database and will be replicated to all your application instances. Therefore you only need to upload the license file to one application instance.
No. The license is stored in the database and is replicated to all instances. You only need to upload the license to your primary Geo instance.
Generally, every user that occupies a seat in the subscription counts as a billable user. However, some categories of users are not counted in the subscription. Learn more about how seat usage is determined for users on GitLab.com and self-managed.
The number of users over subscription (or seats owed) shows how many users are in excess of the number allowed by the subscription, in the current subscription period. On GitLab self-managed, the users over subscription value is always zero for trial licenses.
Nope! The root
user is just the first admin account, created by default in self-managed versions of GitLab. Just like any other user, this account does occupy a license seat. So, please consider following good security practice and have one or more "real" people play the role of administrator. You're allowed (and encouraged) to rename the user, or even delete or disable it as long as you've promoted other users to administrator.
For GitLab.com subscriptions, you can view a list of billable users in the Billing section.
For Self-managed subscriptions, you can view a list of billable users in the Admin section or through a Rails console session.
In GitLab 13.7 and later, the number of maximum users reflects the highest number of billable users on your system for the current license period. See the question Who gets counted in the subscription?
in this same section.
You can also consider restricted access to better control your maximum user count.
Prior to GitLab 13.7, the Maximum Users
value found in self-managed instances of GitLab reflects the maximum daily active user count recorded in the instance for the period of 1 year prior to the expiration date of the license. Since most GitLab subscriptions are annual, this means the Maximum User count in these cases is simply the highest number of active users at any one time during that subscription. However, for non-standard contract lengths (8 months, 14 months, 24 months), the Maximum Users count is not reflective of the entire subscription term, but rather for the 12 months prior to the expiration date.
The seats for your license are generic and are not specific to a user. GitLab does not use a named license model.
The seats you buy can be distributed however you choose. If a user leaves your organization, you can remove or block that user to free the seat. This seat can then be used by another user.
Note that this may result in a user over license if your maximum users has been reached.
Please see instructions on how to add more users for GitLab.com or Self-managed subscriptions.
Maxmimum Users will be reset once the current license is expired and a new license with a new service period is uploaded.
Users over license can be reset either:
- During the current license service period by Adding more seats to the subscription so that your total Users in License meet or exceed your current
Maximum Users
- By paying for quarterly reconciliation or true-ups per quarter or at your renewal.
Please take a look at our subscription docs for information on getting set up, applying, and managing your subscription. Support Bot, Migration Bot
, and Alert Bot
do not count towards the subscription.
Currently, we are not able to transfer plans on a subscription. In order to make use of a SaaS subscription or a self-managed subscription, you will need to purchase a new subscription. You can do so by logging into the Customers Portal and selecting the Buy new subscription
button.
If you need to migrate your data from your self-managed instance to your gitlab.com account, please see our migration docs. Migrating data from gitlab.com to a self-managed instance is a similar process; the main difference is that users can be created on the self-managed GitLab instance by an admin through the UI or the users API.
GitLab.com Subscription
To apply a GitLab.com subscription you'll need to have:
- Created a GitLab.com account
- Linked your customers.gitlab.com account with your GitLab.com account
- Owner permission in the place you want to apply the subscription
If you've met all those conditions, continue on to How do I use my subscription?.
Self-managed Subscription
To activate a GitLab Self-managed subscription, you'll need to have:
- Administrator access to the GitLab installation
Only one top-level namespace (group) can be covered by a single GitLab.com subscription, and all sub-groups under that namespace will share that subscription.
If a customer wants to use the purchased subscription in more than one top-level namespace , then they can follow the approach of Converting a top-level group into a subgroup by transferring it to the appropriate licensed group.
If you are unsure of your renewal date, you will be notified in GitLab 15 days before your expiration date.
If you have auto-renewal on, you will instead receive appropriate email notifications.
GitLab.com
Please see this documentation for instructions on how to renew your GitLab.com subscription.
Self-managed GitLab
Please see this documentation for instructions on how to renew your self-managed subscription.
Administrators of self-managed instances can find user usage through the following options:
- Within GitLab UI, select
Admin Area -> Users
to view the Active Users tab which indicates the users currently
counted. - View the User Statistics panel from
Admin Area -> Overview -> Dashboard
to view users available in license and users over license. - Run the command
sudo gitlab-rails runner 'p User.active.count'
to obtain the Active User count. - Run the command
sudo gitlab-rails runner 'p ::HistoricalData.max_historical_user_count'
to obtain the Maximum billable user count. - Run the command
GET /users
to obtain a list of all billable users.
GitLab Education Program
In order to renew, send an email to education@gitlab.com with the following information:
- Indicate the number of seats for the renewal. Seats can be added at this time if needed.
- Describe the use case for the license. Specifically, we need verification that the use meets the End User License Agreement. Note that University infrastructure operations and information technology operations do not fall within the stated terms of the Education Program. See the FAQ here.
- Include the full name, email address, and phone number of the primary contact who will be signing the renewal quote. Only signatures by faculty or staff with proper signing authority on the behalf of the University will be accepted.
Once we receive the above information, we will process the request and return a renewal quote for signature. Please allow a minimum of 2 business days for return. Email us at education@gitlab.com with any questions.
GitLab Open Source Program
All requests for our GitLab Open Source program (even renewals) must be made via the application process found here.
If you have any questions, email the team at opensource@gitlab.com for assistance.
To renew your subscription at a lower seat quantity, please see the following documentation for GitLab.com or Self-Managed
Please check your inbox for any prior email notifications that may explain why the renewal has not gone through. If you are paying with a credit card, it may have been declined for various reasons. If they do not apply or you encounter other payment errors, please contact support.
If you are not sure how to renew your subscription, please reach out to your account contact or contact sales if you do not know who your account contact is.
For more information and a breakdown on Quarterly Subscription Reconciliation, see the documentation.
- On the day your subscription expires, you will enter a grace period of 14 days so you have adequate time to renew your subscription. Please read how this could differentiate for GitLab.com and Self-managed subscriptions.
- During the grace period, your subscription may still be eligible to receive support. Please reach out to your account contact to further discuss prior to submitting a support ticket.
Your group billing page will show an upcoming renewal until the expiration date of your existing subscription, even if you have already renewed. It will be updated automatically to the new subscription period once your existing subscription expires. For example, if your existing subscription ends on 2023-01-31 and you renewed on 2023-01-20, you will still see an upcoming renewal until 2023-01-31. After this date, your subscription end date will reset to 2024-01-31 if you renewed for 1 year.
It is not possible to downgrade a subscription after it has been purchased or renewed. A separate subscription for the desired plan and seat count will need to be purchased, and your existing subscription will only be eligible for refund per the terms of our Subscription Agreement.
If you would like for your namespace to nevertheless be manually downgraded to the Free tier before the subscription has expired, please submit your request via our support form.
Please note: Manually downgrading a namespace will not make the subscription eligible for refund.
You can find pricing for GitLab.com subscriptions on our pricing page here.
All subscriptions are paid in annual payments, monthly payments are not an available payment option.
Credit Card - When purchasing via our Customers Portal you may pay with a credit card for a self-service experience. This credit card will also be used for any future purchases and will automatically be used for a renewal if you have auto-renewal on. If you wish to not purchase via our Customers Portal but still want to use a credit card, you will have to work with our sales team.
Wire - You will have to work directly with our sales team so they can set you up for wire transfers. For your first and future payments, you will be emailed an invoice that will include instructions with bank details and remittance.
Check - Similarly to wire transfers, you will have to work directly with our sales team.
For possible issues and solutions, see My renewal is not going through or is having payment issues, what should I do?
in the Purchases and payments section.
If you do not know who your account contact is, please complete our sales form and your account contact or a member of our Sales team will get in touch with you.
You can view and download your invoice in the Customers Portal, under Invoices. If your invoice is not available, please submit your request via our support portal.
If you have an Account Contact, please contact them to begin the process of requesting a refund.
If you do not have an Contact, please submit a request via our support portal to get in contact with our Billing team.
You won't be charged if you haven't made any purchase. If you see 1 USD charge in your account, this is for credit card validation purpose. It happens when:
- You use your credit card for the first time
- You validate your GitLab.com account with your credit card
The amount will be return to your account within the next 5-30 days depending on your card issuer bank.
We issue self-managed GitLab legacy licenses in 12 month increments and check-in at the start of each subsequent term within the subscription period to see if there are any changes to users needed prior to generating the license. If you are using Cloud Licensing or Offline Cloud Licensing, your license will be generated for your entire subscription term.
You can always contact us via our support portal as the next term approaches otherwise someone will be in touch as well.
On GitLab.com, there is a 10 GiB repository size limit per project. Effective November 1st, 2020, you can now purchase additional storage via GitLab. To do that, please follow the steps from our documentation.
It is possible to obtain a free evaluation of our GitLab.com or self-managed subscriptions and Duo Enterprise for a 60-day period for up to 100 users. Please visit our free trial page to sign up.
For self-managed users, when you decide to purchase a subscription, you will be issued a new license key. Should you not take out a subscription, your key will expire at the end of your evaluation period. At that point you should remove the trial key and the system will revert to our free Core version.
Since trial is activated per namespace basis, it cannot be transferred. However, Customer can start a new trial for a group by clicking on Start an Ultimate trial
in the group's billing page.
You will first need to create your group in GitLab.com and add users. Follow the steps below:
- Create a group in GitLab.com
- Add users to the group
- Log into the Customers Portal to purchase the desired plan for your group.
- Select the GitLab.com subscription plan using the Order (Premium SaaS, Ultimate SaaS) Plan button
- From the This subscription is for dropdown, select the group name you've created
- Select the Proceed to checkout button
A subscription for GitLab.com can be applied to one of two types of namespaces. Where you assign your subscription determines where those features are accessible.
GitLab.com SaaS Plan on Personal Namespace
Note, As of November 17, 2020, GitLab no longer offers new subscriptions for personal namespaces.
You can find the plan details for a personal namespace by navigating the User Settings>Account>Billing.
GitLab.com SaaS Plan on a Group
A user can choose to purchase a subscription and apply it to a group they've created. This way any project they create in that group or in a
subgroup of that group gets access to the features of the subscription they purchased for it. This extends to any user that gets invited as a member of that group.
A user that's part of an organization with multiple GitLab collaborators will ideally choose to create a group for that organization, purchase and apply a subscription to that group, and then invite their colleagues to that group so that all can
enjoy those paid features while working in that group.
Note that all members within a group subscription are counted as billable seats at the same subscription plan rate.
You can find the plan details for a group namespace by navigating the Group Settings>Account>Billing.
You can create a parent group and only allow access to this group to anyone who should have unlimited child subgroup/project access. Then, create subgroups for each team with nested projects and add people at the subgroup level. This will essentially lock them out of any other team's subgroups for which they do not have access.
In this situation, regarding billable users - you will only be responsible for the unique users within the hierarchy of the parent group. If a user is added to multiple subgroups or projects, they will only be counted as 1 billable user.
We don't currently support reseller purchasing via the portal. If you are a
reseller looking to purchase GitLab on behalf of your client, please get in
touch with us using the Contact sales form.
If you include your billing contact name and email, your physical billing
address, and the end customer's name, email address and shipping address, we
will send you (not your customer) a resellers quote which you can execute
either with a credit card or an EFT.
You can find details on our reseller program at https://about.gitlab.com/partners/program/.
See Acceptable Use of User Licenses for user licensing documentation.
Ready to get started?
See what your team can do with the most comprehensive
AI-powered DevSecOps platform.