Comment Auto-Héberger GitLab CE sur un VPS

C’est un vendredi après-midi, la demande de fusion de ton équipe est en cours de révision, et ton ordinateur portable t’alerte avec un message familier : GitHub rencontre des problèmes à nouveau.

Peut-être que les actions sont bloquées.

Peut-être que `git push` renvoie une erreur 500 pour la troisième fois ce mois-ci.

Le fil dans ton chat d’équipe contient déjà huit messages.

La première fois que cela arrive, tu en ris. La deuxième fois, quelqu’un partage la page de statut de GitHub, et vous allez tous prendre un café. La troisième fois, généralement juste avant une fenêtre de lancement, quelqu’un finit par poser la question à haute voix : “Devrions-nous simplement gérer cela nous-mêmes ?”

Pour la plupart des équipes, la réponse honnête est non. GitLab.com Free convient bien aux petites équipes, et la charge opérationnelle de gérer votre propre serveur de contrôle de version n’est pas nulle.

C’est le genre d’échange que tu fais seulement pour une vraie raison.

Si ton équipe a une de ces raisons, comme un contrat client qui interdit les SaaS tiers, une limite de conformité, ou une facture de licence par utilisateur qui commence à sembler ridicule, s’auto-héberger GitLab CE est le mouvement le plus propre que tu puisses faire. C’est open source, ça fonctionne sur un seul VPS, et, une fois réglé, la maintenance prend environ une heure par mois.

Chez DreamHost, nous avons hébergé d’innombrables serveurs autogérés, et nous observons constamment un modèle : les développeurs qui réussissent avec GitLab auto-hébergé choisissent le bon plan dès le départ, maîtrisent bien le Protocole Shell Sécurisé (SSH) et la préparation du Domain Name System (DNS), et résistent ensuite à l’envie de continuer à bidouiller une fois que c’est stable.

Pourquoi Héberger Toi-Même GitLab Au Lieu D’Utiliser GitLab.com ?

Tu héberges toi-même GitLab lorsque GitLab.com ou GitHub.com ne répondent pas à tes besoins en matière de confidentialité, de conformité ou de contrôle des coûts. Pour la plupart des autres équipes, l’option hébergée est un meilleur compromis.

Trois véritables raisons résistent à l’examen :

1. Confidentialité et souveraineté des données : Ton code source réside sur une infrastructure que tu gères et mises à jour selon ton propre calendrier. Pas d’accès tiers, pas de plateforme partagée, pas de rayon d’impact de violation au-delà de ton propre serveur.
2. Conformité : Les industries réglementées comme la santé, la finance et le gouvernement ont souvent besoin de contrôle de résidence des données. GitLab CE auto-hébergé est la manière la plus simple de garder le code à l’intérieur d’une limite contrôlée. 
3. Contrôle des coûts à grande échelle : GitLab.com facture par utilisateur actif. Selon la page de tarification de GitLab, le tarif Premium est de 29 $ par utilisateur par mois, tandis que le tarif Ultimate est disponible uniquement sur demande. Une équipe de 50 personnes en Premium coûte 17,400 $ par an avant les modules complémentaires. Un VPS auto-géré plus une heure de maintenance mensuelle coûte souvent moins.

Si tu fais partie d’une équipe de deux personnes sans raisons de confidentialité ou de conformité, la bonne réponse est la version gratuite de GitLab. (Oui, nous savons que cela semble drôle venant d’une entreprise d’hébergement).

Avec l’auto-hébergement, tu échanges une facture mensuelle de SaaS contre du temps opérationnel continu. C’est un échange valable seulement si tu as une bonne raison de faire le changement.

Voici où cette option a du sens et où elle n’en a pas :

Scénario	Meilleure solution
Exigence de confidentialité ou de conformité	GitLab CE auto-hébergé
Équipe de plus de ~30 utilisateurs actifs	L’auto-hébergement est souvent moins cher
Le code est votre propriété intellectuelle, et vous voulez le garder local	GitLab CE auto-hébergé
Équipe de 2 à 5 personnes, sans besoin de conformité	GitLab.com (gratuit)
Vous ne voulez pas patcher un serveur	GitLab.com

