Recommended Installation Method

Official Linux package

This is the recommended method for getting started. The Linux packages are mature, scalable, and are used today on GitLab.com. If you need additional flexibility and resilience, we recommend deploying GitLab as described in the reference architecture documentation.

Linux installation is quicker to install, easier to upgrade and contains features to enhance reliability not found in other methods. Install via a single package (also known as Omnibus) that bundles all the different services and tools required to run GitLab. At least 4 GB of RAM is recommended.

    Ubuntu

    18.04 LTS, 20.04 LTS

    Debian

    9, 10

    CentOS 8

    and RHEL, Oracle, Scientific

    CentOS 7

    and RHEL, Oracle, Scientific

    image/svg+xml

    OpenSUSE Leap 15.2, 15.3

    and SUSE Linux Enterprise Server 12.2, 12.5

    Raspberry Pi OS

    and Raspbian Buster

Kubernetes Deployments

When installing GitLab on Kubernetes, there are some trade-offs that you need to be aware of:

  • Administration and troubleshooting requires Kubernetes knowledge.
  • It can be more expensive for smaller installations. The default installation requires more resources than a single node Linux package deployment, as most services are deployed in a redundant fashion.
  • There are some feature limitations to be aware of.

Use this method if your infrastructure is built on Kubernetes and you’re familiar with how it works. The methods for management, observability, and some concepts are different than traditional deployments. The helm chart method is for Vanilla Kubernetes deployments and the GitLab Operator can be used to deploy GitLab on an OpenShift cluster. The GitLab Operator can be used to automate Day 2 operations in both OpenShift and vanilla Kubernetes deployments.