Avancé ⏱ 45 min de mise en œuvre Mis à jour le 11 août 2026

Héberger son propre GitLab sur un VPS

Sa propre plateforme DevOps complète, dépôts et CI/CD compris. GitLab CE le permet, mais c'est un poids lourd. Voici comment l'héberger, et quand préférer Gitea.

Auto-héberger GitLab CE permet à une équipe de disposer de sa propre plateforme DevOps, sur une infrastructure qu’elle maîtrise. Les dépôts Git, merge requests, pipelines CI/CD, registres de conteneurs, issues, wikis et outils de gestion de projet restent réunis dans une seule application.

Installé sur un VPS hébergé en France, GitLab peut aussi répondre à des objectifs de souveraineté et de maîtrise des données. TalCloud propose des VPS avec stockage NVMe, protection Anti-DDoS Netrix, conformité RGPD et support humain, à partir de 4,99 € par mois. Cela ne change toutefois pas un point essentiel : GitLab demande une infrastructure nettement plus conséquente qu’une forge Git légère.

Avertissement : GitLab est très gourmand

GitLab CE n’est pas adapté à un petit VPS. Son installation omnibus regroupe de nombreux composants, notamment PostgreSQL, Redis, Gitaly, Sidekiq, Puma et NGINX. Il faut prévoir au minimum environ 4 Go de RAM pour une petite installation, et idéalement davantage dès que plusieurs utilisateurs, pipelines ou images de conteneurs entrent en jeu.

Plusieurs coeurs de processeur sont également recommandés. Le stockage doit couvrir les dépôts, les artefacts CI/CD, les paquets, les journaux, les sauvegardes et, si vous l’activez, le registre de conteneurs. Le NVMe améliore sensiblement la réactivité des opérations Git et de la base de données, mais il ne compense pas un manque de mémoire.

Les runners GitLab consomment leurs propres ressources lorsqu’ils compilent, testent ou construisent des images. Pour une utilisation régulière de la CI/CD, mieux vaut les placer sur une ou plusieurs machines séparées.

Si votre besoin se limite à héberger quelques dépôts Git privés avec des utilisateurs, des clés SSH et des pull requests, Gitea ou Forgejo sera beaucoup plus léger. Ces solutions suffisent souvent avec une fraction des ressources demandées par GitLab. GitLab se justifie surtout lorsque l’équipe veut une plateforme DevOps complète et intégrée.

GitLab ou Gitea : quelle forge choisir ?

Gitea et Forgejo privilégient la simplicité. Leur consommation de mémoire reste faible, leur démarrage est rapide et leur maintenance convient bien à une petite équipe. Ils couvrent efficacement les dépôts, les revues de code, les issues, les organisations et les webhooks.

GitLab va beaucoup plus loin. Il fournit nativement une chaîne cohérente autour du code :

merge requests avec règles d’approbation ;
pipelines CI/CD décrits dans le dépôt ;
registre de conteneurs ;
gestion des artefacts et paquets ;
issues, tableaux, jalons et wiki ;
permissions détaillées et environnements de déploiement ;
outils de sécurité et de conformité selon l’édition utilisée.

Choisissez donc GitLab si cette intégration évite d’assembler plusieurs services indépendants. Pour une simple forge Git privée, choisissez plutôt Gitea ou Forgejo afin de réduire les coûts matériels et la charge d’administration.

Prérequis du VPS

Prévoyez un VPS Linux avec au moins 4 Go de RAM, plusieurs coeurs et une réserve de stockage confortable. Pour une équipe active, 8 Go ou plus constituent une base plus réaliste. Surveillez ensuite la mémoire, l’espace disque et la croissance des artefacts.

Il vous faut également :

Docker et le plugin Docker Compose (voir installer Docker sur un VPS) ;
un nom de domaine, par exemple gitlab.example.fr ;
un enregistrement DNS pointant vers l’adresse IPv4 ou IPv6 du VPS ;
les ports HTTP et HTTPS accessibles ;
un port dédié au SSH Git, par exemple 2222 ;
un pare-feu autorisant uniquement les services nécessaires.

Le port SSH du conteneur ne doit pas obligatoirement utiliser le port 22 de l’hôte. Le choix de 2222 évite un conflit avec le serveur SSH utilisé pour administrer le VPS. GitLab doit néanmoins connaître ce port afin de générer des URL de clonage correctes.

Déployer GitLab CE avec Docker

Créez un répertoire de travail :

mkdir -p gitlab/config gitlab/logs gitlab/data
cd gitlab

Ajoutez un fichier compose.yaml :

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    container_name: gitlab
    hostname: gitlab.example.fr
    restart: unless-stopped
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.example.fr'
        gitlab_rails['gitlab_shell_ssh_port'] = 2222
        letsencrypt['enable'] = true
        letsencrypt['contact_emails'] = ['admin@example.fr']
    ports:
      - "80:80"
      - "443:443"
      - "2222:22"
    volumes:
      - "./config:/etc/gitlab"
      - "./logs:/var/log/gitlab"
      - "./data:/var/opt/gitlab"
    shm_size: "256m"

Remplacez le domaine et l’adresse de contact. En production, épinglez ensuite une version précise de l’image plutôt que de dépendre durablement de latest. Cela rend les mises à niveau plus prévisibles.

Démarrez le service :

docker compose up -d
docker compose ps
docker compose logs -f gitlab

Le premier démarrage est long. GitLab doit initialiser sa base, générer sa configuration et lancer tous ses composants. Plusieurs minutes peuvent s’écouler avant que l’interface réponde. Le conteneur peut sembler actif alors que les services internes terminent encore leur préparation.

Vérifiez finalement l’installation :

docker exec -t gitlab gitlab-rake gitlab:check SANITIZE=true

Récupérer le mot de passe administrateur

GitLab génère un mot de passe initial pour l’utilisateur root. Récupérez-le dans le conteneur :

docker exec -it gitlab grep Password /etc/gitlab/initial_root_password

Ce mot de passe n’est conservé dans ce fichier que pendant 24 heures. Connectez-vous rapidement à https://gitlab.example.fr, modifiez le mot de passe de root, puis stockez le nouveau secret dans un gestionnaire de mots de passe.

Créez ensuite les comptes, groupes et projets nécessaires. Évitez d’utiliser quotidiennement le compte root : réservez-le aux tâches d’administration.

Effectuer la configuration de base

La valeur external_url doit correspondre exactement à l’adresse publique utilisée par les développeurs. Elle influence les redirections, les URL de clonage, les callbacks et plusieurs fonctions internes.

Dans l’interface d’administration, désactivez l’inscription publique si votre GitLab est destiné à une équipe fermée. Créez les utilisateurs manuellement ou raccordez plus tard un annuaire d’entreprise.

Vérifiez également les URL SSH proposées par GitLab. Avec la configuration précédente, elles doivent inclure le port 2222. Un clone ressemble alors à ceci :

git clone ssh://git@gitlab.example.fr:2222/equipe/projet.git

Si vous modifiez la configuration omnibus, appliquez-la avec :

docker exec -t gitlab gitlab-ctl reconfigure

Activer HTTPS

Deux stratégies sont possibles.

La première consiste à utiliser la gestion Let’s Encrypt intégrée à GitLab omnibus. Avec une external_url en HTTPS, les ports 80 et 443 accessibles et les options présentes dans le fichier Compose, GitLab peut demander et renouveler son certificat. Le domaine doit déjà pointer vers le VPS.

La seconde consiste à placer GitLab derrière un reverse proxy externe, par exemple lorsque le serveur héberge plusieurs applications. Dans ce cas, le proxy termine TLS et transmet les requêtes au NGINX interne de GitLab.

Remplacez alors le mapping HTTP par une écoute locale telle que 127.0.0.1:8080:80, retirez le mapping 443:443 si GitLab ne gère plus TLS, puis ajoutez dans config/gitlab.rb :

external_url 'https://gitlab.example.fr'
nginx['listen_port'] = 80
nginx['listen_https'] = false
nginx['proxy_set_headers'] = {
  "Host" => "$http_host",
  "X-Real-IP" => "$remote_addr",
  "X-Forwarded-For" => "$proxy_add_x_forwarded_for",
  "X-Forwarded-Proto" => "https",
  "X-Forwarded-Ssl" => "on"
}

Le reverse proxy doit transmettre ces en-têtes et accepter les requêtes volumineuses, notamment pour les opérations Git, les artefacts et le registre. Après modification, relancez la configuration omnibus.

Comprendre la CI/CD GitLab

Les pipelines sont décrits dans un fichier .gitlab-ci.yml placé à la racine du dépôt :

stages:
  - test

tests:
  stage: test
  image: node:22
  script:
    - npm ci
    - npm test

GitLab orchestre le pipeline, mais les tâches sont exécutées par des GitLab Runners enregistrés séparément. Un runner peut utiliser Docker, une machine virtuelle ou un serveur dédié.

Évitez d’exécuter des builds intensifs sur le même VPS que GitLab. Une compilation gourmande peut épuiser la RAM, remplir le disque ou dégrader l’accès aux dépôts. Pour une équipe active, placez les runners sur une autre machine et limitez leur concurrence.

Sécuriser et maintenir l’instance

Désactivez l’inscription publique, imposez des mots de passe robustes et activez l’authentification à deux facteurs pour les comptes sensibles. Limitez les administrateurs, révisez régulièrement les clés SSH et protégez l’accès au VPS avec le pare-feu.

Installez rapidement les mises à jour de sécurité, mais ne changez pas de version GitLab aveuglément. GitLab impose des chemins de mise à niveau avec des versions intermédiaires obligatoires. Il ne faut pas sauter directement plusieurs versions majeures. Consultez le chemin correspondant à la version installée, sauvegardez l’instance, puis mettez à jour étape par étape en épinglant chaque image Docker nécessaire.

Après chaque mise à niveau, contrôlez les journaux, l’état des services et l’intégrité de l’installation :

docker exec -t gitlab gitlab-ctl status
docker exec -t gitlab gitlab-rake gitlab:check SANITIZE=true

Sauvegarder GitLab correctement

Créez une sauvegarde applicative avec l’outil fourni :

docker exec -t gitlab gitlab-backup create

Le résultat est enregistré dans le volume monté sous /var/opt/gitlab/backups. Cette sauvegarde couvre notamment les dépôts, la base de données, les artefacts et les données téléversées.

Elle ne suffit pas. Le répertoire /etc/gitlab contient la configuration et des secrets indispensables au déchiffrement de certaines données. Sauvegardez donc séparément le dossier local config :

tar -czf gitlab-config-backup.tar.gz ./config

Conservez les sauvegardes de données et de configuration ensemble, sur un stockage distinct du VPS. Chiffrez-les, testez leur restauration et appliquez une politique de rétention. Notre guide sur les sauvegardes chiffrées avec restic détaille l’externalisation. Une sauvegarde jamais restaurée en environnement de test reste une sauvegarde dont la fiabilité n’est pas démontrée.