GitLab Community Edition est gratuit sous une licence open-source de type MIT. Il n’y a pas de limite d’utilisateurs, pas de restrictions sur les fonctionnalités de base, et pas de sollicitations pour des versions supérieures. Toute la plateforme est à ta disposition.

Quelles Sont Les Exigences Matérielles Pour GitLab CE ?

GitLab CE possède des seuils matériels clairs, et les respecter fait la différence entre une installation rapide et une qui se débat avec la mémoire de swap (espace disque que votre système d’exploitation utilise lorsque la RAM est pleine).

Selon les exigences officielles d’installation de GitLab, la dimension est exprimée en requêtes par seconde plutôt qu’en paliers fixes par utilisateur. La base de référence publiée est de 8 vCPU et 16 Go de RAM pour jusqu’à 1 000 utilisateurs (environ 20 requêtes par seconde). Les équipes plus petites peuvent fonctionner avec moins, jusqu’à un minimum documenté de 2 Go de RAM plus 1 Go de swap pour évaluation, bien que les performances soient inférieures en dessous de 4 Go.

Une nouvelle installation de GitLab consomme environ 4-6 Go au repos. Une fois que les tâches CI/CD commencent à s’exécuter, la mémoire augmente rapidement. Donc prévois une marge — ou prépare-toi à une lenteur.

En ce qui concerne le stockage, la base officielle de GitLab est de 40 GB plus la taille du dépôt, mais 50 GB est un point de départ plus sûr en pratique. Les dépôts grandissent et les artefacts de construction s’accumulent. NVMe, un type de stockage à état solide plus rapide, fait une différence notable sur les opérations Git et les lectures de cache CI.

Voici comment ces seuils correspondent aux niveaux de VPS hosting de DreamHost :

Cas d’Utilisation	RAM Recommandée	Niveau DreamHost VPS
Évaluation / personnel	4 Go de RAM	Stack 4
Petite équipe, utilisation légère	8 Go de RAM	Stack 8
Jusqu’à ~1 000 utilisateurs (seuil publié par GitLab)	16 Go de RAM	Stack 16
Exécution de runners CI/CD sur le même serveur	+ 2-8 Go de RAM en plus de votre niveau	Augmenter de taille (ex. Stack 16 → Stack 32)

Le point de départ idéal pour la plupart des équipes qui exécutent de véritables pipelines CI/CD est Stack 16. Cela semble exagéré jusqu’à ce que tu assistes au lancement de la première construction et que Sidekiq, Postgres et un exécutant montent en charge simultanément.

16 GB de RAM te donnent assez de marge pour la pile de services de GitLab (environ 4 à 6 GB au repos sur une installation par défaut) et un couple de workers CI (1-2 GB chacun) pour fonctionner à plein régime en même temps sans que personne dans le chat de l’équipe ne le remarque.

Comment Prépares-Tu Ton VPS Avant D’installer GitLab ?

Passe 10 minutes à te préparer — cela paie dès le premier redémarrage. Il suffit de suivre ces étapes :

1. Configurer le VPS : Choisis Ubuntu 22.04 LTS ou 24.04 LTS. Les deux sont pris en charge par les paquets Omnibus officiels de GitLab (l’installateur tout-en-un fourni par GitLab) et bénéficient de plusieurs années de mises à jour de sécurité gratuites.
   
2. Associer un domaine à l’IP du serveur : Crée un enregistrement A (le type d’enregistrement DNS qui associe un domaine à une adresse IP) et laisse-le se propager pendant au moins 15-30 minutes avant l’installation. Sans cela, la configuration SSL automatique échouera car l’autorité de certification n’aura aucun endroit pour valider.
   
3. Mettre à jour les paquets : Connecte-toi au VPS en utilisant `ssh root@ton-ip-de-serveur` et exécute `sudo apt update && sudo apt upgrade -y`.
   
