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.
| Stage | Enablement |
| Maturity | Lovable |
| Content Last Reviewed | 2022-02-07 |
Thanks for visiting this category strategy page for Omnibus GitLab. This page belongs to the Distribution group of the Enablement stage and is maintained by Dilan Orrino (E-Mail).
Your ideas and feedback are important to us and play a major part in shaping the product direction. The best way to provide feedback on work that is planned or in the backlog is through the Omnibus epics and deliverable issues board in GitLab.com.
We are always looking for opportunities to interview GitLab users and learn more about your experiences using the Omnibus package to deploy a self-managed instance of GitLab. If you would like to share your experience and provide feedback through a video call, please email Dilan.
Omnibus GitLab is a downloadable package that contains all the components needed to run, configure, and scale a self-managed instance of GitLab on prem or in the cloud. It provides a quick and easy way to install a standard instance of GitLab and keep it updated to the latest version. It also provides the tools and flexibility to
With Omnibus GitLab we aim to reduce the time it takes to administer GitLab, regardless of your scale, so that your users can have the best possible experience.
Installing GitLab
Upgrading GitLab
Scaling GitLab
Configuring GitLab
Getting started with GitLab
GitLab's Omnibus package is a mature product that provides a straightforward and quick way to deploy GitLab on a single node. It also includes a well-proven High Availability solution for distributing components of GitLab across multiple nodes and keeping the system accessible in the event of a node failure. GitLab is being deployed at increasingly larger scale as organizations realize the value of having all projects across their organizations available within a single instance.
To support larger scale deployments, we have developed reference architectures for deploying GitLab with an appropriately sized, highly available architecture. We also plan to support the GitLab Environment Toolkit (GET) on the Omnibus side, for VM and hybrid reference architectures. GET will be the best and easiest way to deploy multi-node production instances of GitLab, and operate them with very high service levels. The collaboration will ensure users can continue to easily grow with GitLab. GET uses Terraform to provision machines and adding specific labels / tags to each machine for Ansible to then use to identify, and Ansible to configure them. This helps users who maintain applications like GitLab have a reliable and automated way of deploying, upgrading, and performing maintenance tasks across multiple nodes. Check out the GET documentation to learn more.
We want to take the worry out of upgrading GitLab so you can upgrade more regularly, with less impact on your end users, and with less time spent by your administrators. Our goal is to reduce the checklist you need to follow when upgrading multi-node GitLab, and enable more customers to leverage truly zero downtime upgrades. For example, this might mean eliminating some of the upgrade steps, and addressing some of the potential scenarios that presently require downtime.
As a new user, you install GitLab. Then what? Our goal is to guide you through to the next steps of running a fully functioning deployment of GitLab that meets the needs of your organization so you can spend less time wading through documentation and more time putting GitLab to good use.
The Omnibus package will also undergo foundational changes to how the package is built. Our direction of splitting and paralleling the components in the Omnibus project will help reduce overall package size, making upgrades quicker and benefiting instances with memory constraints. Another project we will work towards is better repo signing key management via keyring packages, which will make is easier for users to rotate keys.
The Omnibus installation will be benefitting from overall efficiency work the team is planning to work on in the next 3 milestones (15.9-15.11). We have identified these contributor experience issues and build efficiency issues.
Improving our contributor experience is very impactful for the Distribution team because we typically work on a large number of reviews and are asked to contribute to and complete a wide range of work items from customers and internal teams at GitLab. By improving our contributor experience we can reduce the amount of time we spend on reviews. Contributor experience might also mean another team at GitLab is completely enabled to do work, where in the past they may have been required to request assistance from Distribution team members.
In our efficiency work we hope to reduce the amount of maintence we need to do regularly, as well as, reduce the time it takes to build tests and implement features. Our efficiency work is focused on reducing the effort to maintain two distinct code bases, for Omnibus and Cloud-native GitLab. This will ideally reduce the time it takes to implement any issue, maintenance work or feature work.
We get many requests to support running GitLab on different platforms. While we wish we could support all of these requests, we simply don't have the capacity given all of the goals we want to achieve. AWS is the most popular cloud platform for deploying GitLab. We have committed to providing an outstanding experience for deploying in AWS with up-to-date images, a range of marketplace listings, and great documentation. If time permits, we will provide this same level of commitment for other platforms that are in high demand by our users. We know we won't get to all of them, and for some platforms we will rely on community support to get there.
This category is currently at the Lovable maturity level. This is the highest maturity level. Our goal is to stay Lovable by making it even easier to manage a GitLab instance and continuing to provide the best possible experience when deploying GitLab with Omnibus. For more information on maturity levels, see our [definitions in the handbook](https://about.gitlab.com/direction/#maturity.