CRACI vs. Namespace

Die kurze Antwort

Namespace ist Entwicklerinfrastruktur: verwaltete GitHub-Actions-Runner, Remote-Docker-Builder, Cache-Volumes, Bazel Remote Execution und Cloud-Entwicklungsumgebungen, alles auf Hardware, die Namespace selbst betreibt. CRACI ist ein GitHub-Actions-kompatibler Runner, der um Lieferkettensicherheit herum gebaut ist. Jeder Job erzeugt eine SBOM dessen, was er tatsächlich geladen hat, und läuft unter einer Egress-Richtlinie.

Beide Produkte können einschränken, was ein Build im Netzwerk erreicht, und die Egress-Richtlinien von Namespace sind gut durchdacht. Der Unterschied liegt darin, was sonst noch auf dem Runner geschieht: Namespace konzentriert sich auf Geschwindigkeit, Plattformen und Caching, und CRACI zeichnet den Build auf und trägt diese Aufzeichnung weiter in die Schwachstellenüberwachung und die CRA-Nachweise. Beide ersetzen den GitHub-gehosteten Runner, Sie entscheiden sich also für einen.

Auf einen Blick

Was Namespace gut kann

• Plattformen. Linux auf AMD64 (AMD EPYC) und ARM64 (AmpereOne und, in Early Access, Apple Silicon), Windows auf AMD EPYC und macOS auf Apple M5 Max oder M4 Pro. Windows-Runner gibt es ab dem Team-Plan.
• Runner-Profile. Sie erstellen im Dashboard ein Profil mit Betriebssystem und Maschinengröße und verweisen dann in runs-on darauf. Unter Linux reichen die Größen bis 64 vCPUs, und laut Namespace kann der Support bis zu 512 GB RAM freischalten.
• Caching. Cache-Volumes halten Daten über Läufe hinweg auf lokalem Speicher, sodass Jobs nicht jedes Mal ein Cache-Archiv hoch- und herunterladen. Namespace bietet außerdem Docker-Build-Caching, Bazel Remote Cache und Execution sowie Turborepo- und Gradle-Caches.
• Egress-Richtlinien. Richtlinien laufen im Modus BLOCK, der alles Nichterlaubte ablehnt, oder im Modus ADVISORY, der dieselben Entscheidungen aufzeichnet, ohne zu blockieren, sodass Sie aus echtem Datenverkehr eine Allowlist aufbauen können. Regeln gleichen Domains ab, ein verwalteter Regelsatz github-actions hält Runner funktionsfähig, und mit Deep Packet Inspection kann eine Richtlinie Secrets in Request-Header einfügen oder Datenverkehr über einen Proxy leiten. Ein Dashboard gruppiert erlaubte und abgelehnte Anfragen nach Domain, und jede Instanz hat ihre eigene Egress-Ansicht.
• Vertrauen. Namespace verfügt über SOC 2 Type II, der Bericht ist im Trust Center verfügbar, und bietet in Enterprise-Plänen regionsexklusive Datenresidenz.

Namespace veröffentlicht Kundenergebnisse, etwa dass DuckDB sein CI „10x faster“ ausführt. Das sind die Zahlen von Namespace für diese Kunden.

Worin sich CRACI unterscheidet

CRACI betrachtet den Build als Quelle der Wahrheit für das, was Sie ausliefern.

Eine Aufzeichnung dessen, was der Build geladen hat

Während jeder Job läuft, zeichnet ein paketbewusster Proxy den Datenverkehr zu Paketquellen auf: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen, dazu Download-Presets. Die Abhängigkeitsnachweise reisen mit CI-Caches mit, sodass auch ein aus einem Cache wiederhergestelltes Paket gezählt wird. Die SBOM jedes Jobs, als CycloneDX oder SPDX, trägt einen Vollständigkeitsstatus pro Job und pro Cache. Die Egress-Logs von Namespace sagen Ihnen, welche Domains ein Runner kontaktiert hat. Die Aufzeichnung von CRACI sagt Ihnen, welche Pakete und Versionen der Build von dort geladen hat.

Egress-Richtlinie, fair verglichen