4. Installer les dépendances : Exécute `sudo apt install -y curl openssh-server ca-certificates perl postfix`. Le paquet `postfix` est un serveur de mail qui gère les emails sortants pour que GitLab puisse envoyer des notifications de fusion de requêtes et des réinitialisations de mot de passe.
   Lorsque l’installateur demande la configuration du mail, choisis Site Internet et utilise ton domaine. Cela permet à GitLab d’envoyer des mails immédiatement.
   Pour la production : évite le postfix local et configure un relais SMTP dans gitlab.rb à la place. Les IPs de VPS sont fréquemment sur les listes de blocage de spam, et les emails de réinitialisation de mot de passe acheminés via postfix local atterrissent souvent dans les spams. SendGrid, Mailgun et le relais sortant de DreamHost fonctionnent tous — consulte les docs de configuration SMTP de GitLab.
   
5. Ouvrir les bons ports : Configure un pare-feu en utilisant UFW (l’outil de pare-feu intégré d’Ubuntu) et autorise les ports 80, 443 et 22.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Comment Installer GitLab CE Sur Ubuntu Avec Le Paquet Omnibus ?

Ajoute le dépôt GitLab CE :

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Ensuite, installe GitLab CE avec ton domaine défini comme URL externe :

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Définir `https://` ici indique à GitLab de demander automatiquement un certificat Let’s Encrypt pendant l’installation, tant que les ports 80 et 443 sont ouverts et que le DNS est correctement configuré. Si l’un de ces éléments n’est pas prêt, l’installation se termine mais le SSL échoue — et tu passes les trente minutes suivantes à dépanner quelque chose qui n’est en réalité pas cassé.

Ensuite, attends l’étape de reconfiguration.

GitLab exécute `gitlab-ctl reconfigure` (la commande qui applique les modifications à la configuration de GitLab) automatiquement à la fin de l’installation. Cela prend cinq à 10 minutes. Et oui, l’étape de reconfiguration prend vraiment tout ce temps.

Obtenir le mot de passe root initial :

sudo cat /etc/gitlab/initial_root_password

Ce fichier est généré automatiquement et sera supprimé dans 24 heures, alors récupère le mot de passe et connecte-toi. Visite ton domaine dans un navigateur, connecte-toi en tant que `root` et change le mot de passe immédiatement.

Enfin, vérifie le processus d’installation.

Depuis l’écran d’accueil de GitLab, crée un projet de test. Envoie un commit depuis ta machine locale. Si l’envoi réussit et que le fichier apparaît dans l’interface web, l’installation est saine.

Si l’étape de reconfiguration se bloque, vérifie le `tail -f /var/log/gitlab/reconfigure/*.log`. C’est là que se trouve l’erreur réelle.

Comment Sécuriser Une Instance GitLab Auto-Hébergée ?

GitLab est livré avec des paramètres par défaut raisonnables, mais ils sont adaptés pour un serveur communautaire ouvert, et non pour votre instance d’équipe privée. Passe une heure ici.

1. Désactive l’inscription libre. L’inscription libre est activée par défaut. Dans la Zone Admin, navigue jusqu’à Paramètres > Général > Restrictions d’inscription et désactive la case à cocher “Inscription activée”. Sinon, n’importe qui ayant l’URL peut créer un compte.
2. Active l’authentification à deux facteurs. Rends-toi dans Zone Admin > Paramètres > Général > Restrictions de connexion et impose la 2FA pour tous les utilisateurs. Réduis la période de grâce de 48 heures par défaut à 8 heures.
3. Restreins la création de projets. Définit Création de Projet par Défaut à Mainteneurs ou Personne, selon le niveau de restriction désiré.
4. Vérifie le renouvellement SSL. GitLab renouvelle automatiquement les certificats Let’s Encrypt par défaut. Pour confirmer, exécute `sudo gitlab-ctl renew-le-certs` une fois et vérifie le résultat.
5. Verrouille SSH sur le VPS lui-même. Désactive la connexion par mot de passe root, autorise uniquement l’authentification par clé SSH, et (si possible) déplace SSH hors du port 22. Un serveur Git auto-hébergé n’est sécurisé que si la machine sous-jacente l’est également.

