CRACI vs RunsOn

En bref

RunsOn, ce sont des runners GitHub Actions auto-hébergés sans l'entretien d'un parc de runners. Une stack CloudFormation ou un module Terraform le déploie dans votre compte AWS ; chaque job reçoit ensuite une nouvelle instance EC2 du type de votre choix, et AWS facture le calcul à prix coûtant. Si vous voulez des runners dans votre propre compte cloud et la facture de calcul la plus basse possible, surtout sur des instances spot, RunsOn est difficile à battre.

CRACI est une CI qui gère nativement la sécurité de la chaîne d'approvisionnement. C'est un runner managé compatible avec GitHub Actions, et la sécurité fait partie du runner au lieu d'être un outil qu'on lui ajoute : CRACI enregistre chaque dépendance externe récupérée par le build, applique une politique de trafic sortant au réseau du build, et transforme cet enregistrement en SBOM, en surveillance des vulnérabilités et en preuves. Les deux produits remplacent le runner sur lequel s'exécutent vos jobs : il faut donc choisir l'un des deux.

En un coup d'œil

Ce que RunsOn fait bien

Votre compte, vos données. Le plan de contrôle, les VM des runners, le cache S3 et les logs se trouvent tous dans votre compte AWS, et les flux de données propres à RunsOn se limitent à la validation de licence, à la télémétrie et au support. Pour les équipes dont la revue de sécurité s'arrête à « un tiers exécute notre code et nos secrets », c'est la réponse que RunsOn est conçu pour apporter. Les runners CRACI sont managés aujourd'hui ; les runners hébergés par le client figurent sur sa roadmap pour Enterprise.

N'importe quelle instance, une par job. Le label runs-on choisit la machine : un job peut donc demander une grande instance optimisée pour le calcul, un GPU, du stockage NVMe local ou Windows. Chaque job reçoit une nouvelle instance EC2 détruite à la fin du job, et RunsOn indique que les jobs démarrent généralement en environ 30 secondes, ou en moins de 6 avec des warm pools.

Le coût. RunsOn n'ajoute aucune marge au calcul AWS et facture une licence forfaitaire, à partir d'environ $348 (€300) par an. Il affirme que le résultat revient 7 à 12 fois moins cher que les runners hébergés par GitHub. Les instances spot avec repli automatique sur des instances à la demande réduisent encore la facture. Ce sont les chiffres de RunsOn ; votre combinaison d'instances et votre région déterminent le chiffre réel.

Le cache et l'observabilité. Un cache adossé à S3 dans votre VPC remplace le cache de GitHub sans son plafond de taille, le cache des couches Docker est intégré, et les sticky disks EBS et les volumes partagés EFS conservent l'état d'un job à l'autre. Les métriques par job et le reporting des coûts vont vers CloudWatch et OpenTelemetry.

Les extensions de sécurité. Une intégration avec StepSecurity Harden-Runner ajoute la surveillance et le filtrage du trafic sortant, ainsi que la détection de l'altération du code source pendant le build, avec une licence enterprise StepSecurity.

Prix et dimensionnement

Sur le seul calcul, RunsOn sur instances spot coûte une fraction des $0.004 par minute 2 vCPU de CRACI. Mais la comparaison ne se limite pas à la minute. Avec RunsOn, vous payez aussi la licence et les services AWS autour des runners, comme les NAT gateways pour les IP statiques, et votre équipe a la charge de la stack : mises à niveau, quotas AWS et incidents. CRACI, c'est un seul prix à la minute, décompté à la seconde, sans abonnement mensuel, et CRACI exploite l'infrastructure. Consultez les tarifs de CRACI pour les conditions actuelles et runners managés ou auto-hébergés pour l'arbitrage plus large.

Côté vitesse, CRACI exécute les builds environ deux fois plus vite que les runners hébergés par GitHub, grâce à un matériel plus rapide, des temps d'attente plus courts et le cache. La vitesse de RunsOn dépend du type d'instance choisi. Nous n'avons pas comparé les deux par un benchmark.

Ce qui distingue CRACI

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 sources Git, ainsi que des presets de téléchargement. Les preuves de dépendances suivent les caches CI : les paquets restaurés depuis un cache sont donc toujours comptés. Cela inclut les dépendances cachées qu'aucun lockfile ne liste, comme le code téléchargé par des hooks d'installation ou des scripts de build, et les couches d'image de base. Chaque job produit une SBOM CycloneDX ou SPDX avec un état de complétude par job et par cache.

Le contrôle de ce que le build peut atteindre

Les security groups décident quels réseaux un runner RunsOn peut atteindre ; ils ne savent pas quel registre de paquets un job est censé utiliser. La politique de trafic sortant de CRACI, si : refus par défaut ou autorisation par défaut, 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 TLS, TCP, UDP et ICMP explicites. 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. Comme la politique n'autorise que ce dont le build a besoin, elle bloque l'exfiltration vers les hôtes dont le build n'a pas besoin, même lors d'une attaque jamais vue.

Harden-Runner sur RunsOn va plus loin sur un point : il surveille aussi la modification de fichiers source pendant le build, ce que CRACI ne fait pas.

Provenance et surveillance

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance et ne revendique aucun niveau SLSA. Il agrège les vulnérabilités de l'ensemble des builds et des dépôts et continue de réévaluer les SBOM surveillées.

Deux questions de sécurité différentes

