Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Pricing model

On this page


Pricing affects product, marketing, and sales. Therefore, general pricing decisions are made by the CEO.

Product makes most decisions on a day-to-day basis about what feature should go in what plan based on the paid tiers.

Four tiers

We have four pricing tiers. How we make decisions on a day-to-day basis is specified on our stewardship page.

Self-managed tier Core Starter Premium Ultimate Free Bronze Silver Gold
Per user per month $0 $4 $19 $99
Likely Buyer Individual Contributors Manager Director Executive
Main competitor None Atlassian GitHub Collabnet
Type of sell No sell Feature Benefit/solution Transformation

Buyer Based Tiering Clarification

When considering buyers as part of product tiering decisions we use the following guidance:


Understanding the distinction of our buyer-based model can be difficult. In it we focus not on the user of the feature, but on the buyer and in what cases a feature would be useful to that buyer even in cases where the buyer is not the user. When making these decisions we ask questions like:

Below we list product categories and the current and proposed features which reside in a given tier to highlight how the buyer-based model works in practice.

Feature - Kanban Boards

Feature - Merge Requests

Feature - Pipelines

Separate names

We have separate names for .com and self-managed tiers because:

  1. Although we want feature parity some features are not available for .com or self-managed, having separate names makes it easy to indicate this in our release post and documentation.
  2. It prevents ambiguity around .com and self-managed when customers interact with us, for example support questions are handled differently based on this.
  3. It prevents ambiguity around .com and self-managed inside the company, for example when calculating margings.

That being said, we want the .com and self-managed tiers to be as similar as possible. For example if a feature is in premium it should be in silver instead of bronze or gold.

Type of sell

Hybrid sales model

There is a big price difference between the different tiers (0$, $4, $19, $99 per user per month, a price difference of infinite, 5x, 5x). For GitLab Inc., the majority of revenue comes from large enterprises buying the top two tiers.

Most companies in a similar situation would focus only on the highest tiers. There will be pressure to increase our lowest tier to $8, for example. But we want to make a our hybrid model work for the following reasons:

  1. We want to keep being a good steward of the open source project.
  2. The lower two tiers are a scalable way to create future customers.
  3. If organizations are already using Atlassian JIRA, we want to be competitive with Bitbucket on pricing. If they buy Bitbucket, it is hard for us to win them back. If they buy GitLab, they discover that it can replace JIRA, and over time they might buy a higher tier.

Raising the price of the lowest tier will prevent people from starting with GitLab. It will raise short-term revenue at the expense of our long-term market share. Instead of raising prices, we should focus on communicating the value of the higher tiers. This will get easier over time, as we introduce more features. In 2016, sales people focused on free vs. starter; in 2018, on starter vs. premium. Hopefully, in 2020, on premium vs. ultimate.

Charging $8 for the lowest tier and discounting aggressively when we're up against Bitbucket doesn't work. It is unfair to customers who are not aware of this discount, and most customers are self-serve (we never talk to them).

You can also check the viability of the different tiers by the conversion from tier to tier. For example, if 5% of users upgrade from free to starter, starter to premium, and premium to ultimate, your prices are balanced. If many more people upgrade from free to starter than from starter to premium, then starter is underpriced. Please note that when a customer chooses starter over premium, that is much more visible to us than users not buying at all, and this might cause us to focus too much on the first case.

A conversion rate of 5% for installations / organizations should not be confused for 5% of the market revenue. There are organizations of different sizes, and larger ones are more likely to pay and purchase a higher tier.

A 5x higher price doesn't mean there is 5x more value, just like the Starter tier doesn't provide infinitely more value than the gratis Core tier. When deciding between tiers, organizations should look at the ratio between how much extra value they get divided by how much extra they pay. If this ratio is comfortably above 1, it makes sense to move to a higher tier. The value is in making people more effective, saving time on integrating tools, driving faster time to value, and retiring other tools. This should more than pay for the increased price of a tier. An analogy would be Apple's iPhone: it is twice as expensive as an average Android phone, and while it doesn't deliver twice as much value, the extra value is worth the extra cost.

A low price for the lowest tier is also how we mitigate the first risk of only selling a suite.