Pour une version approfondie, GitLab a publié un Guide de Renforcement couvrant l’authentification, le chiffrement et les paramètres d’instance. Lis-le une fois, applique ce qui correspond à ton modèle de menace, et passe à autre chose.

Comment Sauvegarder Et Restaurer Une Instance GitLab Auto-Hébergée ?

GitLab inclut un outil de sauvegarde intégré. La première fois que tu en auras besoin, tu seras content de l’avoir configuré.

Créer une sauvegarde :

sudo gitlab-backup create

Cela dépose une archive tar dans `/var/opt/gitlab/backups`. Planifie-le quotidiennement via un Cron Job avec une fenêtre de rétention de sept jours. Exécute sudo crontab -e et ajoute ces deux lignes :

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

Le drapeau CRON=1 supprime l’affichage de la progression afin qu’il ne spamme pas les logs de cron.

Conseil pro : la sauvegarde des données n’inclut pas `/etc/gitlab/gitlab-secrets.json` ni `/etc/gitlab/gitlab.rb`.

Ces fichiers contiennent la clé de cryptage de la base de données, les graines à deux facteurs et les variables CI/CD. Les secrets de configuration ne font pas partie de la sauvegarde régulière et doivent être sauvegardés séparément. Restaure les données sans le fichier des secrets, et les comptes à deux facteurs échouent, les variables cryptées se transforment en charabia, et tu passes une longue soirée à comprendre pourquoi.

Ajoute cela au même Cron Job :

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Une sauvegarde ne peut être restaurée que sur la même version et édition (de CE à CE, pas de CE à EE) de GitLab sur laquelle elle a été créée.

Mets à niveau avec prudence : ne restaure pas une ancienne sauvegarde sur un GitLab fraîchement installé sans d’abord rétrograder l’installation pour correspondre.

Teste le processus de restauration au moins une fois. Une sauvegarde que tu n’as jamais testée n’est qu’un fichier.

L’Auto-Hébergement de GitLab En Vaut-Il La Peine Pour Ton Équipe ?

Auto-héberger GitLab est une décision de contrôle pour la plupart des équipes. Les calculs de coût fonctionnent parfois, mais la raison pour laquelle les gens restent avec l’auto-hébergement n’est que rarement l’élément de la liste.

Voici le coût mensuel honnête pour une installation en petite équipe :

• ~30 minutes de mise à jour – mises à niveau d’apt, versions mineures de GitLab
• ~15 minutes de vérification de sauvegarde – ne fais jamais confiance à une sauvegarde que tu n’as pas restaurée
• ~15 minutes de vérification de capacité – utilisation du disque, marge de RAM
• ~2x si CI/CD s’exécute sur le serveur – Un exécutant occupé peut doubler la charge

Cela représente environ une heure par mois lors d’une semaine calme, ou deux lors d’une semaine chargée.

À environ 150 $ de l’heure, 12 heures de temps opérationnel coûtent environ 1 800 $ — soit à peu près cinq sièges GitLab.com Premium.

Une étude de cas de Mad Devs explique comment leur équipe économise plus de 10 000 $ par an en utilisant GitLab CE auto-hébergé au lieu de payer pour des sièges Premium. Les économies ne se concrétisent que lorsque l’équipe est suffisamment grande pour que les licences par siège dominent le budget.

Cela dit, l’auto-hébergement est le mauvais choix pour :

• Équipes de deux à trois personnes sans raisons de conformité. GitLab.com Gratuit te couvre. Le temps opérationnel est supérieur au coût économisé.
• Équipes sans personne à l’aise avec la ligne de commande. “À l’aise” ne signifie pas niveau sysadmin. Cela signifie que tu peux lire les erreurs de `/var/log/gitlab` sans paniquer.
• Équipes dont le plus gros obstacle est le recrutement, pas les outils. L’auto-hébergement détourne l’attention du produit. Si la vitesse du produit est la contrainte, l’hébergement géré est le bon choix.

