The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Last reviewed: 2022-11-01
The Core Platform section is responsible for the features and tools our customers use to explore and operate GitLab at all scales. Core Platform supports customers from initial deployment of GitLab to ongoing operation, as well as cross-stage end user features.
The Core Platform section is made up of one eponymous non-DevOps stage, Core Platform, and eight groups:
Provide users with a consistently great experience and achieve customer business requirements by making GitLab easy to deploy, operate, scale, and use.
GitLab delivers value by enabling organizations to build better software, faster. The most important success metric for the Core Platform group is therefore the broader success of the user base of GitLab, rather than its administrators. We need to provide the software necessary to make it easy for an administrator to provide a delightful and productive GitLab experience to their users.
Within the single platform, users as well as contributors need a common set of cross-stage features and frameworks. End users need a set of common cross-stage features to make the broad array of features and content easily consumable. Contributors need a set of frameworks and developer tools to efficiently and safely contribute to GitLab's growing code base and data sets.
There is no traditional addressable market for Core Platform due to its foundational, GitLab-specific nature. Every GitLab user is directly impacted, however, by the work Core Platform delivers.
In light of this, we think of Core Platform's addressable market as that of GitLab's larger addressable market. By working to ensure we can meet the operational, compliance, and usability requirements of GitLab's enterprise customers, we can capture increasingly larger percentages of GitLab's total addressable market opportunity.
There are two primary segments within the broader "GitLab" market: organizations that would like to operate their own GitLab instances (self-managed) and those who prefer to utilize a SaaS service (such as GitLab.com). SaaS revenue within the DevOps space is predicted to overtake self-managed in 2022, with our key competitors already capitalizing on this shift. This is confirmed by analysts reports (GitLab confidential) as well as others in the DevOps space.
Today, we are able to capture most of the self-managed segment with our mature linux packages and more recently our cloud-native deployment options for Kubernetes and OpenShift. A proof point is GitLab's two-thirds market share in the self-managed Git market. While this speaks to the competitiveness of GitLab's overall product, a critical enabling factor is the high-quality, flexible, and scalable software and operational tools.
While we are able to meet the requirements of most organizations, there are some unmet needs:
Today, GitLab is underperforming compared to our peers in the SaaS segment. While GitLab's SaaS revenue is accelerating faster than self-managed, our revenue mix is heavily weighted towards self-managed. IDC predicts that the market for public cloud SaaS-based DevOps tools (currently 52% of the market in 2021) will continue to accelerate and account for $20.0B in revenue (or 61% of DevOps software tools market) by 2026.1(#footnotes) This represents both a significant growth opportunity if we can better serve this segment, or risk if we fail to execute.
There are a larger number of unmet needs on GitLab.com than self-managed, which primarily fall into two buckets:
For GitLab's FY23, SaaS First continues to be a key theme, driving the closure of these gaps. From an Core Platform perspective, much of our work is on improving the performance, reliability, scalability, and efficiency of our SaaS services. The GitLab.com strategy is available here, and a high level overview of GitLab Dedicated is available here.
The existing team members and open vacancies for the Core Platform section can be found in the links below:
All Core Platform section metrics can be found on the Core Platform Performance Indicator (internal only) page.
As noted above, GitLab's competitive position is a tale of two cities. We are the leading self-managed Git solution but are third in SaaS. Our success in self-managed has driven the majority of the company's growth, however it is at risk of being disrupted by growing trends in the market. IDC forecasts that by 2026, 61% of the worldwide DevOps software tools market will be delivered as public cloud services.1(#footnotes) Our SaaS services represents both a large opportunity and risk depending on our execution.
We need to achieve what could be considered opposing goals: making GitLab efficient and easy to run at small scales and improving the scalability and reliability at internet-scale.
In three years we expect:
As a result, in three years, GitLab will:
Woven throughout all of the below themes is a focus on improving our competitiveness in the SaaS segment. As this is critical outcome for the company, it is worth highlighting individually our efforts to contribute.
We are improving the service levels and efficiency of GitLab.com, our multi-tenant SaaS service. A multi-tenant cloud service is the best solution for most customers, combining low cost of ownership and fast time to value. Core Platform is specifically focused on a few key outcomes:
To serve the large enterprise and highly regulated SaaS market, we have recently launched GitLab Dedicated, a single-tenant SaaS offering. Core Platform will be focusing on improving the efficiency of operating individual GitLab tenants, by improving underlying tools like the GitLab Environment Toolkit, and our Operator. By building in automation and self-healing capabilities, we can reduce the maintenance overhead required per instance, improving the efficiency and reliability of not just Dedicated but also self-managed deployments who also use these tools.
Deploying and maintaining GitLab should be as frictionless as possible for organizations of all sizes. This is critical for GitLab at multiple points in the customer journey.
GitLab starts as a personal or side project at many organizations, representing an important driver of initial adoption and awareness. Delighting future champions by providing a thoughtfully designed out-of-the-box experience that runs well on hardware they have lying around pays dividends in future growth.
Once a company is ready to adopt GitLab enterprise wide, it is similarly important to ensure the GitLab instance is set up for success with minimal effort. Consider our 5,000-user reference architecture which recommends setting up at minimum 27 different instances, and that our GitLab configuration file is over 2,000 lines long. This is a significant upfront investment to ask a company to make, prior to seeing value returned. It can also be error prone given the complexity, with the only practical solution to ongoing management being infrastructure as code, which requires further investment.
Day 2 operations like backups, scaling, and upgrades are equally important. GitLab is a business critical application, so events like upgrades need to be routine and seamless. The easier we make it for our customers to upgrade, the faster our users will be able to leverage our new features and provide feedback. Currently it takes over 3 months after release for a majority of our users to feel the impact of our work.
By reducing the deployment/operating costs and packaging best practices, we will see the following benefits:
To support these goals, we are:
We are moving towards a cloud-native deployment of GitLab. Cloud-native will become the strongly recommended architecture for all deployments beyond small single-node instances.
The outcomes we hope to achieve with this effort are:
We plan to achieve this by delivering a few key projects:
By automating and standardizing more of the operations of Gitlab, we can help our customers (both SaaS and self-managed) operate highly reliable, secure, and up-to-date deployments. This will allow end users and customers to maximize the value and potential of the GitLab platform.
As customers roll out and adopt additional stages of GitLab to realize the benefits of a single application, the service availability and performance requirements increase as well. Additional departments within the business utilize the service on a daily basis to accomplish their jobs, such as design, security, and operations teams. People around the world collaborate together. Work that may have been done manually is now automated using CI/CD, including delivering the latest update or bug fix to their customer facing application/website. For these reasons, GitLab is increasingly being identified as a business-critical application with attendant requirements. It is therefore important for GitLab to be a consistently reliable, performant service for all users to fulfill its potential.
By providing market-leading reliability and performance, we will see the following benefits:
Organizations in regulated industries, the public sector, and large enterprises often have a variety of standards and processes that they must adhere to.
In the public sector, there are standards like NIST 800-53 and FedRAMP. For companies handling credit card transactions, there is PCI DSS. These are just two examples. While some of these standards are not directly aimed at services like GitLab, they have a broad reach, and the requirements generally cannot be waived, as the penalties for non-compliance can be severe. Many enterprises have also developed their own internally driven processes and policies that can be important to support, rather than requiring changes prior to the adoption of GitLab.
For published standards, it is important that GitLab offers the required features and configuration to enable our customers to be in compliance. This includes changes to our code base; for example, fully encrypting all traffic between GitLab nodes, selection of specific cryptographic modules, availability via our Reference Architectures, and disaster recovery, among others. Additionally, some standards like FedRAMP (internal only) can also impact the operational and governance processes of GitLab.com, as well as where data can be stored and processed. The more that we can do to be compliant out of the box or provide documentation on recommended settings, the less work our customers will be required to do during evaluation and implementation.
By enabling our customers to meet their compliance requirements and reducing the required effort, we will see the following benefits:
All parts of the software development process grow over time: the code base, its dependencies, data stores, the historical context, the organization, and more. This accretion leads to an increase in complexity, creating a drag on development velocity. At the outset of a project, changes can be quick to land as the code base and its impact is well understood. Fast forward 5 to 10 years and that same change will require significantly more effort, investigating where the change needs to happen across the code base, understanding why the code was written that way in the first place, determining the potential downstream impact, validating the performance, refreshing documentation, and more. GitLab, at 10 years old, is experiencing these challenges as well.
As a single platform, GitLab is uniquely positioned to minimize these effects by providing tools to better explore and manage complexity. We plan to achieve this by:
Over the next 12 months, each group in the Core Platform section will play an integral part in this strategy.
Please see the categories page for a more detailed look at Core Platforms's plan by exploring Direction page links in areas of interest.
In FY23 (CY 2022), the Distribution team will focus on several main themes:
You can learn more about Distribution group plans on the Distribution Direction page.
You can read the Geo group plan on the Geo Direction page.
In FY23, the Geo group is focused on delivering Complete maturity for Disaster Recovery. Disaster Recovery is a common, must-have, requirement for large enterprises, allowing them to feel comfortable that GitLab can remain available for their developers to be productive throughout a variety of disaster scenarios.
In FY23, Geo also plans to deliver Complete maturity for Geo Replication, another key feature for large enterprises with multiple offices, or the growing number of businesses embracing remote work. Geo-replication enables organizations to set up additional GitLab nodes throughout the world, enabling these users to work efficiently by reducing the latency and time it takes to perform common tasks like cloning or pulling container images.
In Q1 FY23, we will re-evaluate the priority of the backup and restore category and are going to assess all currently open issues to define the priorities further.
You can read the Global Search group plan on the Global Search Direction page.
For FY23 - Global Search provides a search experience across the entire GitLab Instance.
The focus is on expanding the user’s needs to include new scopes as GitLab features.
Vulnerabilities search will include multiple ways for sort and filter allowing users to quickly map find Vulnerabilities across groups and projects.
Pipelines and Jobs Search will make it easier to find CI/CD components across multiple groups.
Snippets Search will make it easier for users to share snippets across their organization.
Along with adding these additional scopes, we will be enhancing the Advanced Search experience to include additional ways to sort and filter results.
Adding new content into its own search verticals puts pressure on the user to discover these sections and look at each one individually. To Improve this we will be adding an All results default view that will combine all scopes.
Code Search will focus on addressing the needs of Big Code, Which includes several key areas of focus.
Growing out of the early delivery of Code Intelligence, Code Navigation will bring more Local IDE style use cases to your Web IDE and across multiple Groups and Projects. Details specific to this delivery are in Discovery currently.
GitLab Cloud Connector is a way to access services common to multiple GitLab deployments, instances, and cells. GitLab customers can choose between the following deployment options:
In FY25, we will work to formalize the technical boundaries for Cloud Connector by integrating at least two different services: AI gateway and TanuKey. This experience will help us iterate towards a framework-like solution where new feature teams can self-service their own Cloud Connector integration.
You can learn more about Cloud Connector group plans on the Cloud Connector Direction page.
The Database group is focused on improving the scalability, performance, and resilience of GitLab's database layer as well as instituting best practices across the wider development organization.
You can learn more about Database group plans on the Database Direction page.
For FY23, the group is working on the following key themes:
You can read the Tenant Scale Group plan on the Tenant Scale Direction page.
The Tenant Scale Group is concerned with delivering application changes that allow GitLab and GitLab.com to scale to millions of users and implement the strategies defined in the Database Scalability Working Group.
In FY23, we expect GitLab.com will transition to run on multiple databases that are decomposed by feature. We expect that at least two independent databases exist: main and ci. This will provide significant headroom and will allow the Tenant Scale group to transition towards validating proposals for scaling GitLab even further.
Decomposition is only a first step to unlocking further scalability for GitLab. By the end of FY23, the Tenant Scale Group will have evaluated and implemented other scalability options for GitLab. There are several possible options that will have to be evaluated, including but not limited to sharding GitLab's database using existing PostgreSQL tooling, adopting Vitess, moving towards a Cell-like architecture and utilizing different datastores that fit specific use cases.
See the 1 year GitLab.com infrastructure strategy
The one year Project Horse direction page can be found in the internal handbook here.
You can read the Gitaly group plan on the Gitaly Direction Page.
In FY23, the Gitaly group is focused on improving the performance and availability of the Gitaly product. We have completed a prioritization effort and have coordinated on our near term focus on improving data safety and improving stability for large repositories.
More detailed plans can be found by read the Where we are headed section of our direction page, linked above.
Choosing to invest in these areas in 2021 means we will choose not to:
The Core Platform pricing strategy's aim is to ensure that the widest possible audience can benefit from GitLab through our free tier, and that we can meet the unique needs of large organizations through our paid tiers.
At the free tier, we want to provide an open-core product for everyone. To achieve this GitLab needs to be incredibly easy to try and adopt, for a wide variety of deployment methods. Today we support SaaS with GitLab.com, and self-managed on all major cloud providers as well as on-prem. This model helps keep our open core flywheel spinning, and is a key factor in our organic growth by being a go-to DevOps application with a low time and effort investment required to see value.
As adoption across an organization grows, additional business and scale requirements may need to be met, these are particularly common for large enterprise and regulated industries. We aim to meet these more complex operational needs with features in our paid tiers, so that these organizations can adopt GitLab at scale.
From an operational standpoint, we believe GitLab should be easy to deploy and operate, and that all users should have a great user experience. To achieve this, we invest significantly in automating as much of the deployment and day 2 operations as we can, and embedding as many best practices into the product as possible. We want to set up administrators for success, so they can delight their users. We don't believe application performance, or ease of use, should be a paid-for feature. This helps to ensure that GitLab is easy to try, and that when deployed, provides a good user experience.
For the user-facing features that we build, we align with our overall pricing strategy, focusing Free on individual developers. Presently this includes basic search, which provides a search experience across projects and groups.
Operationally, this tier is where the majority of paid features are located, as Director-level buyers are typically more concerned about meeting wider business, compliance, and scale requirements. We focus features that relate to meeting these needs, typically found in larger enterprises or regulated industries, in this tier. Examples include meeting business continuity needs with disaster recovery and horizontally-scaled instances, as well as multi-region performance requirements with geo-replication. The GitLab Environment Toolkit is also available at this tier, providing a great starting point for customers to develop their own deployment automation further.
For users, Advanced Search provides cross-project code search as well as advanced search syntax to help users more effectively locate content within larger organizations.
Currently there are no Core Platform features in this tier. We would introduce new features in this tier that target highly specialized requirements typically seen at the executive level. For example companies who may operate multiple independent businesses, but still want to provide a unified experience across the organization through some type of federation.
The Core Platform PM team reviews one of the groups direction every other week. Prior recordings and the upcoming schedule can be viewed here.
Install a self-managed instance of GitLab using the Omnibus package. This category is at the "viable" level of maturity.
Install GitLab in a cloud native environment using Helm. This category is at the "complete" level of maturity.
Ensure the components that make up GitLab are tested, up to date, license compliant, and available for our users’ platforms and architectures.
Geo-replication provides an easily configurable, read-only mirror (we call it a Geo node) of a GitLab installation that is complete, accurate, verifiable and efficient. This category is at the "viable" level of maturity.
Learn more • Documentation • Direction
Disaster Recovery (DR) helps our customers fulfill their business continuity plans by creating processes that allow the recovery of GitLab following a natural or human-created disaster. This category is at the "complete" level of maturity.
The Git team makes upstream contributions to the Git open source project, and helps other teams use Git effectively and efficiently.
Priority: high • Documentation • Direction
Gitaly is a Git RPC service for handling all the Git calls made by GitLab. Additionally, Gitaly provides Gitaly Cluster, a Highly Available storage solution offering strong consistency, horizontal scaling, and read distribution.
Priority: high • Documentation • Direction
Managing your organization. This category is planned, but not yet available.
Priority: high • Documentation • Direction
Managing your user profile and configuring what will be visible to others.
Priority: low • Documentation • Direction
Organize your projects and restrict access to controlled resources. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Global Search is made up of two primary experiences, Basic Search and Advanced Search.
Basic Search is the default search experience for self-managed users as well as Free users of GitLab.com. It provides a way to search across the DevOps platform. Basic search includes Code Search for one project.
Advanced Search, in GitLab Premium and above, is an optional feature that uses Elasticsearch to enable additional search features for sorting, filtering, and improved relevancy. This category is at the "complete" level of maturity.
Code Search gives users the ability to explore all their code. Code searches are a significated portion of searches run by users, and Code Search is a fundamental need for organizations with complex or large amounts of code and multiple repositories. This category is at the "viable" level of maturity.
