- Installation Requirements.
- If you want to access your GitLab instance via a domain name, like
mygitlabinstance.com, make sure the domain correctly points to the IP of the server where GitLab is being installed. You can check this using the command
- If you want to use HTTPS on your GitLab instance, make sure you have the SSL certificates for the domain ready. (Note that certain components like Container Registry which can have their own subdomains requires certificates for those subdomains also.)
- If you want to send notification emails, install and configure a mail server (MTA) like Sendmail or Postfix. Alternatively, you can use other third party SMTP servers.
These configuration settings are commonly used when configuring Omnibus GitLab. For a complete list of settings, see the README file.
- Installing GitLab.
- Setting up a domain name/URL for the GitLab Instance so that it can be accessed easily.
- Enabling HTTPS.
- Enabling notification emails.
- Enabling replying via email.
Enabling container registry on GitLab.
- You require SSL certificates for the domain used for container registry.
Enabling GitLab Pages.
- If you want HTTPS enabled, you must get wildcard certificates.
- Enabling Elasticsearch.
- GitLab Mattermost Set up the Mattermost messaging app that ships with Omnibus GitLab package.
- GitLab Prometheus Set up the Prometheus monitoring included in the Omnibus GitLab package.
- GitLab High Availability Roles.
Introduced in Omnibus GitLab 14.0.
By default, Omnibus GitLab automatically generates a password for the
initial administrator user account (
root) and stores it to
/etc/gitlab/initial_root_password for at least 24 hours. For security reasons,
after 24 hours, this file is automatically removed by the first
To provide a custom initial root password, you have two options:
- Pass the
GITLAB_ROOT_PASSWORDenvironment variable to the installation command provided the hostname for the server is set up correctly. If during the installation GitLab doesn’t automatically perform a reconfigure, you have to pass the
GITLAB_ROOT_PASSWORDvariable to the first
Before the first reconfigure, edit
/etc/gitlab/gitlab.rb(create it if it doesn’t exist) and set:
gitlab_rails['initial_root_password'] = '<my_strong_password>'
Both of these methods apply only during the initial database seeding, which happens
during the first reconfigure. For subsequent reconfigure runs, neither of
the aforementioned methods have any effect. In that case, use the random
/etc/gitlab/initial_root_password to log in, or
reset the root password.
You can also use the Docker images provided by GitLab to install and configure a GitLab instance. Check the documentation to know more.