Comment installer GitLab sur un serveur dédié

GitLab est une plateforme pour les dépôts Git, la revue de code, le suivi des tickets et le CI/CD que vous pouvez exécuter sur votre propre serveur. Une instance auto-hébergée garde votre code source sous votre contrôle, et sa capacité dépend uniquement des ressources du serveur et des fonctionnalités GitLab que vous utilisez.

Un serveur dédié convient bien à GitLab. Le stockage des dépôts sollicite fortement les disques, et la base de données et les services d'arrière-plan ont besoin d'une quantité de RAM constante. Sur du matériel dédié, ces ressources ne sont partagées avec personne, de sorte que GitLab reste réactif lors des gros push et des exécutions de CI.

Pourquoi exécuter votre propre GitLab

GitLab.com est pratique pour démarrer, mais à mesure qu'une équipe grandit, une instance auto-hébergée devient souvent le meilleur choix :

• Le code reste sur votre serveur. Le code source, les tickets et les secrets CI/CD sont stockés sur du matériel que vous contrôlez, dans le centre de données de votre choix. C'est important pour les projets soumis à un NDA ou à des exigences de résidence des données.
• Pas de limites de forfait sur les utilisateurs, le stockage et les minutes CI/CD. L'offre gratuite de GitLab.com les limite, tandis que sur votre propre serveur seules ses ressources fixent les limites.
• Vos propres runners CI/CD. Les builds s'exécutent sur vos serveurs sans payer de minutes de calcul et peuvent accéder à des services internes fermés à Internet.
• Contrôle total des mises à jour et des paramètres. Vous décidez quand mettre à niveau, quelles intégrations activer et comment sauvegarder les données.

Si vous utilisez déjà GitLab.com, installez d'abord votre propre instance, puis déplacez-y vos groupes et projets.

Ce guide montre comment installer GitLab à partir du paquet officiel sur Ubuntu ou Debian, obtenir un certificat Let's Encrypt gratuit et préparer l'instance pour votre équipe.

Ce qu'il vous faut avant l'installation

Un serveur dédié avec au moins 8 vCPU (threads de CPU) et 16 Go de RAM. Un processeur à 4 cœurs avec Hyper-Threading ou SMT fournit déjà 8 threads. GitLab peut démarrer avec 8 Go de RAM, mais il en utilise presque la totalité et sera lent sous charge. Utilisez des disques SSD ou NVMe avec au moins 40 Go libres pour le système et GitLab, plus assez d'espace pour tous les dépôts et les sauvegardes.

Ubuntu 26.04 LTS, Ubuntu 24.04 LTS ou Debian 13 installé sur le serveur. Les commandes de ce guide sont les mêmes pour les trois systèmes ; lorsque Debian diffère, c'est indiqué.

Un domaine ou sous-domaine pour GitLab, par exemple gitlab.example.com.

Un enregistrement DNS A qui pointe ce domaine vers l'adresse IPv4 publique du serveur.

Un accès root ou un utilisateur disposant des droits sudo. Les commandes de ce guide sont exécutées en tant que root ; si vous utilisez un utilisateur sudo, ajoutez sudo devant. Dans la commande qui ajoute le dépôt GitLab, placez sudo avant bash : curl ... | sudo bash.

Les ports 22 (SSH), 80 (HTTP) et 443 (HTTPS) ouverts sur Internet. Le port 80 est nécessaire même si vous prévoyez de n'utiliser que HTTPS, car Let's Encrypt vérifie le domaine en HTTP.

Se connecter au serveur

Connectez-vous au serveur en SSH depuis votre ordinateur :

ssh [email protected]

Vérifiez la version du système d'exploitation :

cat /etc/os-release

Exemple de sortie :

PRETTY_NAME="Ubuntu 26.04 LTS"
NAME="Ubuntu"
VERSION_ID="26.04"
...

La sortie doit afficher Ubuntu 26.04, Ubuntu 24.04 ou Debian 13. Vérifiez ensuite le nombre de cœurs du CPU, la quantité de RAM et l'espace disque libre :

nproc
free -h
df -h /

Assurez-vous que le domaine pointe déjà vers le serveur. Exécutez cette commande sur votre ordinateur local (elle fonctionne sous Windows, macOS et Linux) :

nslookup gitlab.example.com

L'enregistrement A doit renvoyer l'adresse IPv4 publique du serveur. Si vous utilisez aussi un enregistrement AAAA, assurez-vous que le serveur est joignable en IPv6. Si les adresses ne correspondent pas, corrigez les enregistrements DNS et attendez que la modification prenne effet. Ne continuez pas tant que le domaine ne se résout pas correctement, car GitLab demande le certificat Let's Encrypt lors de la configuration initiale.

Mettre à jour le serveur et installer les dépendances

Mettez à jour les listes de paquets et les paquets installés :

apt update && apt upgrade -y

