root) that came installed if I am also an administrator?Please complete our sales form and your account manager or a member of our Sales team will be in contact with you.
You can purchase a subscription for GitLab Enterprise Edition (self-managed) or for GitLab.com (hosted by GitLab) on our Customers Portal with a credit card.
You can find pricing for GitLab.com subscriptions on our pricing page here and GitLab Enterprise Edition (self-managed) here.
All subscriptions are paid in annual payments, monthly payments are not an available payment option.
When purchasing via our Customers Portal you may pay via credit card. We are able to accept payment via check and wire in select circumstances, to get help with other type of payment methods please contact our sales team via our sales form.
To apply a GitLab.com subscription you'll need to have:
If you've met all those conditions, continue on to How do I use my subscription?.
To apply a GitLab Self-managed license, you'll need to have:
Please take a look at our subscription docs for information on getting set up, applying, and managing your subscription.
The following will be emailed to you:
Admin Area -> Users to view the Active Users tab which indicates the users currently
counted.Admin Area -> Overview -> Dashboard to view users available in license and users over license.sudo gitlab-rails runner 'p User.active.count' to obtain the Active User count.sudo gitlab-rails runner 'p ::HistoricalData.max_historical_user_count' to obtain the Maximum billable user count.GET /users to obtain a list of all billable users.In order to renew, send an email to education@gitlab.com with the following information:
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.
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.
If you've added more users to your GitLab EE instance during the past period than you were licensed for, the additional users will be payable at the time of renewal.
Without adding these users during the renewal process, your license key will not work.
You can find the number of users over license by going to the /admin
section of your GitLab instance (e.g. https://example.gitlab.com/admin). This
can also be found by clicking the admin wrench in the navbar of your instance
when logged in as an admin.
In the top right section of the admin dashboard, you should see the number to enter when asked this during the renewal process.
Each unique user within a namespace is counted in a subscription. This includes users added at the group level, sub-group level and project level. Every occupied seat, whether by person, job or bot is counted in the subscription. The only exception are members with Guest permissions with an Gold subscription.
Since GitLab.com counts concurrent seats and not named users, you can remove members and add new members as you'd like as long as the total users at any given time is within your license count.
Every occupied seat, whether by person, administrator, job or bot is counted in the subscription.
The following are the only exceptions which are not counted towards the subscription:
Guest permissions on an Ultimate subscription do not count towards the subscription.Migration Bot, and Alert Bot do not count towards the subscription.The Maximum Users value found in self-managed instances of GitLab reviews the daily active user counts 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 refelective of the entire subscription term, but rather for the 12 months prior to the expiration date.
root) that came installed if I am also an administrator?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.
It is possible to obtain a free evaluation of our GitLab.com or self-managed subscriptions for a 30 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.
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.
You can add users to your subscription any time during the subscription period. The cost of additional users added during the subscription period will be prorated from the date of purchase through the end of the subscription period.
To do this:
The following will be emailed to you:
On GitLab.com, there is a 10 GB repository size limit per project. Effective November 1st, 2020, you can now purchase additional storage within our Customers Portal.
To do this:
Buy storage subscriptionnamespace > Settings > Usage Quotas > StorageIf your GitLab instances cover the exact same set of users (e.g., for backup, high availability, failover, testing, and staging), you can use the same license file for all of them.
However, if you're running multiple production instances with different mixes of users, you will need an individual license for each instance.
Once the subscription has expired, the system will revert to the Free tier and users will no longer see paid features, however no data will be lost.
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.
If a subscription is applied to a personal account then that account will have access to the features of the subscription for all of the projects they create under their personal account. If they want, other users can be invited to those projects and they'll be able to enjoy the features of that subscription only while working on those projects. If that user then creates a group, it will by default be on the Free plan.
A user that never collaborates with others on GitLab may opt to purchase a subscription for their personal user account since they have no need for a group and will always only work in projects under their personal account.
You can find the plan details for a personal namespace by navigating the User Settings>Account>Billing.
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 (Bronze, Silver, Gold) 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.
You will first need to create your group in GitLab.com and add users. Follow the steps below:
Please submit your request via our support form and select Licensing and Renewals Problems from the form menu. Note, only purchases made within the last 45 days are eligible for a refund.
Your invoice should be available for viewing and download within our Customers Portal by navigating to the View invoices page. If your invoice is not available, please submit your request via our support form and select Payment Failures and Refund from the menu.
We issue self-managed GitLab 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.
You can always contact us via our support form as the next term approaches otherwise someone will be in touch as well.
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/resellers/program.
Currently, we are not able to transfer plans on a subscription. In order to make use of a gitlab.com 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. Note, only purchases made within the last 45 days are eligible for a refund.
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.
You can get a list of billable users by going to your group namespace, click on Settings and then Billing; scrolling down on the page you will see the users occupied seats in your group along with the total number of users.
We had also released a groups and members API endpoint that can be used to obtained a list of billable users for your plan.
The obtained list will provide the existing members on your account at the time of the request. If you are looking for the specific date and time in which a user was added to a group, please use the Audit Events feature or Audit Events API.
