CRACI vs Ubicloud

En bref

Ubicloud est une alternative open source aux grands clouds, et ses runners GitHub Actions managés comptent parmi les moins chers du marché : un runner 2 vCPU coûte $0.002 par minute sur du matériel x64 premium et $0.00125 en x64 standard ou en arm64, en septembre 2026. Si votre objectif est de réduire la facture GitHub Actions de vos jobs Linux, Ubicloud coûte moins cher que CRACI, et il s'exécute lui aussi en Europe.

CRACI est une CI qui gère nativement la sécurité de la chaîne d'approvisionnement. C'est aussi un runner compatible avec GitHub Actions, et la migration se fait de la même façon, en une ligne, mais 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 visent le même budget runners : il faut donc choisir l'un des deux.

En un coup d'œil

Ce qu'Ubicloud fait bien

Le prix. Ubicloud s'exécute sur du bare metal loué et répercute l'économie. Il affirme que ses runners divisent la facture GitHub Actions par quatre à sept et offrent un rapport prix-performance sept fois supérieur à celui des runners hébergés par GitHub. Ce sont les chiffres d'Ubicloud, mais les prix catalogue confirment la tendance : entre $0.00125 et $0.002 par minute 2 vCPU, il se situe bien en dessous de GitHub comme de CRACI.

Le choix du matériel. Les runners x64 standard utilisent des processeurs AMD EPYC, les runners premium des puces AMD Ryzen 9 7950X3D optimisées pour la vitesse monocœur, et les runners arm64 des Ampere Altra avec un cœur physique dédié par vCPU. Les nouveaux comptes reçoivent le premium par défaut et se rabattent sur le standard lorsque la capacité premium est saturée. Les tailles vont de 2 à 30 vCPU, avec des images construites à partir des templates runner-images de GitHub.

Le cache sans modifier les workflows. Le cache transparent d'Ubicloud sert actions/cache, les actions de setup et le cache des couches Docker depuis un stockage situé près des runners, ce qui, selon Ubicloud, est jusqu'à quatre fois plus rapide, avec 30 Go par dépôt et par semaine. L'accès SSH aide à déboguer un workflow en échec.

L'open source et l'isolation. Le code d'Ubicloud est public sous AGPL-3.0 : vous pouvez donc lire comment il fonctionne ou l'exploiter vous-même. Chaque job reçoit une machine virtuelle KVM propre et éphémère dont le stockage en bloc est supprimé ensuite, enregistrée via l'API de runners just-in-time de GitHub, et les runners sont hébergés dans des data centers en Allemagne.

Prix et dimensionnement

Le prix catalogue d'Ubicloud est plus bas à toutes les tailles. Les $0.004 par minute 2 vCPU de CRACI représentent le double du tarif x64 premium d'Ubicloud et plus de trois fois son tarif standard et arm64. CRACI décompte à la seconde, arrondi à la seconde la plus proche, et Ubicloud facture à la minute : les jobs courts réduisent donc l'écart. Un job de 30 secondes coûte $0.002 sur CRACI, soit autant qu'une minute facturée en x64 premium chez Ubicloud. Les configurations diffèrent aussi : les runners x64 d'Ubicloud ont 4 Go de RAM par vCPU, ses runners arm64 3 Go, et une unité de calcul CRACI correspond à 1 vCPU avec 3 Go. Consultez les tarifs de CRACI pour les conditions actuelles.

Ce n'est pas sur le prix que CRACI se positionne. Tous deux affirment que leurs runners sont environ deux fois plus rapides que les runners hébergés par GitHub ; CRACI y parvient grâce à un matériel plus rapide, des temps d'attente plus courts et le cache. 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 : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Le contrôle de ce que le build peut atteindre

Une VM propre par job empêche un job d'empoisonner le suivant. Elle n'empêche pas une dépendance compromise d'envoyer vos secrets ailleurs pendant le job. 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 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.

Provenance et surveillance

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance. 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

