01Pourquoi 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é.
Le principe de déploiement (Docker, reverse proxy, HTTPS) est le même que dans mon guide Langfuse sur EC2.
02Le 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.
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.
03Les 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.
Une fois les runners en place, tu écris tes pipelines comme dans bien utiliser GitLab CI/CD.
04Sauvegardes & 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.
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.
05Sources & ressources
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.
GitLab — Install docs ↗