BuildJet s'est arrêté. Voici ce que cela signifie pour le CI géré.

Le 6 février 2026, BuildJet a annoncé la fermeture de son service d'exécution GitHub Actions. Le 31 mars, elle a arrêté de gérer ses travaux. Leur guide de migration demandait aux clients de revenir aux coureurs hébergés sur GitHub.

Il serait facile d’écrire un article expliquant à quel point c’est une excellente nouvelle pour nous. Il est plus utile de prendre cet argument au sérieux, car il est en grande partie correct.

Ce que BuildJet a réussi

GitHub s'est véritablement amélioré. Il existe des coureurs plus grands. Arm64 natif existe sur les forfaits payants. Si l'ensemble de votre argumentaire était « la même chose, mais avec plus de processeurs virtuels », il est désormais beaucoup plus faible qu'il ne l'était en 2022. Tout fournisseur dont le seul différenciateur est la taille de la machine devrait être nerveux.

Ce que nous pensons qu'ils ont eu tort

La taille de la machine n’a jamais été la partie intéressante. Les parties que GitHub n'a pas fermées sont celles qui dominent les vrais pipelines :

• La limite de cache de 10 Go par référentiel et la bande passante limitée qui y est associée
• Pas de cache de couche Docker persistant sans l'envoyer à un registre et inversement
• Mise en cache à l'échelle des branches, de sorte que chaque nouvelle demande d'extraction démarre à froid
• Aucune métrique de ressources par tâche, donc personne ne peut distinguer un coureur sous-dimensionné d'un coureur lent
• Aucune option d'apport de votre propre cloud pour les équipes ayant des exigences en matière de résidence des données

Dans nos propres mesures, le comportement du cache explique plus de temps d'horloge murale CI que le nombre de CPU sur la plupart des pipelines. C’est là l’écart, et il n’a pas été comblé.

La question inconfortable

Si vous évaluez actuellement des coureurs gérés, la bonne question à poser à n’importe quel fournisseur – nous y compris – est de savoir ce qui vous arrivera si nous fermons nos portes.

Notre réponse : la surface d'intégration est une seule ligne. La migration entrante prend cinq minutes et la migration externe prend cinq minutes, car l'exécution est la seule chose que vous avez modifiée. Nous publions la différence inverse exacte sur chaque page de migration. C'est délibéré. Une plateforme qu’il est difficile de quitter est une plateforme qui doit être bonne, et nous préférerions être la deuxième chose.