Runners GitHub Actions auto-hébergés ou runners managés CRACI

Qu'est-ce qu'un runner GitHub Actions auto-hébergé ?

Un runner auto-hébergé est une machine que vous déployez et gérez, et qui exécute des jobs GitHub Actions à la place d'une VM hébergée par GitHub. Il peut s'agir d'un serveur physique, d'une machine virtuelle ou d'un conteneur, sur site ou dans votre compte cloud, et GitHub précise que vous êtes responsable de la machine et de tous ses logiciels.

• Enregistrement : un runner s'enregistre auprès d'un seul dépôt, d'une seule organisation ou d'une seule entreprise à la fois. Enregistrez-le au niveau de l'organisation et utilisez des groupes de runners pour partager des runners entre dépôts.
• Plateformes : l'application runner prend en charge les distributions Linux courantes, Windows 10, 11 et Windows Server, et macOS 11 et versions ultérieures, sur x64 et ARM64.
• Réseau : le runner se connecte à GitHub en HTTPS sortant sur le port 443.
• Mises à jour : l'application runner doit être mise à jour dans les 30 jours suivant une nouvelle version. Elle se met à jour toute seule, sauf si vous désactivez cette option.
• Limites : un job peut s'exécuter jusqu'à 5 jours, contre 6 heures sur les runners hébergés par GitHub, et un job en file d'attente depuis plus de 24 heures échoue.
• Mise à l'échelle : Actions Runner Controller (ARC), un opérateur Kubernetes, dimensionne les runner scale sets selon le nombre de workflows en cours. Les runners enregistrés avec --ephemeral ne prennent qu'un seul job.

Pourquoi les équipes auto-hébergent

Les équipes auto-hébergent pour réduire les coûts à la minute, accéder à des systèmes internes ou à du matériel spécifique, et utiliser une capacité qu'elles paient déjà. Les grands runners de GitHub ne peuvent pas non plus utiliser les minutes incluses : les grosses machines deviennent donc coûteuses sur les runners hébergés.

GitHub ne facture pas à la minute les runners auto-hébergés aujourd'hui. Il avait annoncé des frais de plateforme cloud de $0.002 par minute pour ces runners à partir du 1er mars 2026, puis les a reportés pour se donner le temps de réévaluer son approche. En septembre 2026, la documentation de facturation de GitHub décrit l'usage auto-hébergé comme gratuit. Ce que GitHub ne paie pas, c'est tout ce qui entoure le runner.

Les trois composantes du coût de l'auto-hébergement

Le coût de l'auto-hébergement se compose de l'infrastructure, du temps d'ingénierie et du renforcement de la sécurité. Seule la première composante apparaît sur une facture.

Infrastructure

Vous payez les hôtes, qu'ils exécutent des jobs ou restent inactifs : vous les dimensionnez donc pour votre heure la plus chargée. Ajoutez le stockage des caches et des images, le trafic réseau et ce que vous utilisez pour surveiller et dimensionner automatiquement le parc.

Temps d'ingénierie

La documentation de GitHub est claire sur la responsabilité : avec des runners auto-hébergés, c'est à vous de mettre à jour le système d'exploitation et tous les autres logiciels. En pratique, cela signifie aussi les mises à niveau du runner, les écarts d'images entre hôtes, le nettoyage des disques, les scripts de mise à l'échelle automatique et quelqu'un d'astreinte quand la file d'attente n'avance plus.

Renforcement de la sécurité

Les recommandations de sécurité de GitHub pour les runners auto-hébergés comportent deux avertissements qui méritent d'être lus en entier :

Self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment. GitHub Docs, Secure use reference

Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. GitHub Docs, Secure use reference

GitHub recommande des runners just-in-time qui exécutent au plus un job avant d'être supprimés. Bien le faire suppose des machines éphémères, une isolation entre les jobs, des contrôles sur le trafic réseau sortant et une gestion prudente des secrets. Chacun de ces éléments est un travail que vous concevez, construisez et maintenez.

Bonnes pratiques pour les runners auto-hébergés à grande échelle

Les recommandations de sécurité de GitHub et les pratiques publiées par AWS pour les runners à grande échelle convergent vers la même liste. Chaque élément est un projet à part entière :

