CRACI est le runner sur lequel tournent vos builds

Une ligne suffit pour déplacer le build

CRACI remplace le runner, pas GitHub Actions. Vos fichiers de workflow, vos actions et vos secrets restent où ils sont ; seul l'endroit où le job s'exécute change :

jobs:
  build:
    runs-on: craci

Les exécutions apparaissent toujours dans GitHub : pull requests, checks et logs restent là où votre équipe les consulte déjà. C'est le rôle de la GitHub App, que vous installez sur tous vos dépôts ou sur une sélection.

Ce que sont les runners

• Tailles de 1 à 32 unités de calcul, chacune de 1 vCPU et 3 Go de RAM, 2 par défaut. Définissez la taille de chaque job avec cracicorp/setup@v1 et son paramètre size:.
• x86-64 et ARM64 natifs au même tarif.
• Images : CRACI Slim, CRACI Slim ARM64 et une image Ubuntu 24.04 compatible GitHub, avec Docker Engine, Buildx et Compose v2.
• Des machines virtuelles isolées pour chaque job. La virtualisation imbriquée est disponible sur x86-64 et en préversion sur ARM64.
• Cache : le cache GitHub Actions, plus le cache des couches de conteneur — caches de couches locaux, distants et par bind mount.
• Intégration au pipeline : une plage d'IP de sortie stable et des modèles de runner au niveau de l'organisation.
• Linux aujourd'hui. Les runners Windows et macOS figurent sur la roadmap.

Les runners sont gérés par CRACI et s'exécutent sur une infrastructure bare metal européenne, avec résidence des données dans l'UE. Les runners hébergés par le client figurent sur la roadmap pour Enterprise ; consultez runners managés ou auto-hébergés pour peser le pour et le contre.

Pourquoi la sécurité de la chaîne d'approvisionnement se joue dans le runner

Le build de production n'est pas le build réalisé sur un ordinateur portable. Les plages de versions ne se résolvent pas de la même façon, les tags bougent, les caches sont chauds ou froids, et l'environnement n'est pas le même. Le seul enregistrement fiable de ce qui a été livré est celui réalisé pendant le build de la release — c'est pourquoi CRACI a placé l'enregistreur dans le runner plutôt qu'à côté. L'argumentaire complet se trouve sur pourquoi la sécurité de la chaîne d'approvisionnement a sa place dans la CI.

Parce que CRACI maîtrise le runner, il peut faire ce qu'un scanner ne peut pas faire :

• Enregistrer, pas scanner. Un proxy qui comprend les paquets observe ce que le job télécharge réellement, y compris les dépendances transitives et les paquets restaurés depuis les caches CI. La SBOM de chaque job porte un état de complétude.
• Appliquer une politique de trafic sortant. La politique est appliquée au niveau du runner, validée avant le démarrage du job, et bloque tout en cas d'échec.
• Restituer les preuves. L'API renvoie les SBOM, les traces réseau et la provenance de chaque job.

Environ deux fois plus rapide que les runners hébergés par GitHub

CRACI exécute les builds environ deux fois plus vite que les runners hébergés standard de GitHub, sur les mêmes workflows et sans les modifier. Le job qui prenait dix minutes en prend environ cinq.

Une CI plus rapide vaut plus que les minutes qu'elle fait gagner. Une pull request qui passe au vert en cinq minutes est encore sous les yeux du relecteur ; celle qui en prend vingt, son auteur est déjà passé à autre chose. Le temps de build est l'intervalle entre l'écriture d'une modification et le moment où l'on sait si elle fonctionne, et chaque ingénieur de l'équipe le paie à chaque push.

Trois facteurs l'expliquent : le matériel, des temps d'attente plus courts et le cache.

Ce que coûte ce gain de vitesse

Comme CRACI facture à la seconde et coûte moins cher à la minute, aller deux fois plus vite ajoute une économie à l'autre au lieu de l'annuler. Pour un build qui dure dix minutes sur un runner x64 à 2 cœurs hébergé par GitHub (prix catalogue GitHub de septembre 2026, CRACI d'octobre 2026) :

Build de dix minutes, 1 000 fois par mois	GitHub-hosted	CRACI
Durée réelle par build	10 minutes	Environ 5 minutes
Coût par build	$0.060	$0.020
Coût par mois	Environ $60	Environ $20

Soit environ 67 % de moins, ou 3 fois moins cher. Sans le gain de vitesse, l'économie se limite à l'écart de prix catalogue, environ 33 % sur x64 à 2 cœurs. Le gain sur vos propres builds dépend de la charge de travail : migrez un workflow et mesurez.

Facturation à la seconde

Les minutes de build sont facturées à la seconde, arrondies à la seconde la plus proche. GitHub arrondit chaque job à la minute supérieure, si bien qu'une matrice de jobs courts est facturée pour du temps jamais utilisé : un job de 30 secondes coûte environ 67 % de moins sur CRACI, et un job de 70 secondes environ 61 % de moins. Pour les jobs longs, l'écart tend vers celui des prix catalogue.

Les minutes de build coûtent $0.002 par minute vCPU, soit $0.004 par minute pour un runner de taille 2, au même tarif sur ARM64. CRACI n'est pas le runner le moins cher du marché, et le prix n'est pas l'argument : l'argument, c'est ce que le runner enregistre pendant qu'il s'exécute. Voir les tarifs.

CRACI face aux autres runners GitHub Actions

Blacksmith, Depot, Namespace et WarpBuild fonctionnent tous comme CRACI : vos workflows restent sur GitHub Actions, seul l'endroit où le job s'exécute change. En vitesse et en prix, ils sont proches les uns des autres, et plusieurs affichent un prix ARM inférieur à celui de CRACI. La différence tient à ce que le runner enregistre et contrôle pendant l'exécution du job.

CRACI fait partie des runners les plus abordables, et c'est celui qui produit une SBOM de ce que le job a réellement récupéré, applique une politique de trafic sortant qui bloque tout en cas d'échec, et renvoie des données de provenance via son API — comme sous-produit de l'exécution du build, sans rien ajouter au workflow. Pour la version complète, ligne par ligne : comparatif des runners GitHub Actions.

Ce qui tourne bien sur CRACI

Tout ce que fait un job GitHub Actions : builds d'applications, images de conteneur, suites de tests. Deux cas méritent d'être cités : les builds Yocto et BitBake d'images Linux embarqué, documentés jusqu'aux runners de taille 32, et les builds pi-gen de Raspberry Pi OS.

Sur la roadmap

• Runners Windows et macOS : sur la roadmap.
• Runners hébergés par le client : sur la roadmap, pour Enterprise.
• Autres systèmes CI : GitHub Actions aujourd'hui, les autres sur la roadmap, sans date pour l'instant.