CRACI vs WarpBuild

En bref

WarpBuild est un fournisseur de runners GitHub Actions. Il propose des runners hébergés sous Linux, Windows et macOS, un cache rapide, des runners à snapshots, des builders Docker distants et une option bring-your-own-cloud (BYOC) qui exécute les mêmes runners dans votre compte AWS, GCP ou Azure. Si vous voulez la couverture de plateformes la plus large chez un seul fournisseur de runners, ou des runners dans votre propre cloud, WarpBuild est une option solide.

CRACI est un runner compatible avec GitHub Actions, construit autour de la sécurité de la chaîne d'approvisionnement : chaque job produit une SBOM de ce qu'il a récupéré et s'exécute sous une politique de trafic sortant. WarpBuild se bat sur la vitesse, le prix et l'emplacement du runner ; CRACI sur ce que le runner enregistre et contrôle. Tous deux remplacent le runner hébergé par GitHub : il faut donc choisir.

En un coup d'œil

Ce que WarpBuild fait bien

• Plateformes et tailles. Des runners Linux en x86-64 (Ubuntu 22.04, 24.04 et 26.04) et en arm64 (24.04 et 26.04), de 2 vCPU et 8 Go de RAM jusqu'à 32 vCPU et 128 Go, des runners Windows Server 2022 et 2025 à partir de 4 vCPU, macOS 14, 15 et 26 sur Apple M4 Pro, et des runners Linux arm64 sur Apple Silicon. La virtualisation imbriquée est disponible sur Linux x86-64.
• Isolation. Chaque runner est une machine virtuelle éphémère, créée pour le job et détruite ensuite, avec son propre volume de stockage chiffré. WarpBuild affirme ne pas accéder à votre code et ne pas stocker les secrets de build.
• Cache et Docker. Un cache sans limite de taille, facturé $0.20 par Go et par mois sur les runners hébergés, le cache des couches de conteneurs, des runners à snapshots qui restaurent un état de machine préparé, et des builders Docker distants avec des builds natifs amd64 et arm64 qui fonctionnent aussi depuis d'autres systèmes CI.
• Bring your own cloud. BYOC exécute des runners gérés par WarpBuild dans votre propre compte AWS, GCP ou Azure, dans n'importe quelle région, avec des IP statiques, des instances spot, des disques en standby et des images de VM personnalisées. WarpBuild affiche les runners BYOC Linux et Windows à $0.002 par minute, options gratuites, en plus de ce que vous payez à votre fournisseur cloud.
• Enterprise. SOC 2 Type II couvrant la sécurité, la disponibilité et la confidentialité, infrastructure propre à une région, SAML SSO, SCIM, un SLA de disponibilité de 99,9 % garanti par des crédits, des warm pools qui démarrent les jobs en moins de 10 secondes, le débogage SSH et la prise en charge de GitHub Enterprise Server.

Côté vitesse, WarpBuild annonce des builds deux fois plus rapides que les runners hébergés par GitHub, et deux à dix fois plus rapides sur sa page de tarifs. Ce sont les affirmations de WarpBuild, et nous n'avons pas comparé CRACI à WarpBuild par un benchmark : le test le plus juste reste votre propre pipeline.

Prix et dimensionnement

En x86-64, les deux affichent le même prix à la minute : $0.004 à 2 vCPU et $0.064 à 32 vCPU. Le prix arm64 de WarpBuild est plus bas, car CRACI facture ARM64 au même tarif que x86-64. BYOC reporte le coût de calcul sur votre propre facture cloud. CRACI décompte à la seconde plutôt qu'à la minute : les jobs courts sont donc facturés pour les secondes où ils s'exécutent. La mémoire par vCPU diffère aussi (3 Go sur CRACI, 4 Go sur WarpBuild Linux) : vérifiez donc ce dont vos builds ont besoin avant de comparer. Consultez les tarifs de CRACI pour les conditions actuelles.

Ce qui distingue CRACI

CRACI traite le build comme la source de vérité sur ce que vous livrez.

Un enregistrement de ce que le build a récupéré

Pendant l'exécution de chaque job, un proxy qui comprend les paquets enregistre le trafic vers les sources de paquets : npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache est donc toujours pris en compte. La SBOM de chaque job, en CycloneDX ou SPDX, porte un état de complétude par job et par cache : vous savez quand l'enregistrement est complet et quand il ne l'est pas.

