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.
|Content Last Reviewed||
This vision and direction is constantly evolving and everyone can contribute:
The Cell category focuses on delivering a long-term horizontal scalability solution for GitLab. A Cells architecture creates many mostly isolated GitLab instances, called Cells, that include all required services (database, web, Redis, Gitaly, Runners, Sidekiq etc.). The number of Cells can grow alongside the growth of the business.
By introducing Cells we aim to address the following problems:
At this moment, GitLab.com has “social-network”-like capabilities that may not fit well into a more isolated Organization model. Removing those features, however, creates some challenges:
gitlab-orgcontributors continue to contribute to the namespace?)
Over the coming year, the Tenant Scale group will focus on delivering some key work streams that are required by the project.
We currently don't plan to implement any scalability solutions for GitLab.com that would negatively impact our self-managed customers. We want all customers to benefit from further scalability.
We do plan to support a Cells architecture for self-managed deployments, which could address a narrow set of self-managed use cases which previously required independent instances, like data residency.
Cell is a non-marketable category, and is therefore not assigned a maturity level.