As Stripe documented: hybrid is hard, because "The most common result of attempting both models simultaneously is that only one of the models receives any traction, and (because these models weave themselves into all operations of the company) it typically strangles the other."

Combining features in plans

We tried selling one feature at a time, but this was not feasible. An improved version of that would be selling 7 main features, instead of 3 plans. Examples of main features would be: High Availability, Security, Service Desk, etc.

The advantages are:

  1. Gradual upgrading to more expensive features.
  2. Pay only for the features you use.
  3. Add-ons are a common way of selling this.

The disadvantages are:

  1. It is suboptimal for both the buyer and GitLab Inc..
  2. It is hard for the buyer to estimate how much of each feature they will need.
  3. The complexity lengthens the sales process.
  4. For users, it is unclear what features they can use.
  5. The true-up process becomes more complex.
  6. The customer has to administer a process for how users can get more features.
  7. Features get less usage, and therefore the improvements are slower.
  8. It is hard to do with a hybrid sales model, where there is a 25x difference between the lowest and highest paid plans.

We currently think the disadvantages outweigh the advantages.

Multiple plans for one customer

We considered selling multiple plans to the same customer, allowing them to have some users on every plan.

The advantages are:

  1. Gradual upgrading to more expensive features per team; improving rollout when only portions of the organization are well suited to the higher tiers.
  2. Pay only for the features you use.
  3. Consistency with pricing where you can have different subscriptions for different groups.
  4. Consolidation of all users in a single instance rather than separate instances with separate licenses.
  5. Increased transparency on license and usage; reducing renewal risk.
  6. Less negotiation.

The disadvantages are:

  1. The current plans have a blended price, assuming 75% of users should pay for the 5x less expensive plan—so, plan prices would increase by 2.5x 1/(0.25+(0.75/5)).
  2. It is hard for buyers to estimate how much of each tier they will need.
  3. The complexity lengthens the sales process.
  4. For users, it is unclear which features they can use.
  5. It is not common in the industry, buyers don't expect it, and it isn't a boring solution (a sub-value under our efficiency value).
  6. The true-up process becomes more complex.
  7. Some features are can't be disabled on a per user basis, like High Availability (HA).
  8. The customer has to administer a process for how users can get a higher plan.

We currently think the disadvantages outweigh the advantages.

Counting different types of users, roles for users, or other modifications of a user definition tends to lead to the same problems as above.

For the GitLab sales team and for GitLab customers, we suggest handling the objection by focusing on the value and business outcomes

True-up pricing

Price difference between self-managed and SaaS

Arguments to charge more for SaaS:

  1. The costs of SaaS are higher for GitLab.
  2. It is more logical in revenue recognition.

Arguments to at least make them equal:

  1. Self-managed pricing tends to be higher, in general.
  2. There is more market demand for self-managed.
  3. No incentive for sales to sell SaaS over self-managed.
  4. Self-managed tends to be a better experience.
  5. We want to incentivize customers to move to SaaS with us.

Not sure what is normal in the market. Adobe did a good job, but they moved from perpetual licensing to subscriptions, where it is hard to compare the two prices.

When is a dollar not a dollar?

This is the title of a great article of which we'll apply the 8 points to GitLab below:

  1. Cost vs. revenue: we can help both to reduce costs and increase revenue, make sure you align to what the priorities of the prospect are.
  2. Principle agent problem: for a VP of Engineering, you probably want to highlight our features that provide more visibility over features that save developers time.
  3. Existing expense vs. new expense: we can make use of existing budgets, be aware that multiple can apply (dev tools, security, operations, DevOps transformation).
  4. Above vs. below discretionary spending limits: one more reason to have multiple pricing tiers.
  5. Selling services vs. customized products vs. off-the-shelf products: we're selling a high-margin product and augment with services when needed to make the customer more successful.
  6. Selling to many stakeholders vs. one stakeholder: this is another reason for our multiple tiers—Starter is sold to the single stakeholder of development teams, Ultimate is sold to multiple stakeholders and will need the CIO to enforce the transformation.
  7. Monthly vs. upfront payments: that is why we prioritize yearly upfront, sometimes even multi-year upfront. Also, yearly is the standard for enterprises (Salesforce sells it like this) and helps reduce support costs that are an order of magnitude greater for .com (most likely to be monthly) vs. self-managed.
  8. Selling vs. upselling: this is why we have multiple tiers.