Une politique de trafic sortant fournie avec le runner

Les politiques CRACI sont en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés, des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git via HTTPS et SSH, 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. Les runners CRACI utilisent aussi une plage d'IP sortantes stable.

La documentation de WarpBuild ne décrit pas de politique de trafic sortant par job pour ses runners hébergés. Avec BYOC, les runners se trouvent dans votre propre réseau, et le guide de durcissement AWS de WarpBuild montre comment resserrer les règles sortantes avec vos propres groupes de sécurité, en listant les points de terminaison dont un runner a besoin. Cela fonctionne, mais c'est de la configuration réseau que vous maintenez dans votre compte cloud, et non une politique attachée au job.

Provenance et surveillance

• Données de 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.
• Surveillance de ce qui a été livré. Les SBOM surveillées sont réévaluées en continu par rapport aux nouvelles vulnérabilités, et les résultats sont agrégés entre les builds et les dépôts.

Réservez une démo pour voir la SBOM, la trace réseau et la provenance de l'un de vos propres workflows.

Lequel choisir

WarpBuild convient mieux lorsque

• Vous avez besoin de runners macOS ou Windows. CRACI est uniquement sous Linux aujourd'hui ; Windows et macOS figurent sur la roadmap.
• Vous voulez des runners dans votre propre compte AWS, GCP ou Azure. CRACI ne propose pas encore de runners hébergés par le client ; ils figurent sur la roadmap pour Enterprise.
• Vous utilisez GitHub Enterprise Server, que CRACI ne prend pas en charge aujourd'hui.
• Vous dépendez aujourd'hui de runners à snapshots ou de builders Docker distants.
• Votre objectif principal est le coût à la minute le plus bas en arm64 ou en BYOC.

CRACI convient mieux lorsque

• Vous devez montrer ce qui est entré dans une release, avec un état de complétude, à partir du build lui-même.
• Vous voulez une politique de trafic sortant attachée à chaque job sans la construire dans votre réseau cloud.
• Vous voulez surveiller les SBOM de ce que vous avez livré.
• Vous avez besoin de la résidence des données dans l'UE, disponible sur le plan Enterprise de CRACI.

Ce à quoi vous renoncez avec CRACI. Les jobs Windows et macOS, les runners dans votre propre cloud et GitHub Enterprise Server, que WarpBuild propose tous aujourd'hui, ainsi que les prix plus bas en arm64 et en BYOC. Ce que vous gagnez, c'est un enregistrement du build que la sécurité et la conformité peuvent utiliser sans scanner supplémentaire dans le pipeline.

Pour le Cyber Resilience Act

Le Cyber Resilience Act demande aux fabricants de connaître les composants de leurs produits, d'en gérer les vulnérabilités et de conserver des preuves. Le produit de WarpBuild est une infrastructure CI. CRACI automatise une part importante de la visibilité et des preuves sur la chaîne d'approvisionnement logicielle dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA : SBOM de build exportées en CycloneDX ou SPDX, suivi des vulnérabilités et provenance via l'API. Consultez les preuves CRA.

Quitter WarpBuild

CRACI remplace le runner, pas GitHub Actions. Les workflows et l'interface GitHub restent les mêmes, et le label du job devient runs-on: craci. Les jobs disposent de Docker Engine, Buildx et Compose v2, d'une image Ubuntu 24.04 compatible GitHub et de la virtualisation imbriquée sur x86-64. Découvrez l'intégration CI/CD et la génération de SBOM au build.

WarpBuild vs CRACI : questions fréquentes

Tarifs, BYOC, plateformes et sécurité, d'après les informations publiées par chaque éditeur

Qu'est-ce que WarpBuild ?

WarpBuild est un fournisseur de runners GitHub Actions. Il exécute vos jobs sur ses propres runners Linux, Windows et macOS, ou sur des runners gérés par WarpBuild dans votre compte AWS, GCP ou Azure (BYOC). Il vend aussi des builders Docker distants, des runners à snapshots et un cache pour les artefacts et les couches de conteneurs.

Combien coûte WarpBuild ?

