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.
This page outlines the Direction for the GitLab Dedicated category and belongs to the GitLab Dedicated group. To provide feedback or ask questions about this product category, reach out to the Product Manager.
This document and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this document and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
You can contribute to this category by:
GitLab Dedicated's objective is to provide a GitLab SaaS offering to large enterprises and customers in industries with strict security and compliance requirements. When adopting DevOps tools, customers increasingly prefer SaaS to reduce operational cost, but customers in highly-regulated industries (e.g. Healthcare, Finance, and Public sectors) can't compromise on their security and compliance requirements when moving to SaaS. These requirements (e.g. isolated storage of source code IP) often dictate the need to be on separate Cloud Infrastructure from other tenants. This makes it challenging for these customers to adopt a shared-tenancy SaaS solution like gitlab.com.
Additionally, customers in regulated industries often require the ability to connect users or services running in their corporate network to their source code repositories running in the cloud via a private network connection. As a public-facing SaaS service, GitLab.com can't support this type of private connectivity easily by default. Finally, large, globally-distributed enterprises need the ability to control the location and number of Geo Replica sites to reduce latency for their workforce around the world. Some of our Self-Managed customers have 5+ Geo sites, and for them to consume SaaS they may need more global coverage than what we offer on GitLab.com today.
For these customers, a higher level of tenant isolation and deployment customization is required. While some customers may be satisfied leveraging a partner MSP, customers may prefer to consume the service directly from GitLab so that they have a single-point of contact for operational accountability.
GitLab Dedicated will solve these needs by offering a fully isolated, private GitLab instance, deployed in the customer's cloud regions of choice. The instance is fully hosted and managed by GitLab Inc enabling customers to offload operational overhead and focus on more business-critical tasks.
In addition to delivering customer value, GitLab Dedicated will also benefit internal GitLab teams. We envision the tooling we build for Dedicated being used as the single method going forward for running all of GitLab Inc's SaaS services. This will allow us to achieve even greater returns on our initial investment by enabling any future SaaS services to quickly get started with a robust and standardized foundation.
There are two major trends emerging when it comes to the delivery of Cloud based solutions:
GitLab Dedicated is for organizations that want to benefit from both SaaS and Private Cloud. By delivering this offering we will set ourselves up to achieve customer success as these two trends further accelerate in 2025.
GitLab Dedicated is initially targeted at large enterprises and customers in highly-regulated industries.
GitLab Dedicated is for customers that need isolation from other tenants at the infrastructure level or need custom deployments of GitLab as discussed above.
The main value proposition with GitLab Dedicated is that we're giving customers their own GitLab Instance, isolated from other tenants, and hosted as a SaaS service on the customer's behalf. With this extra value comes an additional management fee. Customers who want SaaS, but are OK with the shared-tenant model of .com or don't want to pay an extra fee should use gitlab.com. Availability will not be a point of differentiation between GitLab Dedicated and .com as both offerings target a 99.95% Availability SLA. Meanwhile, customers who want full control over their GitLab installation should use the self-managed option.
See below for a comparison of the different ways to deploy GitLab:
Overall, the main challenge our target customer has is maintaining an up-to-date GitLab instance that fulfills their security and compliance requirements. More granular customer needs are documented in the sections below.
Note, this section does not reflect the list of currently available features within the GitLab Dedicated offering; rather, it contains the needs we're hearing from our customer base. The list of currently supported features in GitLab Dedicated is documented here: https://docs.gitlab.com/ee/subscriptions/gitlab_dedicated/#available-features.
Large enterprises demand strict uptime SLAs (at least 'three-nines') and expect the following capabilities related to system availability:
The main goal for FY23 is to make GitLab Dedicated available to external customers(GitLab internal). The initial version of the service will be fully automated, but will contain a minimal feature set(GitLab internal). After releasing the offering, we plan to deliver application features and operational capabilities that were not included in the first launch based on customer demand.
The product will be made available to customers over the course of the following milestones.
GitLab Dedicated is available in Limited Availability (LA) today. Unlike the previously completed phases (Alpha and Beta), Limited Availability makes production-level environments available to customers.
Production instances are currently available to an exclusive set of hand-picked customers until we broaden availability (including lowering seat count) in GA. During this phase, we will focus on delivering improvements to the service and customer-facing features to prepare for increased scale in GA. Criteria for exiting Limited Availability and entering General Availability:
General Availability will be driven by the ability of GitLab Dedicated to scale to the expected demand of the service. Customers who want a production-quality GitLab Dedicated instance and are willing to pay for it will be able to get one in this phase, as opposed to LA where instances were limited to selected customers. Targeting expected demand avoids prematurely optimizing for demand significantly beyond what is projected.
In line with GitLab's value of Iteration, GA will not support all GitLab features at launch, but will provide customers with an enterprise-ready solution that they can integrate into their environments.
The full roadmap for GA is documented in this Epic(GitLab internal).
Because Dedicated is a SaaS offering, we prioritize "Keep the lights on" activities (e.g. operating customer environments, tech debt, and corrective actions) above all else to ensure we provide customers a high level of service that continually meets our reliability and performance SLAs. Next, we prioritize security enhancements (e.g. supporting new compliance certifications) since our customer base comprises of large enterprises with strict compliance requirements, followed by initiatives to improve our automation and scaling of the system (including Switchboard), enhancements to our overall system SLAs (uptime, rto/rpo targets, etc), customer feature requests, and then, finally, config changes to customer environments.
When it comes to customer feature requests, we prioritize features that will benefit the most customers. As a result, we will not build any custom capabilities or one-off features for individual customers. This includes not making modifications to individual tenants. Feature requests that meet our prioritization criteria but are not currently on the roadmap will be slotted in after other committed roadmap items have been delivered.
| Priority | Category | Description |
|---|---|---|
| 0 | KTLO - On Call | Operating Tenant Production Environments |
| 1 | Security/Compliance | Attain security and third party compliance certifications and addressing findings from audits |
| 2 | Automation | Reduce toil required to operate GitLab Dedicated platform including Switchboard (management portal for customer admins) MVC, automated restore, and Automated Version Management |
| 3 | Reliability | Improve SLAs - Availability, RTO, RPO, Geo, disaster recovery, failover testing |
| 4 | Customer Feature Requests | Delivering new customer-facing platform capabilities as well as enabling GitLab functionality such as Pages, advanced search, reply-by email, service desk |
| 5 | Customer Configuration Changes | Customers will need config changes during onboarding and weekly maintenance windows. |
Please see list of Available Features in our documentation.
This category is currently at the Minimal maturity level, and our next maturity target is Viable, which will be met when the service reaches the General Availability milestone.
Please see list of Features that are not available in our documentation. These features will not be available before the launch of GA but are under consideration for release in the Post-GA launch timeframe.
The key customer features we plan to deliver in FY24 are summarized below.
Post Q2, we will prioritize features from the list of what is not currently planned based on customer demand.
2022-12-01, Start on BYOK implementation - new tenants only(internal only)The following links are internal to GitLab
When engaging with customers, we encourage everyone to be very intentional about when and how to mention GitLab Dedicated. We do not want to disrupt prospective and existing customers by introducing GitLab Dedicated too early, or when it's a bad fit.
Please complete the steps below before asking to schedule time with the GitLab Dedicated Product Team.
#f_gitlab_dedicated Slack channel with a link to the opportunity and note that the opportunity meets the qualification criteria. Product and Sales teams will partner to review and establish potential and timeline.We have the following public facing pages available for those interested in learning more:
The GitLab Dedicated customer onboarding timeline is available in GitLab's internal handbook.
GitLab Dedicated creates a business opportunity for both GitLab and GitLab channel partners who offer hosted GitLab services. We are creating this offering to meet the needs of customers who want to consume hosted solutions directly from the DevOps vendor (in this case GitLab, Inc.) to more closely align operational and DevOps application needs. Customers who are interested in purchasing hosting services that include value-add managed services (for example, helping meet industry-specific specific requirements like HIPAA) would benefit from working with a Managed Service Provider (MSP) Partner Additionally, many customers have existing relationships with Channel Partners. Per the services ROE, these customers should continue consuming GitLab through their Channel Partner. By following the segmentation laid out above, we can minimize any disruption to existing channel-sourced ARR(GitLab internal).
With this effort, we also see an opportunity to grow the overall market for GitLab-hosted services through collaboration with partners. In the short-term we plan to enable MSP partners with design guidance and certifications (GitLab Internal) so that they can offer better hosted GitLab solutions for their customers. We will work with the GitLab Channel Partner team to create a partner certification that will provide MSP partners with technical certifications, training, deployment and maintenance guidelines, and access to some of the same underlying tooling that powers GitLab Dedicated (e.g. GitLab Environment Toolkit and official Reference Architectures). We plan to keep the other underlying services (e.g. Switchboard and Amp) as well as the GitLab Dedicated branding proprietary to GitLab, Inc. Longer-term opportunities for consideration include enabling partners to resell GitLab Dedicated(GitLab internal). These partners would provide customers value-added services or integrated vendor stacks while the GitLab Dedicated team would still host the GitLab instance on behalf of the partner.
The pricing for GitLab Dedicated is comprised of the following components:
During Limited Availability we've priced GitLab Dedicated to align with likely buyers based on minimums and the complexities of their deployments. As mentioned above, the pricing for GitLab Dedicated is comprised of the following components: the cost for Ultimate Licenses, plus additional fees for instance infrastructure & management, the amount of storage needed, and the customer's infrastructure size (e.g. S, M, L, XL, XXL). As we scale and introduce GitLab Dedicated to more and more customer cohorts we'll share further details on pricing options.
The main competitor to GitLab Dedicated is GitHub AE, which offers a fully-managed GitHub Enterprise instance in the customer's desired region on Azure. Other competitors offering single-tenant, fully-managed devops solutions include AWS CodeCommit, Azure Devops, and GitLab Host.
This will be filled in during the Limited Availability period once we start receiving feedback from customers.
This will be filled in during the Limited Availability period once we start receiving feedback from customers.
This will be filled in during the Limited Availability period once we start receiving feedback from customers.