CRACI vs Namespace

En bref

Namespace est une infrastructure pour développeurs : runners GitHub Actions gérés, builders Docker distants, volumes de cache, exécution distante Bazel et environnements de développement cloud, le tout sur du matériel que Namespace exploite lui-même. 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éellement récupéré et s'exécute sous une politique de trafic sortant.

Les deux produits peuvent restreindre ce qu'un build joint sur le réseau, et les politiques de trafic sortant de Namespace sont bien conçues. La différence tient à ce qui se passe d'autre sur le runner : Namespace se concentre sur la vitesse, les plateformes et le cache, tandis que CRACI enregistre le build et prolonge cet enregistrement jusqu'à la surveillance des vulnérabilités et aux preuves pour le CRA. Les deux remplacent le runner hébergé par GitHub : vous en choisissez donc un.

En un coup d'œil

Ce que Namespace fait bien

• Les plateformes. Linux sur AMD64 (AMD EPYC) et ARM64 (AmpereOne, et Apple Silicon en accès anticipé), Windows sur AMD EPYC, et macOS sur Apple M5 Max ou M4 Pro. Les runners Windows sont inclus à partir du plan Team.
• Les profils de runner. Vous créez un profil dans le tableau de bord avec un système d'exploitation et un format de machine, puis vous le référencez dans runs-on. Les formats vont jusqu'à 64 vCPU sous Linux, et Namespace indique que le support peut débloquer jusqu'à 512 GB de RAM.
• La mise en cache. Les volumes de cache conservent les données sur un stockage local d'une exécution à l'autre : les jobs n'ont donc pas à téléverser et télécharger une archive de cache à chaque fois. Namespace propose aussi la mise en cache des builds Docker, le cache et l'exécution distants Bazel, et des caches Turborepo et Gradle.
• Les politiques de trafic sortant. Les politiques s'exécutent en mode BLOCK, qui refuse tout ce qui n'est pas autorisé, ou en mode ADVISORY, qui enregistre les mêmes décisions sans bloquer afin que vous puissiez construire une liste d'autorisation à partir du trafic réel. Les règles portent sur les domaines, un ensemble de règles géré github-actions maintient les runners en état de marche, et avec l'inspection approfondie des paquets, une politique peut injecter des secrets dans les en-têtes de requête ou acheminer le trafic par un proxy. Un tableau de bord regroupe les requêtes autorisées et refusées par domaine, et chaque instance a sa propre vue du trafic sortant.
• La confiance. Namespace détient une attestation SOC 2 Type II, dont le rapport est disponible dans son Trust Center, et propose une résidence des données exclusive par région sur les plans enterprise.

Namespace publie des résultats clients, comme DuckDB exécutant sa CI « 10x faster ». Ce sont les chiffres de Namespace pour ces clients.

Ce qui distingue CRACI

CRACI traite le build comme la source de vérité de 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 reste donc comptabilisé. La SBOM de chaque job, en CycloneDX ou SPDX, porte un état de complétude par job et par cache. Les journaux de trafic sortant de Namespace vous disent quels domaines un runner a contactés. L'enregistrement de CRACI vous dit quels paquets et quelles versions le build en a tirés.

La politique de trafic sortant, comparée équitablement

Les politiques de 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 sur 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, rejettent les champs inconnus et envoient une alerte en cas de violation.

Namespace a de l'avance sur deux points. Son mode consultatif vous permet d'observer une politique avant de l'appliquer, et le mode surveillance de CRACI figure encore sur la roadmap. Ses règles d'injection de secrets et de proxy n'ont pas d'équivalent chez CRACI. CRACI se distingue par des sources typées selon l'écosystème de paquets et le protocole plutôt que listées comme des domaines, et par le fait que le job qui s'exécute sous la politique produit aussi l'enregistrement des paquets qu'il a récupérés.

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 au regard des nouvelles vulnérabilités, et les résultats sont agrégés sur l'ensemble des builds et des dépôts.

Prix et tailles

Namespace facture en unit minutes, une unité correspondant à 1 vCPU et 2 GB de RAM pendant une minute sous Linux. En septembre 2026, un runner Linux à 2 vCPU et 4 GB coûte $0.002 par minute dans les minutes du plan et $0.003 par minute en dépassement. Le plan Team est à $100 par mois avec 100 000 unit minutes, et Business à $250 par mois avec 250 000. Windows consomme les minutes à deux fois le tarif Linux et macOS à dix fois. L'usage comporte un minimum d'une minute par job, puis il est arrondi à la minute ; l'exemple de Namespace facture 150 secondes comme 3 minutes.

CRACI facture $0.002 par minute vCPU : un runner à 2 vCPU avec 6 GB de RAM coûte donc $0.004 par minute, ARM64 au même tarif, décompté à la seconde, sans abonnement mensuel. Le prix catalogue par minute de Namespace est plus bas, avec un minimum d'une minute par job. Ses formats standard ont 2 GB de RAM par vCPU et ceux de CRACI 3 GB : choisissez donc le format dont vos builds ont besoin avant de comparer. Consultez les tarifs de CRACI pour les conditions en vigueur.

Lequel choisir

Namespace 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 tester une politique de trafic sortant en mode consultatif avant de l'appliquer.
• Vous dépendez de l'exécution distante Bazel ou des volumes de cache.
• Vous exploitez aussi des agents Buildkite ou des environnements de développement cloud et voulez un seul fournisseur.

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 surveiller les SBOM livrées en un seul endroit.
• Vous avez besoin de preuves pour le Cyber Resilience Act.
• Vous avez besoin de la résidence des données dans l'UE, disponible sur le plan Enterprise de CRACI.

Pour le Cyber Resilience Act

Le Cyber Resilience Act demande aux fabricants de connaître les composants de leurs produits, d'en traiter les vulnérabilités et de conserver des preuves. Le produit de Namespace, c'est une CI rapide et une infrastructure de développement. CRACI 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 : SBOM au build exportées en CycloneDX ou SPDX, suivi des vulnérabilités et provenance via l'API. Voir les preuves pour le CRA.

Passer de Namespace à CRACI

Installez la GitHub App CRACI sur votre organisation, avec accès à tous les dépôts ou à une sélection, puis modifiez le label du runner sur un job :

runs-on: craci

Migrez un job à la fois, vérifiez sa SBOM et sa trace réseau, et apprenez-en plus sur l'intégration CI/CD et la génération de SBOM au build.