Pourquoi faire tourner mon propre runner plutôt que ceux hébergés par GitHub ?

Trois vraies raisons : vos propres dépendances et votre toolchain intégrés (pas de réinstallation à chaque exécution), l'accès à des ressources privées comme un registre interne ou une base de données, et le contrôle de la machine — sa taille, ses caches, son réseau. Si les minutes hébergées par GitHub et un environnement propre vous conviennent, restez dessus. Auto-hébergez quand vous avez précisément besoin de l'une de ces trois choses.

De combien de CPU et de RAM un runner a-t-il besoin ?

Ça dépend entièrement de votre build. Un job typique de compilation-et-test est à l'aise avec 2 cœurs et 4 à 8 Go — Small ou Medium ici. Les builds lourds (grosses compilations natives, grandes images Docker, suites de tests gourmandes en mémoire) veulent plus, et vous devriez dimensionner sur votre vrai job, pas sur une estimation. Observez une exécution réelle et vous saurez.

Un seul runner peut-il gérer plusieurs dépôts ?

Un runner peut être enregistré auprès d'une organisation et récupéré par plusieurs dépôts, un job à la fois par défaut. Pour plus de parallélisme, faites tourner plus de runners — chacun est son propre service systemd. Gardez-les simplement tous sur des dépôts privés.

Dois-je vous donner une pièce d'identité ?

Non. Un e-mail pour s'inscrire, USDC ou USDT pour payer. Pas de documents, root en une minute environ.

Faire tourner un runner GitHub Actions auto-hébergé sur un VPS

Q: Est-ce sûr d'utiliser un runner auto-hébergé ?

Sur un dépôt privé, oui. Sur un dépôt public, non — jamais. Un workflow exécute du code arbitraire de celui qui le déclenche, et sur un dépôt public la pull request d'un inconnu peut faire tourner son code sur votre runner. La doc de GitHub dit la même chose. Gardez les runners auto-hébergés pour les dépôts privés, ou acceptez de remettre votre machine à Internet.

Les runners hébergés par GitHub sont un bon choix par défaut. Vous cessez d'en avoir besoin à l'instant où un build veut quelque chose qu'ils n'ont pas — votre registre de paquets privé, une version précise de toolchain que vous en avez marre de réinstaller à chaque exécution, une base de données sur votre propre réseau, ou simplement plus de contrôle sur la machine. C'est là qu'un runner auto-hébergé sur un VPS gagne sa place.

Ce guide en met un en marche correctement : installé, enregistré, en vie sous systemd, et — la partie que les gens ratent — sûr. Commençons par cette dernière, parce que c'est celle qui mord.

La seule règle de sécurité

Un workflow GitHub Actions exécute du code arbitraire — ce qui est dans le fichier de workflow, et tout ce que ce code embarque. Sur votre propre dépôt, c'est votre code, et c'est bien. Sur un dépôt public, une pull request d'un inconnu peut faire tourner son code sur votre runner. Ce n'est pas un bug ; c'est ainsi que fonctionne la CI. La documentation de GitHub le dit clairement : n'utilisez pas de runners auto-hébergés avec des dépôts publics.

Donc la règle est simple et non négociable : les runners auto-hébergés sont pour les dépôts privés. Si votre dépôt est public, utilisez les runners hébergés par GitHub et passez à autre chose. Tout ce qui suit suppose un dépôt privé.

Ce qu'un runner demande à la machine

Ça dépend du build, et vous devriez dimensionner sur le vôtre plutôt que sur un chiffre pris sur une page :

Un job typique de compilation-et-test — 2 cœurs et 4 à 8 Go, c'est confortable. Small (8 $, 4 vCPU / 4 Go) ou Medium (12 $, 6 vCPU / 6 Go) couvre la plupart.
Les builds plus lourds — grosses compilations natives, grandes images Docker, suites de tests gourmandes en mémoire — veulent plus de marge. Observez une exécution réelle (htop pendant le build) et dimensionnez sur ce que vous voyez vraiment, pas sur l'espoir.

Le disque compte aussi : caches de build, couches Docker et dépôts clonés s'accumulent. Gardez-le à l'œil et élaguez.

1. Préparer la machine

Créez un utilisateur non-root pour le runner — l'installateur de GitHub refuse de toute façon de tourner en root, et c'est comme ça que vous le voulez :

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # uniquement si vos builds ont vraiment besoin de sudo

Installez ce dont vos builds ont besoin — une toolchain de langage, Docker, des outils de build. Par exemple, si vos jobs construisent des conteneurs :

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. Télécharger et enregistrer le runner

Dans votre dépôt (ou organisation) sur GitHub, allez dans Settings → Actions → Runners → New self-hosted runner. GitHub vous donne les commandes de téléchargement exactes et un jeton d'enregistrement (il est éphémère — prenez-le frais). En tant qu'utilisateur runner :

sudo -iu runner
mkdir actions-runner && cd actions-runner
# utilisez l'URL exacte que GitHub affiche pour votre OS/architecture :
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh demande un nom de runner, des labels et un dossier de travail — les valeurs par défaut suffisent pour commencer. Les labels sont la façon dont votre workflow cible ce runner (runs-on: self-hosted).

3. Le faire tourner comme un service systemd

Le runner est livré avec un assistant qui installe un service systemd pour vous — utilisez-le, pour que le runner survive aux redémarrages et redémarre en cas d'échec. Toujours dans l'installation de l'utilisateur runner, mais les commandes de service ont besoin de root :

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

Ça enregistre actions.runner.* comme unité systemd tournant sous l'utilisateur runner, démarrant au boot. Les logs vont dans journald :

sudo journalctl -u 'actions.runner.*' -f

De retour sur la page Runners de GitHub, votre runner affiche maintenant Idle — point vert. Pointez un workflow dessus :

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

Poussez, et le job tourne sur votre machine.

4. Le garder propre

Un runner auto-hébergé réutilise son système de fichiers entre les jobs — c'est le gain de vitesse (caches chauds) et le piège (état résiduel). Deux habitudes le gardent en bonne santé :

Élaguez régulièrement. Docker surtout — docker system prune dans un cron, sinon le disque se remplit silencieusement de couches mortes.
Ne stockez pas de secrets sur la machine. Utilisez les secrets GitHub Actions, injectés par exécution, pas des fichiers posés dans le home du runner. Si le runner est compromis, tout ce qui est sur le disque part avec.

Si vous avez besoin d'un environnement vraiment propre par job, faites tourner chaque job dans une étape conteneurisée — le runner reste, le désordre du job non.

Quand auto-héberger, honnêtement

Auto-hébergez quand vous avez besoin de votre propre toolchain intégrée, d'un accès à des ressources réseau privées, ou du contrôle de la machine. Restez sur les runners hébergés par GitHub quand un environnement propre et jetable et leurs minutes vous conviennent — c'est franchement plus simple, et le simple a de la valeur. Et jamais, sur un dépôt public, n'auto-hébergez. Celle-là n'est pas une préférence.

Si un runner sur dépôt privé est ce qu'il vous faut : choisissez un plan — Small (8 $) pour les builds légers, Medium (12 $) quand ils s'alourdissent — payez en USDC ou USDT (pas de KYC, pas de documents), et vous aurez root en environ 60 secondes. Ensuite déroulez cette page et vous aurez un runner qui ramasse des jobs quelques minutes plus tard.