Définissez le nom d'hôte du serveur sur le domaine GitLab. GitLab ne l'exige pas, mais le nom du système reste ainsi cohérent avec l'adresse de GitLab dans les journaux et les e-mails sortants :

hostnamectl set-hostname gitlab.example.com

Installez les paquets dont GitLab a besoin :

apt install -y curl openssh-server ca-certificates perl tzdata locales

GitLab nécessite également une locale UTF-8 : sans elle, la base de données PostgreSQL fournie peut ne pas s'initialiser pendant l'installation. Activez en_US.UTF-8 dans la liste des locales et générez-la (sous Ubuntu 26.04, elle est déjà activée et la première commande ne change rien) :

sed -i 's/^# *en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen
locale-gen

Configurer le pare-feu

Ce guide utilise le pare-feu UFW. Il est inclus dans Ubuntu mais désactivé par défaut ; sous Debian, installez-le d'abord :

apt install -y ufw

Si UFW est déjà activé sur votre serveur, vérifiez d'abord ses règles actuelles avec ufw status. Autorisez SSH, HTTP et HTTPS, et n'activez le pare-feu qu'ensuite, afin de ne pas interrompre votre session SSH :

ufw allow ssh
ufw allow http
ufw allow https
ufw enable

Répondez y lorsque la confirmation est demandée. Vérifiez les règles :

ufw status

Exemple de sortie :

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
443/tcp (v6)               ALLOW       Anywhere (v6)

Ajouter le dépôt GitLab

GitLab est distribué en deux éditions :

• GitLab Enterprise Edition (gitlab-ee). Elle inclut toutes les fonctionnalités gratuites et permet d'activer ultérieurement les fonctionnalités payantes sans réinstallation.
• GitLab Community Edition (gitlab-ce). Une version entièrement open source avec les fonctionnalités gratuites de GitLab.

Ce guide utilise gitlab-ee. Si vous préférez la Community Edition, remplacez gitlab-ee par gitlab-ce dans toutes les commandes.

Ajoutez le dépôt officiel de GitLab :

curl -fsSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | bash

Le script ajoute le dépôt et sa clé de signature et actualise la liste des paquets.

Installer GitLab

Installez le paquet et transmettez l'adresse de votre instance dans EXTERNAL_URL. Utilisez https:// dans l'adresse : GitLab demande alors un certificat Let's Encrypt et configure automatiquement la redirection de HTTP vers HTTPS.

EXTERNAL_URL='https://gitlab.example.com' apt install -y gitlab-ee

Pendant l'installation, GitLab décompresse ses composants (le serveur web, la base de données PostgreSQL, Redis, le stockage Git et les services d'arrière-plan), écrit la configuration dans /etc/gitlab/gitlab.rb, demande le certificat et démarre tous les services. Cela prend de 5 à 10 minutes. À la fin, la sortie se termine par le message « Thank you for installing GitLab! ».

Exemple de sortie :

Thank you for installing GitLab!
GitLab should be available at https://gitlab.example.com

GitLab génère un mot de passe aléatoire pour le compte root et l'enregistre dans un fichier. Affichez-le :

cat /etc/gitlab/initial_root_password

Copiez le mot de passe. Le fichier est supprimé automatiquement 24 heures après l'installation, connectez-vous donc et définissez votre propre mot de passe avant.

Ouvrir GitLab et vérifier HTTPS

Ouvrez https://gitlab.example.com dans votre navigateur. La page doit s'ouvrir sans avertissement de sécurité, et le navigateur doit afficher un certificat valide émis par Let's Encrypt.

Connectez-vous avec le nom d'utilisateur root et le mot de passe de initial_root_password.

Changez immédiatement le mot de passe. Sélectionnez votre avatar, puis Edit profile. Dans le menu de gauche, développez Access, sélectionnez Password and authentication, puis Change password. Saisissez le mot de passe actuel et un nouveau, puis sélectionnez Save password. GitLab rejette les mots de passe faibles, y compris ceux qui contiennent le mot « gitlab » ou votre nom d'utilisateur.

Si la page ne s'ouvre pas en HTTPS, le certificat n'a très probablement pas été émis. Dans ce cas, la sortie de l'installation contient une erreur Let's Encrypt. Vérifiez que le domaine se résout vers l'adresse IP du serveur, que le port 80 est ouvert et qu'il n'y a pas d'enregistrement AAAA sans IPv6 fonctionnel. Après avoir corrigé la cause, demandez à nouveau le certificat :

gitlab-ctl reconfigure

Let's Encrypt limite le nombre de tentatives échouées par heure, corrigez donc la cause avant de réessayer.

Configuration de base de GitLab