• Runners éphémères : un job par machine, pour que rien ne passe d'un job à l'autre.
• Groupes de runners : séparez les runners par dépôt et par environnement, idéalement dans des comptes distincts.
• Identifiants à courte durée de vie : OpenID Connect vers votre cloud plutôt que des clés d'accès à longue durée de vie.
• Contrôle du trafic sortant : limitez ce qu'un job peut atteindre, pas seulement ce qu'il exécute.
• Temps de démarrage : pools préchauffés et images personnalisées, car les machines éphémères démarrent plus lentement.
• Coût : instances spot avec une solution de repli pour les jobs de longue durée.
• Surveillance : métriques sur les jobs en attente, en cours et terminés, avec des alertes.

Sur CRACI, le premier et le quatrième points sont fournis avec le runner : chaque job s'exécute dans une machine virtuelle isolée, sous une politique de trafic sortant validée avant le démarrage du job et qui bloque tout en cas d'échec.

Un modèle de coût à remplir

Exemple A

Données illustratives, pas des benchmarks. 60 000 minutes de build par mois sur des runners à 2 vCPU, $350 par mois pour les hôtes de runners, et 8 heures de maintenance par mois à $85 de l'heure.

• Auto-hébergé : $350 + (8 × $85) = $350 + $680 = $1,030 par mois
• CRACI : 60 000 × $0.004 = $240 par mois

Exemple B

Données illustratives, pas des benchmarks. Les mêmes 60 000 minutes, mais les hôtes coûtent $115 par mois et la maintenance prend 2 heures à $85 de l'heure.

• Auto-hébergé : $115 + (2 × $85) = $115 + $170 = $285 par mois
• CRACI : $240 par mois

Dans l'exemple B, les deux sont proches sur le seul coût de calcul. C'est un résultat réaliste pour les équipes qui ont des hôtes bon marché et une configuration stable. Pour trouver votre propre seuil de rentabilité, soustrayez le coût de vos hôtes du chiffre de CRACI et divisez par votre coût horaire. Avec les hôtes de l'exemple B, cela donne ($240 moins $115) ÷ $85, soit environ 1,5 heure de maintenance par mois.

La formule ne montre pas deux choses. D'abord, le chiffre de CRACI inclut plus que du calcul (voir la section suivante). Ensuite, les heures sont la donnée que la plupart des équipes sous-estiment. Comptez les mises à jour d'images, les correctifs de sécurité, le dimensionnement, le nettoyage des disques et le temps passé sur les jobs en échec, pas seulement la configuration initiale.

Ce que les runners auto-hébergés ne vous apportent pas

Un runner auto-hébergé exécute votre job, mais il n'enregistre pas ce que le job a fait. Sur les runners CRACI, chaque build produit des preuves pendant son exécution :

• Une SBOM de build en CycloneDX ou SPDX, issue d'un proxy qui comprend les paquets et observe ce que le job récupère, y compris les paquets restaurés depuis les caches CI. La complétude est indiquée par job et par cache.
• Une politique de trafic sortant, en refus ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés et des sources personnalisées typées. Les politiques sont validées avant le démarrage du job et bloquent tout en cas d'échec. Les violations déclenchent des alertes.
• Une trace réseau par job, disponible via l'API.
• Des données de provenance, disponibles via l'API.
• Le suivi des vulnérabilités entre builds et dépôts, avec des SBOM surveillées réévaluées en continu.

Vous pouvez construire une partie de cela sur des runners auto-hébergés avec votre propre proxy, vos outils SBOM et votre journalisation réseau. Dans ce cas, le temps nécessaire pour le construire et le maintenir doit figurer dans le modèle de coût ci-dessus.

Ce que CRACI ne propose pas

CRACI ne propose pas aujourd'hui de runners hébergés par le client ni on-premise ; ils figurent sur la roadmap pour Enterprise. Les builds s'exécutent sur les runners managés de CRACI, sur une infrastructure européenne. Si un job doit s'exécuter dans votre propre réseau, sur du matériel qui vous appartient ou dans un environnement isolé (air-gapped), conservez un runner auto-hébergé pour ce job.

• Les runners CRACI ne fonctionnent que sur Linux aujourd'hui ; Windows et macOS figurent sur la roadmap. Les builds macOS et Windows restent là où ils sont.
• x86-64 et ARM64 sont au même tarif.
• Images : CRACI Slim, CRACI Slim ARM64 et une image Ubuntu 24.04 compatible GitHub. La virtualisation imbriquée est disponible sur x86-64 et en préversion sur ARM64.
• GitHub Actions est l'intégration CI prise en charge.