Alors, quand est-ce que l’auto-hébergement a du sens ? Voici quelques scénarios :

• Industries réglementées avec des exigences explicites de résidence des données ou de chaîne de garde
• Équipes UE/UK ayant des préoccupations de souveraineté concernant le code hébergé aux États-Unis
• Équipes de 30+ où les licences par siège dominent le budget
• Contrats clients interdisant le SaaS tiers pour le code source

Si ta raison est “GitHub facture par siège,” tu seras probablement gagnant. Si ta raison est “Je veux me sentir aux commandes,” tu pourrais trouver que la réalité opérationnelle est moins romantique que prévu.

Devrais-Tu Exécuter les Runners GitLab CI/CD sur le Même VPS ?

Pour l’évaluation, oui. Pour la production, non.

Un exécutant CI sur la même machine vole de la mémoire et du CPU à l’interface utilisateur de GitLab. Le symptôme classique est “GitLab semble lent à 9 heures du matin,” ce qui remonte généralement à un build qui déclenche la première pipeline du matin et qui affame le frontend web. La configuration plus propre est un petit VPS séparé (ou une instance DreamCompute) pour l’exécutant, enregistré à l’instance GitLab via le réseau.

Si tu dois garder les exécutants sur la même boîte, augmente le VPS à 16 Go.

Selon les exigences du système de runner de GitLab, le processus du runner lui-même est léger. Les charges de travail qu’il exécute ne le sont pas, et elles partagent le CPU et le disque du boîtier avec tout ce que GitLab fait d’autre.

Prêt À Faire Le Changement ?

Retour au chat d’équipe du vendredi après-midi.

Si GitHub devient jaune et que ton équipe en rit de nouveau et part prendre un café, c’est bien.

Mais si le fait que GitHub soit en panne commence à sembler sérieux ?

Peut-être que cela menace un contrat client ? Apparaît dans un audit de conformité ? Ou la facture de licence par siège a-t-elle finalement franchi la limite ?

Héberger soi-même GitLab CE commence à devenir une option tout à fait raisonnable. Il suffit d’un VPS, d’un domaine, d’une installation Omnibus et d’une heure de renforcement.

La prochaine fois que la page de statut de GitHub s’illuminera, ton code continuera de se pousser sans problème.

Questions Fréquemment Posées Sur L’auto-Hébergement De GitLab

Y a-t-il autre chose que tu souhaites savoir sur l’auto-hébergement de GitLab sur un VPS ? Voici les réponses à quelques questions fréquemment posées.

GitLab CE est-il gratuit pour l’auto-hébergement ?

Oui, GitLab CE est gratuit pour l’auto-hébergement sous une licence open-source de type MIT. Il n’y a pas de limite d’utilisateurs et pas de tarification par siège. Les seuls coûts sont le VPS lui-même et le temps opérationnel pour le maintenir.

Le VPS Stack 4 de DreamHost est un point de départ raisonnable pour l’évaluation. Les équipes de production utilisent généralement le Stack 8 ou le Stack 16.

Combien de RAM GitLab CE a-t-il réellement besoin ?

Prévois 16 Go de RAM pour jusqu’à 1 000 utilisateurs, ce qui est la base publiée par GitLab (environ 20 requêtes par seconde). Les équipes plus petites peuvent fonctionner avec moins, jusqu’à un minimum documenté de 2 Go plus 1 Go de swap pour l’évaluation. Dans tous les cas, si tu exécutes des pipelines CI/CD sur la même machine, prévois 16 Go.

Puis-je auto-héberger GitLab sur un VPS de 4 GB ?

Oui, tu peux exécuter GitLab CE sur 4 GB, mais cela sera lent sous une charge réelle. GitLab documente une solution de secours de 2 GB + 1 GB de swap pour les environnements à mémoire limitée — cette voie est pour l’évaluation, pas pour la production. Pour une équipe qui pousse activement du code et exécute des pipelines, 8 GB est le minimum pratique.

