|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 throgh a video call, please email Larissa.
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 includes a well-proven High Availability solution for distributing the components of GitLab across multiple nodes and keeping the system running in the event of a node failure. GitLab is being deployed at increasingly larger scales as organizations realize the value of having all of the 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.
As the scale of your deployment grows, the number of recommended nodes increases. It is time consuming to manually create and configure all of these nodes. To support larger deployments based on the reference architectures, our goal is to build automation for multi-node deployments and reduce the time it takes to get up and running. Regardless of your scale and the platform you deploy on, you will be able to deploy a highly redundant and scaled instance of GitLab, optionally with Geo replication, in a matter of hours.
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 uprading GitLab, and manage more of the process for you. For example, this might mean more automation around upgrades and the steps required to achieve a zero-downtime upgrade.
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.
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.