VPS CI/CD

Vos builds n'ont pas à coûter 10x plus cher que le reste

GitHub Actions facture la minute de build sur des runners mutualisés à 2 vCores. Une équipe qui compile du Rust, builde des images Docker ou lance des suites de tests Playwright dépasse vite 500 €/mois — pour des performances médiocres. Un runner auto-hébergé sur un Quantum (8 vCores EPYC Genoa, 32 GB de RAM, NVMe Gen4) fait le même travail trois fois plus vite, pour un coût fixe mensuel.

Le calcul est rapide : si vos pipelines consomment plus de 2000 minutes/mois de build, l'auto-hébergement est rentable. En dessous, restez sur les runners managés.

GitHub Actions runner en cinq minutes

mkdir actions-runner && cd actions-runner
curl -o runner.tar.gz -L https://github.com/actions/runner/releases/download/v2.321.0/actions-runner-linux-x64-2.321.0.tar.gz
tar xzf runner.tar.gz
./config.sh --url https://github.com/votre-org --token VOTRE_TOKEN
sudo ./svc.sh install && sudo ./svc.sh start

Le runner s'enregistre comme service systemd et dépile les jobs dès le prochain push. Pour les builds Docker, installez Docker sur l'hôte et montez le socket — ou mieux, utilisez le mode rootless.

GitLab Runner : même logique

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

Enregistrez-le avec gitlab-runner register et le token de votre projet. Le mode docker executor isole chaque job dans un conteneur jetable : exactement ce que fait GitLab.com, sauf que le disque derrière est du NVMe Gen4 à 1 M IOPS — le docker pull d'une image de 2 GB prend 3 secondes.

Le cache : là où tout se gagne

La différence entre un pipeline de 12 minutes et un pipeline de 3 minutes tient rarement au CPU : c'est le cache. Layer cache Docker persistant, cache de dépendances (npm, cargo, pip) sur un volume dédié, et registry Docker local en miroir pull-through. Sur un runner mutualisé, chaque job repart d'un disque vierge ; sur votre VPS, tout persiste entre les builds.

Sécurité : un runner est une porte dérobée si vous l'oubliez

Un runner exécute du code arbitraire depuis vos dépôts — y compris depuis les pull requests de forks si vous l'autorisez. Trois règles non négociables : runner dédié aux dépôts privés uniquement (jamais de runner partagé sur un dépôt public), secrets injectés via les variables CI protégées et non dans les fichiers, et UFW qui n'expose que le SSH. Notre guide de durcissement Ubuntu couvre le reste.

Dimensionner pour l'équipe

Un Quantum absorbe 3-4 builds parallèles de taille moyenne. Une équipe de 15 développeurs qui pousse 50 fois par jour tient largement. Au-delà, ajoutez un second Quantum plutôt qu'un plus gros serveur : deux runners isolés valent mieux qu'un gros point unique de défaillance.