Combien de temps faut-il pour installer GitLab CE sur un VPS ?

Environ 10 à 15 minutes pour l’installation du paquet, plus à peu près une heure pour la préparation et le durcissement, donc environ 90 minutes du début à la fin. L’installation elle-même consiste principalement à attendre l’étape de reconfiguration.

Le passage au durcissement, qui nécessite la désactivation de l’inscription libre, l’application de l’authentification à deux facteurs et le verrouillage de la création de projets, prend l’heure restante et est obligatoire pour toute instance de production.

Est-il judicieux d’auto-héberger GitLab pour une équipe de cinq personnes ?

Probablement pas, sauf si tu as une raison de confidentialité ou de conformité. GitLab.com Free couvre jusqu’à cinq utilisateurs avec des projets privés illimités et 400 minutes de CI/CD par mois. Le temps opérationnel de l’auto-hébergement dépasse le coût économisé par siège à cette taille d’équipe.

L’auto-hébergement commence à être rentable, en termes de coûts purs, à partir de 30 utilisateurs actifs ou plus.

Quelle est la différence entre GitLab CE et GitLab Community Edition ?

GitLab CE et GitLab Community Edition sont le même produit. CE est l’abréviation standard. Le terme « Auto-géré » se réfère à l’endroit où tu l’exécutes (ton infrastructure), et non à l’édition.

GitLab Community Edition est open-source. GitLab Enterprise Edition (EE) ajoute des fonctionnalités payantes sur la même base de code.

En quoi GitLab CE diffère-t-il de GitLab EE ?

GitLab CE est l’édition gratuite et open-source. GitLab EE utilise la même base de code, plus des fonctionnalités payantes qui s’activent lorsque tu télécharges un fichier de licence.

La différence pratique se résume aux points suivants :

• CE est sous licence MIT et entièrement fonctionnel. Contrôle de version, demandes de fusion, problèmes, CI/CD basique, registre de conteneurs, le tout.
• EE ajoute des fonctionnalités d’entreprise derrière une licence. Pensez à épopées, cadres de conformité avancés, analyses de flux de valeur, règles d’approbation multiples et balayage de sécurité avancé. Selon la comparaison des fonctionnalités gérées par soi-même de GitLab, l’écart est surtout important pour les organisations avec des processus formels de gestion des changements.
• Tu peux installer EE sans licence, et il fonctionne comme CE jusqu’à ce qu’il soit licencié. C’est ainsi que la plupart des équipes se prémunissent contre un besoin futur de mise à niveau.
• Tu ne peux pas rétrograder EE à CE proprement. Planifie en conséquence.

Pour la plupart des équipes d’auto-hébergement, CE est suffisant. Si ta raison concerne la confidentialité ou le coût, les fonctionnalités de EE changent rarement les calculs.

Comment maintenir à jour mon instance GitLab auto-hébergée ?

Exécute `sudo apt update && sudo apt upgrade gitlab-ce` pour appliquer les correctifs de sécurité. Une cadence mensuelle est le minimum pratique pour une instance de production. Crée toujours une sauvegarde avant de procéder à une mise à niveau.

Les mises à jour de version majeure doivent être effectuées séquentiellement — tu ne peux pas sauter de versions majeures. Passer de 16.x à 18.x nécessite de passer d’abord à 17.x, puis à 18.x. Sauter une version majeure interrompra les migrations de bases de données. Vérifie toujours l’outil de chemin de mise à niveau de GitLab avant de procéder à la mise à jour, et crée une sauvegarde immédiatement avant chaque étape.

Où se situe DreamHost dans le cadre de GitLab auto-hébergé ?

L’hébergement VPS de DreamHost fournit le serveur Linux avec accès root sur lequel GitLab CE est installé. Le plan Stack 16 (16 GB de RAM) correspond aux exigences officielles de GitLab pour jusqu’à 1 000 utilisateurs, avec de la marge pour des pipelines CI/CD actifs.