Annual pricing is prioritized over monthly pricing

Annual, up-front pricing is our priority and primary offering. We will enable monthly billing options for SaaS offerings, when packaged as part of a bundled monthly offering with partners.

Arguments supporting annual up-front pricing:

  1. It helps to recover the costs of acquiring, onboarding, and supporting a customer.
  2. It enables reinvestment to speed delivery of new product capabilities for customers.
  3. It aids customer self-selection and commitment to drive to successful deployment and enough time to see successful outcomes with the product.
  4. It can be offered at a discount relative to monthly pricing.
  5. We offer a wide range of product tiers, including a free tier to appeal to many customer types and free trials of any tier.
  6. Costs are lower for sales, billing, and customer support.
  7. Better customer experience due to ongoing product availability and less frequent administration and and billing contact.
  8. It is much easier to enforce license entitlement only once per year and yields lower product development cost.
  9. It enables a more predictable business and more up-front investment in customer success to ensure great outcomes from use of the product.

Arguments supporting monthly pricing

  1. Monthly billing gives customers another way to buy and thus reduces barriers to adoption of the product.
  2. Monthly pricing can align with billing of combined or dependent products/services that are already billed monthly. (ex: if bundled with another monthly service)

Only sell a suite

Most companies evolve in the following way:

  1. Sell one product
  2. Sell multiple products
  3. Sell multiple products and a suite of them
  4. Only sell a suite

An example is Microsoft Office, where it is costly to buy components of Office365 separately, although higher tiers include more products. At GitLab, we decided to skip the intermediate steps and immediately only offer a suite that includes all our products. Having our complete scope included in our open source version is even part of our stewardship promises.

Selling only a suite has risks, after the => is how we mitigate those at GitLab:

  1. Lose potential customers, if people want one product. => Offer a Starter tier that is priced competitively with single products from competitors.
  2. Leave money on the table, if people want all products. => Offer an Ultimate tier that is great value, if you adopt everything of GitLab.
  3. Discount because people don't want all the products. => Make a discount conditional on not using part of the product.
  4. Tiers are harder to define than if you would have separate products. => Hard to mitigate, we have to work extra hard on communicating the differences.
  5. No revenue feedback from customer about what products they value more. => The product function focuses on usage data as our best proxy for value.

Companies evolve to selling only a suite for the following reasons, after the => is how this applies to GitLab:

  1. Makes it easier for organizations to adopt the other products. => This is essential; organizations have official solutions and GitLab grows with organic adoption from developers.
  2. Show customers the benefit of a single application. => This is essential, since people are skeptical (showing beats telling).
  3. More usage of all the products. => This is essential for us, due to our breadth over depth strategy
  4. Harder to displace the suite, once it is in place. => This will help if competitors offer a service based on our open source code.

We're going even further than selling a suite by integrating everything in a single application. We do that because of the advantages mentioned on our direction page section about us being single application. A secondary effect is that the user doesn't have to make a buying, or even an adoption, decision.

Value creation

There are two factors that determine how much value Gitlab creates for an organization, in order of importance:

  1. Scope: how many parts of GitLab you use, indicated by the DevOps score, how many components of GitLab are in use.
  2. Size: how many people work in an organization and use GitLab.

When an organization is larger, the benefits of GitLab are larger because:

Value capture

Since GitLab is an open core project, we'll always create much more value then we (are able to) capture. Based on the value created, the straightforward way to capture value would be to:

  1. Scope: charge a higher price per user the more of GitLab you use.
  2. Size: Charge a higher price per seat the more users you have.

These straightforward ways are not possible for the following reasons:

  1. Scope: charging more for adoption would hurt the adoption of GitLab for the whole lifecycle. In January 2018, version control is 10 times more popular than the next feature (CI). We need the features to spread organically, so people can create more value with GitLab. People are much more willing to pay when they are already using a part of the lifecycle.
  2. Size: many other software companies limit the maximum amount of users in certain tiers. For GitLab, we can't do this because the open source version can't contain artificial restrictions. We can do it in our proprietary tiers, but this doesn't seem symmetrical. It also feels unfair, if you have to pay more simply by being a bit larger then the limit.

