On this page
Free is targeted at individual contributor developers. It is a complete DevOps solution and contains capabilities from all ten GitLab stages.
Premium is targeted at Director level buyers and is for teams. The pricing themes for Premium are Faster code reviews, Ops insights, Project management, and Release controls. Premium helps teams iterate faster and innovate together.
Ultimate is targeted at Executive level buyers and is for organizations. The pricing themes for Ultimate are Advanced security testing, Compliance, Portfolio management, and Value stream analytics. Ultimate helps organizations deliver better software faster with enterprise ready planning, security and compliance.
Product Managers are responsible for helping determine and maintain the optimal tier for their features. To accomplish this, Product Managers should leverage the supporting resources below to understand and implement the strategy, philosophy and various components of GitLab's pricing model.
The CEO is the DRI for pricing and tiers. This includes any changes that directly impact how we charge customers under our licensing model, such as a change to how we handle active users. GitLab leverages a buyer-based open core pricing model. Please review the entirety of the stewardship and pricing model pages before making any determinations as to which tier a given feature should go in.
The likely buyer determines which tier, and "Who cares most about the feature" ultimately determines the likely buyer. Our stewardship principles also help guide whether something belongs in a paid tier. Be sure to consider documenting your rationale for the decision in the issue description, including a reference to our stewardship page when appropriate.
Please indicate the applicable tier for an issue by applying the label associated with the tier (e.g.
GitLab Ultimate). Ensure this is defined before feature development begins.
When early in a category's maturity, it is recommended to start with functionality in the open source version to drive broad awareness and adoption. Early adoption translates into open source contributions, which can help accelerate maturity in a new area of the product.
Each product area should have a laddered tiering strategy, where incremental value is contained in each tier. This enables us to drive broad usage in Free, and then drive uptiers to Premium and Ultimate as customers increase in their sophistication of using the given product area. When considering what to offer in open source, also think through what additional features can be monetized later. Open source drives popularity of the main feature, but it's important to understand up front how we intend to leverage that usage and exposure to drive incremental ARR later in higher tiers.
To propose changing a feature tier or making any other change that impacts how we charge customers, please follow the process and template on the pricing page. This ensures collaboration and alignment with key GitLab stakeholders and maintenance of
features.yml as SSOT.
Please remember our promise not to make open-source features source-available.
All Premium, and Ultimate features must:
Should product managers have any questions when making tier decisions, they should collaborate with their manager, product leadership, or the CEO for clarification. The most up to date reference for pricing DRIs can be found in the feature tier or pricing change template.
Multiple considerations go into customers' purchase decisions. Here are some various resources product managers can visit to reference various data points for analysis:
Product managers should be familiar with and leverage strategies and tactics for their own stage as well as across GitLab's other stages in accordance with GitLab's pricing model. Here are some helpful examples:
GitLab currently has three ways of allocating investment across product as detailed in investment types.
Pricing adjustments within a buyer-based model can be challenging and sometimes feel counterintuitive. Below are some examples of strategies/tactics that have succeeded and failed that we can learn from: