← Retour aux ressources
// guide · self-hosting

Déployer GitLab en self-hosted

Ton propre GitLab, sur ton serveur : le code reste chez toi, sans abonnement par utilisateur. Voici comment je le déploie proprement — Docker, HTTPS, sauvegardes, runners CI — et le dimensionnement à ne pas sous-estimer.

Guide30 juil. 2026~9 min · intermédiaire
GitLab CEDockerLet’s Encryptrunnersbackups
// sommaire
01Pourquoi self-host02Le déploiement03Les runners CI04Sauvegardes & maintenance05Sources & ressources
01

Pourquoi self-host

Deux raisons dominent : la souveraineté (le code source ne quitte pas ton infra, utile pour la conformité) et le coût à grande équipe (pas de licence par siège). La contrepartie : c'est toi l'admin — sauvegardes, mises à jour, disponibilité.

i

Le principe de déploiement (Docker, reverse proxy, HTTPS) est le même que dans mon guide Langfuse sur EC2.

02

Le déploiement

GitLab CE tient dans un seul conteneur Docker, avec la config, les logs et les données en volumes persistés. L'image Omnibus gère même le certificat Let's Encrypt toute seule.

docker-compose.ymlcopier
# docker-compose.yml — GitLab CE en un conteneur
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    hostname: gitlab.mondomaine.com
    restart: always
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.mondomaine.com'
        # Let's Encrypt automatique
        letsencrypt['enable'] = true
    ports: ["80:80", "443:443", "22:22"]
    volumes:
      - ./config:/etc/gitlab
      - ./logs:/var/log/gitlab
      - ./data:/var/opt/gitlab
    shm_size: "256m"
!

GitLab est gourmand : compte 4 Go de RAM minimum, 8 Go confortable. En dessous, le premier démarrage échoue ou rame — ne lésine pas sur l'instance.

03

Les runners CI

GitLab sans runner ne fait tourner aucun pipeline. Un runner est un process séparé qui exécute tes jobs CI ; on l'enregistre auprès de l'instance avec un token.

shellcopier
# enregistrer un runner CI pour executer les pipelines
$ docker run -d --name gitlab-runner --restart always \
    -v /srv/gitlab-runner/config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest
$ docker exec -it gitlab-runner gitlab-runner register
i

Une fois les runners en place, tu écris tes pipelines comme dans bien utiliser GitLab CI/CD.

04

Sauvegardes & maintenance

Le point qui fait la différence entre un self-host sérieux et une bombe à retardement. GitLab a une commande de backup intégrée — mais elle n'inclut pas la config et les secrets, qu'il faut sauvegarder séparément.

shellcopier
# sauvegarde complete (repos + base) + la config a part
$ docker exec gitlab gitlab-backup create
# la config et les secrets ne sont PAS dans le backup principal :
$ docker cp gitlab:/etc/gitlab ./gitlab-config-backup
!

Un backup jamais restauré n'est pas un backup. Teste une restauration complète sur une VM à part — c'est tout le sujet de des backups qui marchent vraiment.

05

Sources & ressources

01GitLab Docs — Install GitLab in a Docker containerLa page officielle d'installation via image Docker : setup, config, sauvegarde, mises à jour.↗02GitLab Docs — GitLab installation requirementsLe dimensionnement de référence : 8 vCPU et 16 Go de RAM en baseline pour un nœud unique.↗03GitLab Docs — Configure SSL for a Linux package installationLet's Encrypt est activé par défaut si external_url est en HTTPS ; renouvellement automatique inclus.↗04GitLab Docs — Back up GitLabConfirme noir sur blanc que gitlab.rb et gitlab-secrets.json ne sont pas dans le backup.↗05GitLab Docs — Back up and restore overviewLa vue d'ensemble sauvegarde/restauration — à lire avant de tester ta première restauration.↗06GitLab Docs — Run GitLab Runner in a containerLancer le runner en conteneur, monter le volume de config, et le mettre à jour sans le perdre.↗07GitLab Docs — Registering runnersLe token d'authentification runner remplace l'ancien registration token, supprimé en GitLab 20.0.↗08GitLab Docs — Upgrade GitLabLes chemins de mise à jour et les paliers obligatoires : le point à ne pas improviser.↗

Self-héberger GitLab, c'est reprendre le contrôle de son code et de sa CI, contre la responsabilité de l'admin. Un conteneur Docker, une instance bien dimensionnée, des runners, et surtout des sauvegardes testées : avec ça, ton GitLab est aussi fiable que le SaaS, et il est à toi.