Une configuration mixte est courante. Déplacer un job revient à modifier sa ligne runs-on : vous pouvez donc déplacer la plupart des jobs et en garder quelques-uns sur des runners auto-hébergés. Seuls les jobs sur les runners CRACI bénéficient des SBOM de build et de la politique réseau.

Comment décider

Décidez à partir de vos propres chiffres : le coût et les heures de runners du mois dernier, les preuves qu'on vous demande et un vrai workflow exécuté sur chaque option.

1. Additionnez la facture d'hôtes du mois dernier et les heures que votre équipe a consacrées aux runners, incidents compris.
2. Comptez vos minutes de build.
3. Reportez les deux dans les formules ci-dessus.
4. Listez les preuves qu'on vous demande (SBOM, provenance, contrôles réseau) et ce qu'il faudrait pour les produire sur vos runners actuels.
5. Réservez une démo et exécutez un vrai workflow sur CRACI pour comparer.

Pour en savoir plus sur le fonctionnement des runners : intégration CI/CD, la sécurité chez CRACI et la documentation.

Runners GitHub Actions auto-hébergés : questions fréquentes

Des réponses courtes sur le coût, la configuration, la sécurité et les limites.

Qu'est-ce qu'un runner GitHub Actions auto-hébergé ?

Un runner auto-hébergé est une machine que vous déployez et gérez, et qui exécute des jobs GitHub Actions. Il peut s'agir d'une machine physique, virtuelle ou d'un conteneur, sur site ou dans un compte cloud. Vous y installez l'application runner de GitHub, vous l'enregistrez auprès d'un dépôt, d'une organisation ou d'une entreprise, et vous le ciblez avec runs-on: self-hosted ou vos propres labels.

Les runners GitHub Actions auto-hébergés sont-ils gratuits ?

GitHub ne facture pas à la minute les runners auto-hébergés en septembre 2026. Il avait annoncé des frais de plateforme de $0.002 par minute à partir du 1er mars 2026, puis les a reportés pour réévaluer son approche. Vous payez toujours les machines, leur stockage et leur réseau, ainsi que le temps nécessaire pour les tenir à jour et sécurisées.

Un même runner auto-hébergé peut-il servir plusieurs dépôts ?

Un runner s'enregistre auprès d'un seul dépôt, d'une seule organisation ou d'une seule entreprise à la fois. Pour le partager entre dépôts, enregistrez-le au niveau de l'organisation et contrôlez l'accès avec des groupes de runners, ou exécutez plusieurs instances de runner sur la même machine, chacune enregistrée séparément.

Quels systèmes d'exploitation peuvent exécuter un runner auto-hébergé ?

GitHub prend en charge l'application runner sur les distributions Linux courantes comme Ubuntu 20.04 et versions ultérieures, Debian 10 et versions ultérieures et RHEL 8 et versions ultérieures, sur Windows 10, 11 et Windows Server 2016 à 2022, et sur macOS 11 et versions ultérieures. Elle fonctionne sur x64 et ARM64, et sur ARM32 pour Linux.

Combien de temps un job peut-il s'exécuter sur un runner auto-hébergé ?

Jusqu'à 5 jours, contre 6 heures sur les runners hébergés par GitHub. Un job qui reste en file d'attente plus de 24 heures échoue.

Les runners auto-hébergés sont-ils sûrs pour les dépôts publics ?

GitHub indique que les runners auto-hébergés ne devraient presque jamais être utilisés pour des dépôts publics, car n'importe qui peut ouvrir une pull request et exécuter du code sur la machine. Il recommande des runners éphémères just-in-time qui exécutent au plus un job, avec de l'isolation, un contrôle du trafic sortant et une gestion prudente des secrets.

À quoi sert Actions Runner Controller ?

Actions Runner Controller (ARC) est un opérateur Kubernetes qui orchestre et dimensionne les runners auto-hébergés pour GitHub Actions. Les runner scale sets s'agrandissent et se réduisent selon le nombre de workflows en cours. Vous exploitez toujours le cluster, les images et le réseau qui l'entoure.

Les runners CRACI peuvent-ils tourner dans mon propre réseau ?

Pas aujourd'hui. CRACI propose des runners managés sur une infrastructure européenne, les runners hébergés par le client figurant sur la roadmap pour Enterprise. Les jobs qui doivent tourner dans votre réseau peuvent rester sur des runners auto-hébergés pendant que les autres passent sur CRACI.