Runners CRACI vs runners hébergés par GitHub

Les mêmes workflows, un runner plus rapide

Si vous utilisez GitHub Actions, vos jobs s'exécutent sur des runners hébergés par GitHub, sauf si vous avez mis en place les vôtres. Ils sont pratiques : chaque job obtient une machine virtuelle neuve, il n'y a rien à exploiter, et Linux, Windows et macOS sont tous disponibles.

CRACI est un runner compatible avec GitHub Actions. Installez la GitHub App CRACI sur votre organisation, sur tous les dépôts ou sur une sélection, et changez une ligne dans votre workflow :

runs-on: craci

Vos fichiers de workflow, vos actions et l'interface GitHub ne changent pas. CRACI remplace le runner, pas GitHub Actions, et vous apporte trois choses qu'un runner généraliste n'offre pas : des builds plus rapides, une facture plus basse et une sécurité de la chaîne d'approvisionnement intégrée à la machine qui exécute le job.

Vitesse

Sur CRACI, les builds se terminent en environ deux fois moins de temps que sur les runners hébergés standard de GitHub. Trois éléments s'additionnent : un matériel plus rapide, une attente plus courte avant le démarrage d'un job, et le cache.

Le gain sur vos propres builds dépend de la charge de travail. Les compilations et les suites de tests limitées par le CPU gagnent le plus ; les jobs qui passent l'essentiel de leur temps à attendre le réseau ou des services externes gagnent moins. Ce qui aide :

• Des tailles de runner de 1 à 32 unités de calcul, pour que les jobs lourds puissent en demander davantage.
• Du x86-64 et de l'ARM64 natifs, pour que les builds ARM n'aient pas besoin d'émulation.
• La prise en charge du cache GitHub Actions, ainsi que Docker Engine, Buildx et Compose v2 dans chaque job.
• La virtualisation imbriquée en x86-64, pour les jobs qui démarrent leurs propres machines virtuelles.

Le meilleur test reste votre propre pipeline : migrez un job et comparez les temps côte à côte dans GitHub.

Coût

Deux choses réduisent la facture en même temps. Chaque minute coûte moins cher, et un build plus rapide en utilise moins.

CRACI facture $0.002 par minute vCPU, mesurée à la seconde : un runner Linux standard à 2 vCPU coûte donc $0.004 par minute. GitHub affiche son runner Linux x64 standard à 2 cœurs à $0.006 par minute : la minute CRACI coûte donc environ 33 % de moins.

Un build de 10 minutes

Prenons un build qui dure 10 minutes sur un runner à 2 cœurs hébergé par GitHub :

L'écart de prix permet à lui seul d'économiser environ 33 %. C'est le build plus court qui porte l'économie à environ 67 %. Si un build n'est pas plus rapide sur votre charge de travail, vous payez tout de même le prix par minute inférieur.

Ce qui change aussi la facture

• Arrondi. GitHub arrondit chaque job à la minute entière supérieure ; CRACI mesure à la seconde. Un job de 10 minutes 20 secondes est facturé 11 minutes sur GitHub, et les pipelines comportant de nombreux jobs courts (lint, shards de tests, vérifications) paient beaucoup de secondes inutilisées.
• Minutes incluses. GitHub inclut 2 000 à 50 000 minutes par mois selon votre plan, et les runners standard sont gratuits sur les dépôts publics. CRACI n'a ni offre gratuite ni minutes incluses : vous payez chaque minute de build dès la première, sans frais mensuels. Dans l'enveloppe de GitHub, le coût marginal est nul.
• Architecture et taille. CRACI facture le même tarif en ARM64 et en x86-64. Le runner arm64 à 2 cœurs de GitHub coûte $0.005 par minute : les $0.004 de CRACI représentent donc 20 % de moins. À 32 vCPU, CRACI coûte $0.064 par minute, soit environ 22 % de moins que les $0.082 de GitHub en x64, mais le runner arm64 à 32 cœurs de GitHub, à $0.050, est moins cher à la minute que celui de CRACI. La mémoire diffère aussi : une unité de calcul CRACI dispose de 3 Go de RAM par vCPU, et le runner privé standard à 2 cœurs de GitHub de 8 Go. Tenez compte du profil dont vos builds ont besoin avant de comparer.

Consultez les tarifs de CRACI pour les conditions actuelles.

La sécurité de la chaîne d'approvisionnement dans le runner

Voici ce que fait un runner CRACI et qu'un runner généraliste n'est pas conçu pour faire.

Un enregistrement de chaque dépendance récupérée par le build

Pendant l'exécution de chaque job, un proxy qui comprend les paquets enregistre le trafic vers les sources de paquets : sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement. Les preuves suivent les caches CI : les paquets restaurés depuis un cache sont donc bien comptés. Chaque job produit une SBOM en CycloneDX ou SPDX, avec un état de complétude par job et par cache.

Le graphe de dépendances de GitHub est construit à partir des manifestes et des lockfiles de votre dépôt et peut être exporté en SPDX. Il décrit le dépôt, pas un build précis.

Un contrôle de ce qu'un build peut atteindre

Les politiques de trafic sortant de CRACI sont en refus par défaut ou en autorisation par défaut, avec 24 presets intégrés de sources logicielles, des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git, et des règles explicites TLS, TCP, UDP et ICMP. Les politiques sont validées avant le démarrage du job, bloquent tout en cas d'échec et envoient une alerte en cas de violation. Sous une politique de refus par défaut, une dépendance compromise qui tente de joindre un hôte inattendu est arrêtée au niveau du runner.

Les runners plus grands de GitHub offrent des adresses IP statiques et le réseau privé Azure, qui vous permettent de gérer l'accès sortant via votre propre réseau Azure. C'est utile, et c'est une approche différente : une infrastructure réseau que vous configurez dans Azure plutôt qu'une politique associée au job.

Provenance

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance et ne revendique aucun niveau SLSA.

GitHub propose des artifact attestations fondées sur Sigstore, qui, selon GitHub, fournissent SLSA v1.0 Build Level 2 seules et Level 3 avec des workflows réutilisables. Si une provenance signée ou un niveau SLSA formel est une exigence pour vous, c'est un point en faveur de GitHub.

Isolation et localisation des données

Les jobs CRACI s'exécutent dans des machines virtuelles isolées. Sur le plan Enterprise, CRACI propose la résidence des données dans l'UE, avec une exécution des builds sur une infrastructure bare metal européenne.

Quand rester sur les runners hébergés par GitHub

• Vous avez besoin de runners Windows ou macOS. CRACI ne fonctionne que sous Linux aujourd'hui ; Windows et macOS figurent sur la roadmap.
• Vos dépôts sont publics et les runners standard vous couvrent gratuitement.
• Votre usage tient dans les minutes incluses de votre plan.

De nombreuses équipes combinent les deux : les jobs Linux de build et de test sur CRACI, les jobs macOS et Windows sur GitHub. Comme le changement se résume à un label runs-on, vous pouvez migrer un job à la fois.