Des runners CI éphémères sur du matériel vraiment rapide.

GitHub met le job en file avec votre label. Notre contrôleur, qui interroge GitHub en continu en HTTPS sortant, l'apprend en une ou deux secondes et demande l'autorisation au registre d'admission : assez de mémoire sur l'hôte, votre plafond non atteint, le nœud en bonne santé. Un clone lié de l'image courante est créé, démarre, lit une amorce à usage unique et un enregistrement GitHub à usage unique, et prend votre job une vingtaine de secondes après sa mise en file. À la fin du job, la machine s'éteint elle-même et est détruite avec son disque ; une ligne avec les horodatages de GitHub tombe sur votre relevé mensuel.

Chaque job s'exécute dans une machine virtuelle neuve, détruite avec son disque ensuite : rien d'un job n'est censé survivre jusqu'au suivant. Chaque machine est derrière le pare-feu de l'hôte : rien en entrée, et en sortie seulement GitHub, les registres et Internet, jamais une autre machine, notre LAN ou l'hyperviseur. Les clients dédiés ont en plus leur propre VLAN. Être root dans la machine est prévu ; l'isolation est à l'extérieur. L'opérateur peut techniquement accéder à ce qu'un job lit pendant qu'il s'exécute, et le contrat le dit par écrit.

Rien. Aucun port n'est exposé nulle part : le contrôleur appelle GitHub, GitHub ne nous appelle jamais. L'authentification est une GitHub App que vous installez sur votre organisation, dont les permissions sont listées avant d'accepter et que vous pouvez désinstaller à tout moment ; la désinstaller nous coupe l'accès immédiatement.

Le plafond et l'isolation. Le mutualisé vous donne jusqu'à 16 vCPU en parallèle, l'image standard, et une isolation par le pare-feu de l'hôte sur un segment réseau partagé ; il ouvre dès que le pare-feu par machine a passé le test d'isolation depuis l'intérieur d'un runner. Le dédié vous donne jusqu'à 32 vCPU en parallèle, 64 sur accord, un VLAN à vous, et une image de runner construite pour vous avec vos outillages, images de base et certificats. Les deux suivent le même cycle de vie sur le même matériel ; le palier et son statut sont écrits sur votre annexe.

La mémoire est la limite dure et n'est jamais sur-allouée ; le CPU peut l'être. Le registre d'admission sert d'abord le job qui attend depuis le plus longtemps, et ne laisse passer un job plus petit que s'il laisse la place au plus ancien. Les jobs qui ne tiennent pas attendent chez GitHub, exactement comme ils attendraient un runner GitHub occupé, et démarrent dès qu'une machine est détruite. Si vous préférez ne pas attendre, rebasculer un workflow sur les runners de GitHub tient en une variable.

Une vingtaine de secondes entre un job mis en file et un job en cours d'exécution sur une ferme froide, mesurée sur l'hôte d'accès anticipé. Le tableau de preuves de cette page donne les temps de build que nous avons mesurés, avec leurs conditions ; les chiffres GitHub à côté sont des médianes historiques de jobs de production, pas une comparaison à conditions égales, et la page le dit.

Ubuntu 26.04 LTS, reconstruite chaque semaine depuis l'image cloud d'Ubuntu avec l'outillage de GitHub : Node, Go, Java, Python, Docker, Bun, Rust, la CLI GitHub et le cache d'outils tel que les actions setup l'attendent. Chaque téléchargement est vérifié contre l'empreinte publiée par son éditeur, et le manifeste liste chaque téléchargement avec son empreinte ; ce manifeste est le contrat de compatibilité que vous recevez. Les clients dédiés ont leur propre image, construite de la même façon.

Quatre tailles : icr-1c (1 vCPU, 2 Gio), icr-2c (2 vCPU, 8 Gio), icr-4c (4 vCPU, 16 Gio) et icr-8c (8 vCPU, 32 Gio). Chaque tentative de job est une ligne du relevé avec les horodatages de GitHub ; ses minutes sont arrondies à l'entier supérieur par job et pondérées par le nombre de vCPU divisé par quatre : une minute d'icr-8c compte double, une minute d'icr-1c un quart. Le poids est figé au moment du job ; un changement ultérieur du catalogue ne réécrit jamais un relevé passé.

Un job canari tourne toutes les 30 minutes et montre la santé du nœud. En accès anticipé, il n'y a pas d'engagement de disponibilité ; le repli reste entre vos mains : remettez la variable de runner sur ubuntu-latest et vos workflows tournent sur les runners de GitHub sans changement de code. L'engagement arrive avec la colocation dans un centre de données certifié, et il est écrit sur l'annexe à ce moment-là.

Les jobs tournent sur du matériel qui nous appartient en France, sous une société française et le droit européen. Le contenu d'un job vit dans la machine le temps du job et est détruit avec elle. L'opérateur peut techniquement voir ce qu'un job lit pendant qu'il s'exécute, ce que le contrat précise ; lorsque le contenu des jobs comporte des données personnelles, nous agissons comme votre sous-traitant selon l'annexe. GitHub reçoit les enregistrements des runners. La politique de confidentialité liste chaque destinataire et chaque durée de conservation.

Vous installez la GitHub App sur votre organisation ; nous créons vos scale sets ; vous réglez la variable de runner sur icr-4c, et sur icr-8c pour les workflows lourds. Une semaine de canari sur quelques dépôts, puis le basculement de l'organisation quand vos tech leads le décident. Le contrat est une courte annexe de service signée par les deux sociétés ; le prix est contractuel, pas affiché.

Aujourd'hui, ICR sert GitHub Actions pour des organisations GitHub.com, via le protocole des scale sets de runners de GitHub. GitLab et GitHub Enterprise Server ne sont pas pris en charge.

Trois raisons que nos clients nous donnent : le matériel est en France, détenu par une société française, sous le droit européen ; un AMD EPYC dédié avec du stockage NVMe est plus rapide que des runners cloud partagés sur des builds limités par le processeur, à un prix contractuel ; et vous savez qui exploite le service, ce qu'il y a dans l'image et ce qui vous a été facturé. Quand un cloud public est le bon outil pour vous, nous le disons.

Remettez la variable de runner sur les runners de GitHub : c'est la sortie, à tout moment, sans nous demander. Le contrat a un préavis mensuel et aucun engagement de durée au-delà du pilote. Désinstallez l'App et la ferme n'a plus rien de vous ; le contenu des jobs a été détruit avec chaque job, et seuls les relevés restent, pour la durée légale de conservation des factures.