Désactiver l'inscription publique. Si l'instance est réservée à votre équipe, désactivez la création de comptes depuis la page d'inscription. Par défaut, toute personne qui ouvre votre page GitLab peut s'inscrire, et le nouveau compte attend alors l'approbation d'un administrateur. Le moyen le plus rapide est le bouton Deactivate dans la bannière de la page d'accueil de GitLab. Vous pouvez aussi sélectionner Admin dans le coin supérieur droit, aller dans Settings > General et développer New user account restrictions. Décochez la case Allow new user accounts et sélectionnez Save changes. Les nouveaux comptes ne seront alors créés que par les administrateurs.

Créer des comptes utilisateur. Allez dans Admin > Instance overview > Users et sélectionnez New user, renseignez le nom, le nom d'utilisateur et l'adresse e-mail, puis sélectionnez Create user. Utilisez un compte personnel disposant des droits d'administrateur pour le travail quotidien et le compte root uniquement en cas de nécessité.

Créer un groupe. Les groupes rassemblent des projets et des membres de l'équipe. Sélectionnez Create new (l'icône plus) dans la barre supérieure, puis New group > Create group, saisissez un nom et sélectionnez Create group. Ajoutez vos collègues au groupe dans Manage > Members.

Ajouter une clé SSH. Pour travailler avec les dépôts en SSH, chaque utilisateur ajoute sa clé publique dans Edit profile > Access > SSH keys : sélectionnez Add new key, collez la clé et sélectionnez Add key.

Vérifier l'installation

Vérifiez que tous les services GitLab sont en cours d'exécution :

gitlab-ctl status

Exemple de sortie :

run: gitaly: (pid 2981) 512s; run: log: (pid 2975) 512s
run: gitlab-workhorse: (pid 3412) 498s; run: log: (pid 3401) 498s
run: nginx: (pid 3530) 495s; run: log: (pid 3522) 495s
run: postgresql: (pid 3105) 507s; run: log: (pid 3098) 507s
run: puma: (pid 3288) 501s; run: log: (pid 3280) 501s
run: redis: (pid 2950) 514s; run: log: (pid 2944) 514s
run: sidekiq: (pid 3350) 499s; run: log: (pid 3342) 499s
...

Chaque ligne doit commencer par run:.

Lancez la vérification intégrée de la configuration et des services :

gitlab-rake gitlab:check SANITIZE=true

Créez un dépôt de test. Dans l'interface web, sélectionnez Create new > New project/repository > Create blank project, saisissez le nom test, sélectionnez votre groupe et laissez cochée l'option Initialize repository with a README. Sélectionnez Create project.

Vérifiez l'accès en SSH depuis votre ordinateur :

ssh -T [email protected]

Exemple de sortie :

Welcome to GitLab, @username!

Une configuration qui fonctionne répond par un message de bienvenue contenant votre nom d'utilisateur. Clonez ensuite le dépôt de test :

git clone [email protected]:group/test.git

Remplacez group par le chemin de votre groupe. Si le dépôt est cloné et contient README.md, GitLab est installé et fonctionne.

Que configurer ensuite

Sauvegardes. La commande gitlab-backup create crée une sauvegarde de l'application avec la base de données GitLab, les dépôts et d'autres données de l'application dans /var/opt/gitlab/backups. Les fichiers de configuration /etc/gitlab/gitlab.rb et /etc/gitlab/gitlab-secrets.json n'y sont pas inclus et doivent être sauvegardés séparément, par exemple avec gitlab-ctl backup-etc. Sans gitlab-secrets.json, une instance restaurée ne peut pas déchiffrer les paramètres 2FA ni les variables CI/CD. Effectuez régulièrement les sauvegardes de l'application et de la configuration et copiez-les vers un stockage extérieur au serveur GitLab, par exemple vers INTROSERV Cloud Storage : voir Connecter INTROSERV Cloud Storage au serveur.

E-mails sortants. Configurez un serveur SMTP dans /etc/gitlab/gitlab.rb pour que GitLab puisse envoyer des notifications, des réinitialisations de mot de passe et des confirmations de compte. Voir Paramètres SMTP dans la documentation de GitLab.

GitLab Runner. Runner exécute les pipelines CI/CD. Les builds consomment beaucoup de CPU et de RAM, il vaut donc mieux installer Runner sur un VPS ou un serveur dédié distinct plutôt que sur le serveur GitLab lui-même.

Mises à jour. GitLab publie une nouvelle version chaque mois et des correctifs de sécurité plus souvent. Avant de mettre à niveau en sautant plusieurs versions, consultez le chemin de mise à niveau officiel : GitLab doit passer par certaines versions intermédiaires. Créez une sauvegarde, puis mettez à jour avec apt update && apt install -y gitlab-ee.

Supervision. GitLab inclut Prometheus et exporte ses propres métriques. L'état de santé de l'instance peut être vérifié dans Admin > Monitoring > Health check, et les points de terminaison qui y figurent peuvent être connectés à votre système de supervision externe.

Pour choisir un serveur pour votre instance GitLab, consultez la page Serveurs dédiés.