RunsOn répond à la question « qui détient mon code, mes secrets et l'état de mes runners ? » en conservant le tout dans votre compte AWS. CRACI répond à une autre question : « qu'a récupéré ce build, et à quoi s'est-il connecté ? » CRACI exécute chaque job dans sa propre VM isolée, ne stocke pas votre code source et est certifié ISO 27001. C'est cette seconde réponse que vous demandent un auditeur, un client ou le Cyber Resilience Act.

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

RunsOn convient mieux si

• Les runners doivent s'exécuter dans votre propre compte AWS, à côté de vos ressources VPC.
• Le coût de calcul le plus bas prime, et vous êtes à l'aise pour exploiter une stack dans AWS.
• Vous avez besoin dès aujourd'hui de runners Windows, d'instances GPU ou de types d'instances EC2 précis.
• Vos projets sont non commerciaux, ce que RunsOn couvre gratuitement.

CRACI convient mieux si

• Vous livrez des logiciels pour lesquels vous devez montrer, à partir du build lui-même, ce qui est entré dans chaque release.
• Vous voulez restreindre ce que les builds peuvent atteindre, avec une politique qui bloque tout en cas d'échec et n'exige aucune licence supplémentaire.
• Vous avez besoin de surveiller ce qui a été livré, sans ajouter d'outils à chaque workflow.
• Vous préférez ne pas exploiter d'infrastructure CI et voulez des builds sur une infrastructure européenne.

Ce à quoi vous renoncez avec CRACI. Les runners dans votre propre compte AWS, qui figurent sur la roadmap pour Enterprise, les runners Windows, qui figurent aussi sur la roadmap, et la facture de calcul la plus basse. Ce que vous gagnez : un enregistrement de build que la sécurité et la conformité peuvent exploiter sans un scanner de plus dans le pipeline, sur une infrastructure que vous n'avez pas à exploiter.

Pour le Cyber Resilience Act

Le Cyber Resilience Act de l'UE attend des fabricants qu'ils sachent ce que contient chaque release et qu'ils en traitent les vulnérabilités, avec des obligations de signalement dès septembre 2026 et une application complète à partir de décembre 2027. Un runner auto-hébergé ne produit pas ces preuves à lui seul ; il vous faudrait ajouter des outils SBOM et de scan à vos workflows. CRACI les produit à partir de l'enregistrement du build et exporte les SBOM en CycloneDX ou SPDX. Il automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA.

Passer de RunsOn à CRACI

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 en x86-64. En savoir plus sur l'intégration CI/CD et la génération de SBOM au build. Les startups peuvent postuler au programme startup.

RunsOn vs CRACI : questions fréquentes

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

Qu'est-ce que RunsOn ?

RunsOn, ce sont des runners GitHub Actions auto-hébergés sous forme de produit. Vous déployez une stack CloudFormation ou un module Terraform dans votre propre compte AWS, et RunsOn lance une nouvelle instance EC2 pour chaque job, puis la détruit à la fin du job. Les runners, les caches, les logs et les identifiants restent dans votre compte AWS. Il a été fondé en 2023 par Cyril Rohr, basé à Rennes, en France.

Combien coûte RunsOn ?

En septembre 2026, RunsOn facture une licence annuelle forfaitaire par entité juridique : à partir d'environ $348 (€300) par an sur Starter, environ $1,044 (€900) sur Growth, environ $2,088 (€1,800) sur Scale et environ $4,176 (€3,600) sur Enterprise, selon le nombre de runners que vous lancez par mois. AWS facture directement le calcul, à la seconde, sans marge de RunsOn. RunsOn indique une instance spot x64 à 2 vCPU dans us-east-1 à environ $0.0009 par minute. Il est gratuit pour un usage non commercial et propose un essai de 15 jours.

RunsOn est-il moins cher que CRACI ?

Pour le calcul, oui, et de loin sur les instances spot. CRACI facture $0.004 par minute 2 vCPU, alors qu'une instance spot à 2 vCPU via RunsOn coûte environ $0.0009 par minute dans us-east-1, plus la licence. Le total inclut aussi votre réseau et votre stockage AWS, ainsi que le temps d'exploitation de la stack. Ce que CRACI ajoute au 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.

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

Cela ne figure pas parmi ses fonctionnalités documentées. RunsOn se concentre sur le calcul, le cache, le coût et l'observabilité dans votre compte AWS. 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.

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

Les runners RunsOn se trouvent dans votre VPC : les security groups et le routage AWS s'appliquent donc, et les IP sortantes statiques proviennent de NAT gateways. Pour filtrer le trafic sortant à l'intérieur du job, RunsOn intègre StepSecurity Harden-Runner, qui établit une référence du trafic sortant de chaque job et peut l'appliquer comme liste d'autorisation ; sur RunsOn, il exige une licence enterprise StepSecurity. CRACI applique une politique de trafic sortant au niveau du runner lui-même : refus ou autorisation par défaut, 24 presets de sources logicielles intégrés, validée avant le démarrage du job et qui bloque tout en cas d'échec.

Puis-je exécuter CRACI dans mon propre compte AWS ?

Pas aujourd'hui. Les runners CRACI sont managés, sur une infrastructure européenne, et les runners hébergés par le client figurent sur la roadmap du plan Enterprise. Si des runners dans votre propre compte AWS sont une exigence impérative, RunsOn est conçu exactement pour cela.

CRACI prend-il en charge les runners Windows ou macOS ?

CRACI exécute aujourd'hui Linux en x86-64 et ARM64, avec Windows et macOS sur la roadmap. RunsOn propose Windows Server 2022 et 2025 ainsi que des instances GPU ; avec RunsOn aussi, les jobs macOS restent sur les runners hébergés par GitHub.

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.