root) that came installed if I am also an administrator?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.
Please take a look at our getting started with subscriptions page 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.
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.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.
Currently we do not have a self-service option to for adding additional users to your subscription outside of initial purchase and renewal periods. You can add users to your GitLab.com group as needed, however you won't be billed for these until the renewal cycle. If you would like to be billed offcycle for additional users please contact support via our support form and select Licensing and Renewals Problems from the form menu.
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:
If 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 Purchase History 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.