CRACI-Richtlinien sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen, typisierten eigenen Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git über HTTPS und SSH sowie expliziten Regeln für TLS, TCP, UDP und ICMP. Richtlinien werden vor dem Start des Jobs validiert, blockieren im Zweifel (fail closed), lehnen unbekannte Felder ab und senden bei einem Verstoß eine Warnung.

An zwei Stellen liegt Namespace vorn. Mit seinem Advisory-Modus können Sie eine Richtlinie beobachten, bevor Sie sie durchsetzen, und der Monitor-Modus von CRACI ist noch auf der Roadmap. Für seine Secret-Injection und Proxy-Regeln hat CRACI keine Entsprechung. CRACI unterscheidet sich darin, dass seine Quellen nach Paket-Ökosystem und Protokoll typisiert statt als Domains aufgelistet sind und derselbe Job, der unter der Richtlinie läuft, auch die Aufzeichnung der geladenen Pakete erzeugt.

Provenienz und Überwachung

• Provenienzdaten. Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht und beansprucht kein SLSA-Level.
• Überwachung des Ausgelieferten. Überwachte SBOMs werden laufend gegen neue Schwachstellen neu bewertet, und Befunde werden über Builds und Repositories hinweg zusammengeführt.

Preise und Größen

Namespace rechnet in Unit-Minuten ab, wobei eine Unit unter Linux 1 vCPU und 2 GB RAM für eine Minute entspricht. Stand September 2026 kostet ein Linux-Runner mit 2 vCPU und 4 GB $0.002 pro Minute innerhalb der Planminuten und $0.003 pro Minute darüber hinaus. Der Team-Plan kostet $100 pro Monat mit 100.000 Unit-Minuten, Business $250 pro Monat mit 250.000. Windows verbraucht Minuten zum doppelten Linux-Satz, macOS zum zehnfachen. Pro Job wird mindestens eine Minute berechnet, danach wird minutenweise gerundet; im Beispiel von Namespace werden 150 Sekunden als 3 Minuten berechnet.

CRACI berechnet $0.002 pro vCPU-Minute, ein Runner mit 2 vCPU und 6 GB RAM kostet also $0.004 pro Minute, ARM64 zum gleichen Preis, sekundengenau abgerechnet und ohne Monatsgebühr. Der Listenpreis pro Minute von Namespace ist niedriger, bei mindestens einer berechneten Minute pro Job. Seine Standardgrößen haben 2 GB RAM pro vCPU, die von CRACI 3 GB, wählen Sie also vor dem Vergleich die Größe, die Ihre Builds brauchen. Die aktuellen Konditionen finden Sie unter CRACI-Preise.

Was passt

Namespace passt besser, wenn

• Sie macOS- oder Windows-Runner brauchen. CRACI läuft heute nur unter Linux; Windows und macOS sind auf der Roadmap.
• Sie eine Egress-Richtlinie im Advisory-Modus testen wollen, bevor Sie sie durchsetzen.
• Sie auf Bazel Remote Execution oder Cache-Volumes angewiesen sind.
• Sie auch Buildkite-Agents oder Cloud-Entwicklungsumgebungen betreiben und alles von einem Anbieter möchten.

CRACI passt besser, wenn

• Sie aus dem Build selbst zeigen müssen, was in ein Release eingeflossen ist, mit Vollständigkeitsstatus.
• Sie die Überwachung ausgelieferter SBOMs an einem Ort wollen.
• Sie Nachweise für den Cyber Resilience Act brauchen.
• Sie EU-Datenresidenz brauchen, verfügbar im Enterprise-Plan von CRACI.

Für den Cyber Resilience Act

Der Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu kennen, deren Schwachstellen zu behandeln und Nachweise aufzubewahren. Das Produkt von Namespace ist schnelle CI- und Entwicklungsinfrastruktur. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen: Build-Time-SBOMs mit Export als CycloneDX oder SPDX, Schwachstellenverfolgung und Provenienz über die API. Siehe CRA-Nachweise.

Wechsel von Namespace zu CRACI

Installieren Sie die CRACI GitHub App in Ihrer Organisation, mit Zugriff auf alle Repositories oder eine Auswahl, und ändern Sie dann das Runner-Label eines Jobs:

runs-on: craci

Verlegen Sie einen Job nach dem anderen, prüfen Sie seine SBOM und seinen Netzwerk-Trace und lesen Sie mehr über CI/CD-Integration und SBOM-Generierung während des Builds.