En septembre 2026, les runners Linux hébergés de WarpBuild coûtent $0.004 par minute pour 2 vCPU en x86-64 et $0.003 en arm64, jusqu'à $0.064 et $0.048 à 32 vCPU. Windows commence à $0.016 par minute pour 4 vCPU, macOS sur M4 Pro à $0.08 pour 6 vCPU. Les runners BYOC coûtent $0.002 par minute en plus de votre facture cloud. Le stockage du cache coûte $0.20 par Go et par mois, et la facturation se fait à la minute.

WarpBuild est-il moins cher que CRACI ?

En arm64, oui ; en x86-64, le tarif affiché est identique. CRACI facture $0.004 par minute pour 2 vCPU en x86-64 comme en ARM64, contre $0.004 en x86-64 et $0.003 en arm64 chez WarpBuild. À 32 vCPU, tous deux affichent $0.064 par minute en x86-64. WarpBuild présente BYOC comme son option la moins chère à grande échelle, puisque vous payez $0.002 par minute plus votre propre facture cloud. CRACI décompte à la seconde plutôt qu'à la minute : les jobs courts sont donc facturés pour les secondes où ils s'exécutent. Ce que CRACI ajoute sur le runner, c'est l'enregistrement du build : une SBOM pour chaque job, une politique de trafic sortant, des données de provenance et la surveillance des vulnérabilités.

Qu'est-ce que WarpBuild BYOC, et CRACI peut-il s'exécuter dans mon propre cloud ?

BYOC exécute des runners gérés par WarpBuild dans votre propre compte AWS, GCP ou Azure, dans n'importe quelle région, avec des IP statiques, des instances spot, des disques en standby et des images de VM personnalisées. CRACI exécute aujourd'hui des runners managés sur une infrastructure européenne, et les runners hébergés par le client figurent sur la roadmap pour Enterprise.

WarpBuild génère-t-il des SBOM ou une provenance de build ?

Cela ne figure pas parmi ses fonctionnalités documentées. WarpBuild se concentre sur le calcul, le cache et l'emplacement du runner. CRACI enregistre les paquets que chaque job récupère, y compris ceux restaurés depuis les caches, et produit une SBOM CycloneDX ou SPDX avec un état de complétude. L'API renvoie les SBOM, les traces réseau et la provenance.

WarpBuild peut-il restreindre ce qu'un build peut atteindre sur le réseau ?

La documentation de WarpBuild ne décrit pas de politique de trafic sortant par job pour ses runners hébergés. Avec BYOC, les runners se trouvent dans votre propre réseau, et son guide de durcissement AWS montre comment resserrer les règles sortantes avec vos propres groupes de sécurité. CRACI applique une politique de trafic sortant sur le runner pour chaque job : refus ou autorisation par défaut, 24 presets de sources logicielles intégrés, validation avant le démarrage du job et blocage total en cas d'échec.

CRACI prend-il en charge Windows, macOS ou GitHub Enterprise Server ?

Pas aujourd'hui. CRACI exécute Linux en x86-64 et ARM64, Windows et macOS figurent sur la roadmap, et il ne prend pas en charge GitHub Enterprise Server. WarpBuild propose des runners Windows et macOS, ainsi que la prise en charge de GitHub Enterprise Server sur son plan enterprise.

WarpBuild est-il conforme à SOC 2, et où les données sont-elles conservées ?

WarpBuild indique être certifié SOC 2 Type 2 pour la sécurité, la disponibilité et la confidentialité, et affirme ne pas accéder à votre code ni à vos secrets de build. Les plans Enterprise peuvent conserver les données dans une région choisie. CRACI exécute les builds sur une infrastructure bare metal européenne, propose la résidence des données dans l'UE sur Enterprise, ne stocke pas votre code source et documente ses contrôles de sécurité dans son Trust Center.

WarpBuild est-il plus rapide que CRACI ?

WarpBuild annonce sur sa page d'accueil des builds deux fois plus rapides que les runners hébergés par GitHub, et deux à dix fois plus rapides sur sa page de tarifs. Nous n'avons pas comparé CRACI à WarpBuild par un benchmark : exécutez le même workflow sur les deux et comparez.

Dois-je réécrire mes workflows GitHub Actions pour changer ?

Non. Les deux produits remplacent le runner, pas GitHub Actions. Les workflows, les déclencheurs et l'interface GitHub restent les mêmes ; sur CRACI, le label du job devient runs-on: craci.