Le travail d'Ubicloud sur la sécurité répond à la question « peut-on confier ses jobs à ce runner ? » : VM isolées, enregistrement just-in-time, chiffrement et code source publié. CRACI répond lui aussi à cette question, avec des machines virtuelles isolées, aucun code source stocké et la certification ISO 27001, puis à une seconde : « qu'a récupéré ce build, et à quoi s'est-il connecté ? » 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

Ubicloud convient mieux si

• Le prix à la minute le plus bas pour les jobs Linux est l'objectif principal.
• Vous voulez une plateforme open source que vous pourriez aussi exploiter vous-même.
• Vous utilisez déjà Ubicloud pour le calcul ou PostgreSQL et voulez la CI sur la même facture.

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.
• Vous avez besoin de surveiller ce qui a été livré, sans ajouter d'outils à chaque workflow.
• Vous avez besoin de la résidence des données dans l'UE comme clause contractuelle, disponible sur le plan Enterprise de CRACI.

Ce à quoi vous renoncez avec CRACI. Le prix d'Ubicloud, plus bas à toutes les tailles, et son code open source. 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.

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 à bas coût 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 d'Ubicloud à 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.

Ubicloud vs CRACI : questions fréquentes

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

Qu'est-ce qu'Ubicloud ?

Ubicloud est un cloud open source : calcul, PostgreSQL managé, Kubernetes et runners GitHub Actions, construits sur des fournisseurs bare metal tels que Hetzner, Leaseweb et AWS Bare Metal. Vous pouvez utiliser son service managé ou l'exploiter vous-même. Ses runners GitHub Actions s'activent en changeant un label, et chaque job reçoit une machine virtuelle propre et éphémère. Ubicloud a fait partie de la promotion W24 de Y Combinator et a levé $16M en seed.

Combien coûtent les runners Ubicloud ?

En septembre 2026, un runner x64 à 2 vCPU coûte $0.00125 par minute sur du matériel standard et $0.002 sur du matériel premium, attribué par défaut aux nouveaux comptes. Un runner arm64 à 2 vCPU coûte $0.00125. La facturation se fait à la minute, et chaque compte reçoit un crédit mensuel de $2.50, soit environ 1 250 minutes. La page marketing d'Ubicloud cite aussi des runners standard à partir de $0.0010 par minute ; les chiffres donnés ici viennent de sa documentation tarifaire.

Ubicloud est-il moins cher que CRACI ?

Oui. CRACI facture $0.004 par minute 2 vCPU en x86-64 comme en ARM64. Les runners 2 vCPU d'Ubicloud coûtent $0.002 en x64 premium et $0.00125 en x64 standard et en arm64. CRACI décompte à la seconde et Ubicloud à la minute, ce qui réduit l'écart sur les jobs courts : un job de 30 secondes coûte $0.002 sur CRACI, soit autant qu'une minute facturée en x64 premium chez Ubicloud. 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.

Ubicloud est-il plus rapide que CRACI ?

Ubicloud affirme que ses runners sont deux fois plus rapides que les runners hébergés par GitHub, et 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. Nous n'avons pas comparé les deux par un benchmark : exécutez le même workflow sur les deux et comparez.

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

Cela ne figure pas parmi ses fonctionnalités documentées. Les runners d'Ubicloud se concentrent sur le prix, la performance et l'isolation des jobs. 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.

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

Une politique de trafic sortant pour les jobs de runner ne figure pas parmi les fonctionnalités de la documentation GitHub Actions d'Ubicloud, qui couvre les VM isolées, l'enregistrement just-in-time des runners et la conservation des logs de métadonnées. CRACI applique une politique de trafic sortant au niveau du runner : 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.

Où s'exécutent les jobs, et les données peuvent-elles rester dans l'UE ?

Ubicloud répartit ses runners GitHub Actions entre des data centers en Allemagne. CRACI exécute les builds sur une infrastructure bare metal européenne, avec résidence des données dans l'UE sur le plan Enterprise. CRACI ne stocke pas votre code source : il est traité dans la VM du job pendant la durée du build.

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.