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||
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.
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 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.
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.