Updates to paid tiers for improved billing and subscription management
Overview
GitLab announced changes to improve the billing and subscription management experience for customers. These changes and your new subscription agreement will be applicable at your next renewal on or after August 1, 2021. We announced 4 key changes:
Changes applicable to both SaaS and self-managed customers
- Quarterly subscription reconciliation - Users added during a quarter will only be charged for the remaining quarters of their subscription term as opposed to the full annual subscription fee(s) with annual true-ups - resulting in significant savings for add-on Users.
Changes applicable to self-managed customers only
- Auto-renewals - To make the renewal process more seamless for customers and more efficient for GitLab, similar to our SaaS subscriptions, all self managed subscriptions will now be set to auto-renew, with an option to manually cancel in the GitLab Customers Portal anytime up to thirty (30) days before renewal.
- Cloud licensing - Self-managed customers will be able to activate their GitLab instances via an activation code and manage their GitLab licenses using the GitLab Customers Portal. License data such as subscription tier, active users, guest users and inactive users will be synced with GitLab daily to facilitate quarterly subscription reconciliation and auto-renewals.
- Operational Data - To enable consistent customer success services for paying customers, self-managed instances will be required to share aggregated operational data that indicates the adoption of product use cases or features. Like SaaS service usage data, operational data for self-managed instances such as number of projects, issues, pipelines, and merge requests will be aggregated for each self-managed instance and will not contain any personal information or project-specific information. This operational data will be used by customer success services to help customers understand their usage, identify adoption issues, provide use case enablement, and recommend best practices for a successful customer journey. Please see our service usage data page for the full list of usage data and its use.
These changes are applicable to customers purchasing or renewing a GitLab subscription on or after August 1, 2021. For existing customers, these changes are applicable at their next renewal. At purchase or renewal -
SaaS customers can benefit from the changes at their next renewal on or after August 1, 2021 Self-managed customers can benefit from the changes by installing/upgrading to version 14.1. Existing customers can upgrade at their own pace - GitLab will support the current license management process on 13.x versions and 14.x versions, until further notice.
These changes are only applicable to customers using any of GitLab's paid tiers. For existing customers, these changes will be applicable at your next renewal after the effective date.
Quarterly subscription reconciliation will be applicable for both SaaS and self-managed customers. Auto-renewals, cloud licensing and operational data collection will be applicable for self-managed customers. To benefit from these changes, self-managed customers will need to be on version 14.1 (releasing on July 22, 2021)
The changes are not applicable to
- Free tier users and users of our community programs (GitLab for Education, Open Source and Startups).
- For customers purchasing GitLab via channel partners / resellers, quarterly subscription reconciliation and auto-renewals will not be available at launch - but will be made available subsequently.
No, self-managed customers will need to be on version 14.1 (releasing on July 22, 2021) which enables cloud licensing and will need to activate the self-managed instance using the activation code. This is required to take advantage of quarterly subscription reconciliation, auto-renewals and cloud licensing.
Cloud licensing
Cloud Licensing is a new and easier way to manage licenses for self-managed subscription plans. It introduces two major capabilities.
- Activation - is the ability to unlock plan features and activate a self-managed instance via an activation code. Previously, customers needed to manage license files and manually upload them to their instance.
- License sync - is the ability for a self-managed instance to sync subscription data between itself and GitLab. Previously, an instance would not update automatically to any subscription changes including add ons or renewals, requiring manual generation of new license files
These capabilities make activation, provisioning, subscription reconciliation and renewal seamless for customers.
Customers will receive a confirmation email with the activation code upon purchase. By logging into the Admin Area of the customer's GitLab instance, the customer can then use the code to activate the instance. Once the instance is activated, a nightly job will generate a payload that sends the number of active users, tier, etc., back to GitLab. This data will be used to enable quarterly subscription reconciliation and auto-renewals, and to improve license management (described in subsequent sections).
Existing customers can upgrade at their own pace - GitLab will support the current license management process on 13.x versions and 14.x versions until further notice.
We understand that you may be unable to automatically share required license data to GitLab due to network limitations (e.g. air-gapped instances, restrictive firewalling, etc.).
If your organization policies allow you to add an IP or domain to your allow list as per these instructions, you can still share license data to GitLab.
If that is not an option, for now, you will need to continue to use the annual true-up model. We are investigating ways we can allow for manual submission of required license data without needing an active internet connection. When available, we'll update any affected customers.
Quarterly Subscription Reconciliation
Annual true-ups were confusing and frustrating for customers. With quarterly subscription reconciliation, users added during a quarter will only be charged for the remaining quarters of their subscription term as opposed to the full annual subscription fee(s) with annual true-ups. Customers stand to gain substantial savings for add-on users as there is no retroactive charge. For example:
| Quarter in which users are added | Payment period with quarterly subscription reconciliation | Savings per add-on user |
|---|---|---|
| First | Remaining three quarters only | 25% |
| Second | Remaining two quarters only | 50% |
| Third | Remaining one quarter only | 75% |
| Fourth | Next subscription period only | 100% |
Under no scenario will the license cost for add-on users in the quarterly subscription reconciliation model be higher than in the annual true-up model.
In the current annual true-up model, you pay for the full subscription period in which these users were added. For example, if your subscription term starts Sep 1, 2021 and ends Aug 31, 2022 and you add 100 users on May 15, 2022 - you pay for those 100 additional users for the full subscription period even though the users were only added in the third quarter of your subscription period.
In the quarterly co-terms model, new users are accounted for after the quarter in which they are added. In the same example as before, if your subscription term starts Sep 1, 2021 and ends Aug 31, 2022 and you add 100 users on May 15, 2022 (third quarter), you will now pay for those 100 additional users only starting from Jun 1, 2022, the fourth quarter of your term.
If you increase the number of users in a specific quarter, with that overage reconciled and paid for, and then reduce the number of users in the next quarter, you will not be subject to quarterly subscription reconciliation. The number of billed users will be same as the previous quarter.
For example, your subscription term starts Sep 1, 2021 and ends Aug 31, 2022. If you add 100 seats on October 15, 2021, you will pay for the additional 100 seats from the quarter starting Dec 1, 2021. If you remove 25 seats on Jan 15, 2022, you will not have any overage, and therefore no quarterly reconciliation. The number of billed users for the quarter starting Mar 1, 2022 will be the same as the previous quarter (i.e., 100)
Quarterly subscription reconciliation is only applicable for users added above the number of users in your subscription. It does not apply to the base subscription user count.
For example, if you signed up for a subscription for 100 users and during the quarter you only used 75 seats, there is no reduction in your annual subscription amount.
These changes are applicable to all new and existing SaaS and self-managed customers.
For existing customers, these changes will be applicable at your next renewal on or after the effective date. For new customers, these changes will be applicable when you subscribe to GitLab after the effective date.
These changes are not yet available to customers who purchase GitLab through a reseller or channel partner, but will be made available subsequently. Please contact your reseller or channel partner and GitLab channel manager to benefit from these updates.
Existing SaaS and self-managed customers can take advantage of these changes at their next renewal after the effective date. Self-managed customers will need to have cloud licensing enabled and be on version 14.1+. If you would like to avail these changes before your renewal, please reach out to your sales representative for more information.
In a future release, we will make the ability to avail cloud licensing before your renewal self-service - details of which will be announced when available.
You will receive an email within 3 days of your quarterly reconciliation date with details of the reconciled seats. Your credit card will be charged within 10 days of the quarterly boundary of your renewal date with the reconciled amount for additional seats added during the previous quarter.
For example, if your subscription has 25 users, your term is Sep 1, 2021 to Aug 31, 2022 and you add 15 users on October 15, 2021, then:
- Around Dec 3, 2021, you will receive an email informing you that you will be billed for 15 additional seats
- Around Dec 10, 2021, your credit card will be charged for the 15 additional seats and your contract will be amended to 40 users.
- If credit card payment fails, you will be reverted to annual true-ups for your subscription term, as stated in our terms.
You will receive an email within 3 days after your quarterly reconciliation date with details of the reconciled seats. An invoice will be generated and emailed to your billing contact within 10 days of the quarterly boundary of your renewal date with the reconciled amount for additional seats added during the previous quarter.
For example, if your subscription has 25 users, your term is Sep 1, 2021 to Aug 31, 2022 and you add 15 users on October 15, 2021, then:
- Around Dec 3, 2021, you will receive an email informing you that you will be billed for 15 additional seats
- Around Dec 10, 2021, you will receive an invoice for the 15 additional seats and your contract will be amended to 40 users.
- The payment of the invoice will follow the GitLab payment terms and conditions
Auto-renewals
Subscriptions on GitLab SaaS are already on auto-renewal. This has made the renewal process more seamless for customers and more efficient for GitLab. After their next renewal, all subscriptions for self-managed customers will be set to auto-renew, with an option to manually cancel in the GitLab Customers Portal anytime up to thirty (30) days before renewal.
You can cancel auto-renewal a minimum of 30 days prior to your renewal date. To do so, either select the "Cancel subscription" button in the GitLab Customers Portal, or reach out to your GitLab sales representative to provide notice.
These changes are applicable to all new and existing SaaS and self-managed customers. For existing customers, these changes will be applicable at your next renewal after the effective date.
These changes are not yet available to customers who purchase GitLab through a reseller or channel partner, but will be made available subsequently. Please contact your reseller or channel partner and GitLab channel manager to benefit from these updates.
Auto-renewal will be at the per user list price as documented on our pricing page.
You will be billed for either the total number of active users on the date of renewal or the current subscription quantity, whichever is higher.
For example, if your maximum number of users during the 4th quarter of your subscription is 120, but on the last date of the quarter you have 103 active users, you will auto-renew for 120 users.
Auto-renewal is a terms-of-use change and not a change to your payment methods. If you're a customer without a credit card on file, GitLab will generate an invoice for your auto renewal. You can still process your renewal payment via GitLab sales or channel partner or distributor of GitLab. Customers that require purchase orders will continue to process their renewal via GitLab sales or a channel partner or distributor of GitLab.
You can cancel auto-renewal a minimum of 30 days prior to your renewal date. Non-payment of your subscription fees will follow the termination terms as per our subscription agreement.
Operational Data
To enable consistent customer success services for paying customers, self-managed instances will be required to share aggregated operational data that indicates the adoption of product use cases or features. Operational data for self-managed instances such as number of projects, issues, pipelines, and merge requests will be aggregated for each self-managed instance and will not contain any individual user's personal information or project-specific information. This operational data will be used by customer success services to help customers understand their usage, identify adoption issues, provide use case enablement, and recommend best practices for a successful customer journey. Please see our service usage data page for the full list of usage data and its use.
Please refer to the customer success services page for details on the service offering.
There are two categories of data collected:
| Category | Why it's important | Status |
|---|---|---|
| Operational Data | Data essential to operate the product, to aid primary product improvement use cases and provide proactive support to customers with self-managed instances. | Always on by default |
| Optional product usage data | Data to aid secondary product improvement use cases | Turned on by default. Can be disabled by customer |
Previously, data was not classified in these categories.
With this change, the license data and operational data cannot be turned off by the customer without a contract change. Please contact your GitLab Sales Representative for assistance.
These changes are applicable to all new and existing paid tier self-managed customers. Operational data for SaaS customers is already available on GitLab SaaS.
For existing customers, these changes will be applicable at your next renewal on or after the effective date. For new customers, these changes will be applicable when you subscribe to GitLab after the effective date.
Any data necessary to operate the product is classified as operational data. A sample list of the data classification is here.
We understand that you may be unable to automatically share required license data to GitLab due to network limitations (e.g. air-gapped instances, restrictive firewalling, etc).
If your organization policies allow you to add an IP or domain to your allow list as per these instructions, you can still share license data to GitLab.
If that is not an option, for now, you will need to continue to use the annual true-up model. We are investigating ways we can allow for manual submission of required license data without needing an active internet connection. When we have those plans we'll update any affected customers.
There is no personal information or project specific information collected from self-managed and/or SaaS customers in the Operational Data data set, therefore the data collection is in compliance with the GitLab Privacy Policy.
More information
To address your questions and feedback, we have created a space in the GitLab Community Forum that is actively monitored by GitLab Team members involved with this change.
If you have more questions or need clarifications, please contact your GitLab Sales Representative or GitLab Support.