So we're left with charging for features. We can't charge for each feature separately, since that is unwieldy for the customer. So we charge for tiers that contain a bundle of features. We select features in the (more expensive) paid tiers that:

  1. Scope: become more useful and valuable as your DevOps score increases
  2. Size: become more useful and valuable as your organizational size increases

Adding features to a (more expensive) paid tier is not the only thing stopping users from adopting them, but it is a very important factor.

To simplify the above, we base our feature groupings on champion position (see below).


The likely type of buyer determines what features go in what tier. Our plans are based on the buyer that buys GitLab, from individual contributor, to manager, to director, to executive. Every person in the company is on the same tier, even if they don't use all the features. The feature is put in the plan based on what champion is most likely to care about it. Buyers make sense, since a higher-cost plan needs a higher-placed buyer.

Alternatives that don't work:

  1. Pricing based on company size doesn't work; some small companies need the features of the most expensive plan.
  2. Scope and size don't work.
  3. Pricing based on maturity is strange, because organizations at the beginning of their journey should pay the most, since in a greenfield you benefit the most quickly and extensively from GitLab.

More detail about this in my presentation about Buyer-Based-Open-Core at the Open Source Leadership Summit in 2019.

Also see fork and commoditize in the list of our biggest risks.

We'll always move features down

Besides the tier framework, we also need to keep our stewardship promises. We owe it to our users to only move features from higher-paid tiers to lower ones, never the other way.

This means that, when in doubt, we will select the higher tier and move it down later, if data shows that this is better. It also means that all tier changes will involve moving things to lower-priced plans.

When moving features to lower priced plans, it is important that we take an overall view. If there is a knee-jerk reaction of 'why do we always move features down,' then the response will be to opt for lower tiers initially. The harder we make moving a feature down in tiers, the higher the risk of getting the initial assessment wrong.

So we should focus on building new features that buyers want and making sure that the initial assessment of new features is never too low. Please also note that the CEO is in charge of pricing and tiers; this is delegated to product for the day-to-day work. While other parts of the GitLab organization are consulted, the CEO is the directly responsible individual.

Moving a feature down

To propose bringing a feature that exists in Premium to Core, for example, follow the process outlined in the Move a Feature Down issue template.

DevOps score is not maturity

What is interesting is that GitLab creates more value as you adopt more of it. This shouldn't be confused with DevOps maturity. DevOps maturity is how advanced your practices are and how fast your DevOps lifecycle is, shown in cycle analytics. With the best practices embedded in GitLab, you will mature faster than without it. GitLab enables a 200% faster DevOps lifecycle. But DevOps maturity is mostly about organizational change. GitLab the product is just an enabler of it. Even if an organization uses everything of GitLab (high DevOps score), they can still have a slow process (slow lifecycle). We know there is a correlation between a higher DevOps score and a faster lifecycle; but especially in organizations new to DevOps, it is a trend, not an absolute. Linking our tiers to maturity would mean we don't ask any money from the large organizations that currently have a slow lifecycle but that are making it faster by adopting all of GitLab. These large organizations with a slow lifecycle benefit the most from GitLab, since they can adopt it completely, because they are not held back by an existing toolchain.

Location based pricing

As suggested by a user on Twitter. This is a good suggestion to consider given the GitLab approach to adapting to local markets throughout the business. GitLab will assess viability of the idea in our overall pricing strategy planning. It is difficult to do and our assessment of this will consider:

  1. This is a complex issue and requires that all parties are better off if a change is made to account for geography. We fully admit that this would be hard to pull off successfully.
  2. If there is a way this could be good for customers and for GitLab, we will not treat this separately. We will treat it as part of a unified pricing strategy
  3. In a global and digital marketplace it is difficult to positively identify where a customer is geographically located either because we rely on that customer to self-identify or because it is a large organization with users in several geographical locations.
  4. We may be able to solve with a simpler discounting policy
  5. Any overall reduction in cost per license must be more than made up by increased volume at the new pricing