CRACI vs. RunsOn

Die kurze Antwort

RunsOn bietet selbst gehostete GitHub-Actions-Runner ohne den Pflegeaufwand einer Runner-Flotte. Ein CloudFormation-Stack oder Terraform-Modul stellt es in Ihrem AWS-Konto bereit; danach erhält jeder Job eine neue EC2-Instanz eines beliebigen Typs Ihrer Wahl, und AWS rechnet die Rechenleistung zum Selbstkostenpreis ab. Wenn Sie Runner in Ihrem eigenen Cloud-Konto und die niedrigstmögliche Compute-Rechnung möchten, vor allem auf Spot-Instanzen, ist RunsOn kaum zu schlagen.

CRACI ist CI, das Lieferkettensicherheit nativ abdeckt. Es ist ein verwalteter, GitHub-Actions-kompatibler Runner, und die Sicherheit ist Teil des Runners statt ein zusätzliches Tool: CRACI zeichnet jede externe Abhängigkeit auf, die der Build geladen hat, setzt eine Egress-Richtlinie im Build-Netzwerk durch und macht aus dieser Aufzeichnung SBOMs, Schwachstellenüberwachung und Nachweise. Beide Produkte ersetzen den Runner, auf dem Ihre Jobs laufen, Sie wählen also eines.

Auf einen Blick

Was RunsOn gut kann

Ihr Konto, Ihre Daten. Control Plane, Runner-VMs, S3-Cache und Logs liegen alle in Ihrem AWS-Konto, und die eigenen Datenflüsse von RunsOn beschränken sich auf Lizenzprüfung, Telemetrie und Support. Für Teams, deren Sicherheitsprüfung bei „Ein Dritter führt unseren Code und unsere Secrets aus“ endet, ist das genau die Antwort, für die RunsOn gebaut ist. CRACI-Runner sind heute verwaltet; kundenseitig gehostete Runner stehen für Enterprise auf der Roadmap.

Jede Instanz, eine pro Job. Das Label runs-on wählt die Maschine aus, ein Job kann also eine große rechenoptimierte Instanz, eine GPU, lokalen NVMe-Speicher oder Windows anfordern. Jeder Job erhält eine neue EC2-Instanz, die nach seinem Ende zerstört wird, und laut RunsOn starten Jobs typischerweise in etwa 30 Sekunden, mit Warm Pools in unter 6.

Kosten. RunsOn schlägt nichts auf die AWS-Rechenleistung auf und berechnet eine pauschale Lizenz ab etwa $348 (€300) pro Jahr. Das Ergebnis sei laut RunsOn 7- bis 12-mal günstiger als GitHub-gehostete Runner. Spot-Instanzen mit automatischem Rückfall auf On-Demand senken die Rechnung weiter. Das sind Zahlen von RunsOn; Ihr Instanz-Mix und Ihre Region bestimmen den tatsächlichen Wert.

Caching und Observability. Ein S3-gestützter Cache in Ihrer VPC ersetzt den Cache von GitHub ohne dessen Größenlimit, Docker-Layer-Caching ist integriert, und EBS-Sticky-Disks und gemeinsame EFS-Volumes bewahren den Zustand über Jobs hinweg. Metriken und Kostenberichte pro Job gehen an CloudWatch und OpenTelemetry.

Sicherheits-Add-ons. Eine Integration mit StepSecurity Harden-Runner ergänzt Egress-Überwachung und -Filterung sowie die Erkennung von Quellcode-Manipulation während des Builds, mit einer StepSecurity-Enterprise-Lizenz.

Preis und Größen

Allein bei der Rechenleistung kostet RunsOn auf Spot-Instanzen nur einen Bruchteil der $0.004 pro 2-vCPU-Minute von CRACI. Der Vergleich läuft jedoch nicht nur über den Minutenpreis. Mit RunsOn zahlen Sie zusätzlich die Lizenz und die AWS-Dienste rund um die Runner, etwa NAT-Gateways für statische IPs, und Ihr Team verantwortet den Stack: Upgrades, AWS-Kontingente und Störungen. CRACI hat einen einzigen Minutenpreis, sekundengenau abgerechnet, ohne Monatsgebühr, und CRACI betreibt die Infrastruktur. Aktuelle Konditionen finden Sie unter CRACI-Preise, die umfassendere Abwägung unter verwaltete vs. selbst gehostete Runner.

Bei der Geschwindigkeit führt CRACI Builds etwa doppelt so schnell aus wie GitHub-gehostete Runner, dank schnellerer Hardware, kürzerer Wartezeiten und Caching. Die Geschwindigkeit von RunsOn hängt vom gewählten Instanztyp ab. Einen direkten Benchmark beider Produkte haben wir nicht durchgeführt.

Worin sich CRACI unterscheidet

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, sodass aus einem Cache wiederhergestellte Pakete weiterhin mitgezählt werden. Das umfasst die versteckten Abhängigkeiten, die in keinem Lockfile stehen, etwa von Install-Hooks oder Build-Skripten heruntergeladenen Code und Basis-Image-Layer. Jeder Job erzeugt eine CycloneDX- oder SPDX-SBOM mit einem Vollständigkeitsstatus pro Job und pro Cache.

Kontrolle darüber, was der Build erreichen kann

Security Groups entscheiden, welche Netzwerke ein RunsOn-Runner erreichen kann; sie wissen nicht, welche Paket-Registry ein Job verwenden soll. Die Egress-Richtlinie von CRACI weiß es: standardmäßig sperrend oder erlaubend, 24 integrierte Presets für Softwarequellen, typisierte eigene Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git über HTTPS und SSH sowie explizite TLS-, TCP-, UDP- und ICMP-Regeln. Richtlinien werden vor dem Start des Jobs validiert, blockieren im Zweifel (fail closed) und senden bei einem Verstoß eine Warnung. Weil die Richtlinie nur erlaubt, was der Build braucht, blockiert sie die Exfiltration zu Hosts, die der Build nicht braucht, selbst bei einem Angriff, den noch niemand gesehen hat.

Harden-Runner auf RunsOn geht an einer Stelle weiter: Es überwacht auch, ob Quelldateien während des Builds verändert werden, was CRACI nicht tut.

Provenienz und Überwachung

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht und beansprucht kein SLSA-Level. Es führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu.

Zwei verschiedene Sicherheitsfragen

RunsOn beantwortet „Wer verwahrt meinen Code, meine Secrets und meinen Runner-Zustand?“, indem alles in Ihrem AWS-Konto bleibt. CRACI beantwortet eine andere Frage: „Was hat dieser Build geladen, und wohin hat er sich verbunden?“ CRACI führt jeden Job in einer eigenen isolierten VM aus, speichert Ihren Quellcode nicht und ist ISO-27001-zertifiziert. Die zweite Antwort ist die, nach der ein Auditor, ein Kunde oder der Cyber Resilience Act fragt.

Buchen Sie eine Demo, um SBOM, Netzwerk-Trace und Provenienz aus einem Ihrer eigenen Workflows zu sehen.

Was passt

RunsOn passt besser, wenn

• Runner in Ihrem eigenen AWS-Konto laufen müssen, direkt neben Ihren VPC-Ressourcen.
• Die niedrigsten Compute-Kosten am wichtigsten sind und Sie sich den Betrieb eines Stacks in AWS zutrauen.
• Sie heute Windows-Runner, GPU-Instanzen oder bestimmte EC2-Instanztypen brauchen.
• Ihre Projekte nichtkommerziell sind, was RunsOn kostenlos abdeckt.

CRACI passt besser, wenn

• Sie Software ausliefern, bei der Sie aus dem Build selbst zeigen müssen, was in jedes Release eingeflossen ist.
• Sie einschränken wollen, was Builds erreichen können, mit einer Richtlinie, die im Zweifel blockiert (fail closed) und keine Zusatzlizenz braucht.
• Sie die Überwachung des Ausgelieferten brauchen, ohne jedem Workflow Tools hinzuzufügen.
• Sie lieber keine CI-Infrastruktur betreiben und Builds auf europäischer Infrastruktur möchten.

Worauf Sie mit CRACI verzichten. Runner in Ihrem eigenen AWS-Konto, die für Enterprise auf der Roadmap sind, Windows-Runner, die ebenfalls auf der Roadmap sind, und die niedrigste Compute-Rechnung. Dafür erhalten Sie eine Build-Aufzeichnung, die Sicherheit und Compliance ohne weiteren Scanner in der Pipeline nutzen können, auf Infrastruktur, die Sie nicht selbst betreiben müssen.

Für den Cyber Resilience Act

Der EU Cyber Resilience Act erwartet von Herstellern, dass sie wissen, was in jedem Release steckt, und dessen Schwachstellen behandeln, mit Meldepflichten ab September 2026 und voller Anwendung ab Dezember 2027. Ein selbst gehosteter Runner erzeugt diese Nachweise nicht von selbst; Sie müssten Ihren Workflows SBOM- und Scan-Tools hinzufügen. CRACI erzeugt sie aus der Build-Aufzeichnung und exportiert SBOMs als CycloneDX oder SPDX. Es automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen.

Wechsel von RunsOn

CRACI ersetzt den Runner, nicht GitHub Actions. Workflows und die GitHub-Oberfläche bleiben gleich, und das Job-Label wird zu runs-on: craci. Jobs erhalten Docker Engine, Buildx und Compose v2, ein GitHub-kompatibles Ubuntu-24.04-Image und verschachtelte Virtualisierung auf x86-64. Lesen Sie mehr über CI/CD-Integration und SBOM-Generierung während des Builds. Startups können sich für das Startup-Programm bewerben.

RunsOn vs. CRACI: häufige Fragen

Preise, Hosting, Plattformen und Sicherheit, beantwortet anhand der veröffentlichten Angaben jedes Anbieters

Was ist RunsOn?

RunsOn bietet selbst gehostete GitHub-Actions-Runner als Produkt. Sie stellen einen CloudFormation-Stack oder ein Terraform-Modul in Ihrem eigenen AWS-Konto bereit, und RunsOn startet für jeden Job eine neue EC2-Instanz und beendet sie, wenn der Job fertig ist. Runner, Caches, Logs und Zugangsdaten bleiben in Ihrem AWS-Konto. Gegründet wurde es 2023 von Cyril Rohr, der in Rennes, Frankreich, ansässig ist.

Was kostet RunsOn?

Stand September 2026 berechnet RunsOn eine pauschale Jahreslizenz pro Rechtseinheit: ab etwa $348 (€300) pro Jahr bei Starter, etwa $1,044 (€900) bei Growth, etwa $2,088 (€1,800) bei Scale und etwa $4,176 (€3,600) bei Enterprise, je nachdem, wie viele Runner Sie pro Monat starten. AWS rechnet die Rechenleistung direkt ab, pro Sekunde, ohne RunsOn-Aufschlag. RunsOn gibt für eine x64-Spot-Instanz mit 2 vCPU in us-east-1 etwa $0.0009 pro Minute an. Für nichtkommerzielle Nutzung ist es kostenlos, und es gibt eine 15-tägige Testphase.

Ist RunsOn günstiger als CRACI?

Bei der Rechenleistung ja, und auf Spot-Instanzen mit großem Abstand. CRACI berechnet $0.004 pro 2-vCPU-Minute, während eine Spot-Instanz mit 2 vCPU über RunsOn in us-east-1 etwa $0.0009 pro Minute kostet, zuzüglich der Lizenz. Zur Gesamtsumme gehören außerdem Ihr AWS-Netzwerk und -Speicher sowie die Zeit für den Betrieb des Stacks. Was CRACI auf dem Runner ergänzt, ist die Build-Aufzeichnung: eine SBOM für jeden Job, eine Egress-Richtlinie, Provenienzdaten und Schwachstellenüberwachung.

Erzeugt RunsOn SBOMs oder Build-Provenienz?

Das gehört nicht zu seinen dokumentierten Funktionen. RunsOn konzentriert sich auf Compute, Caching, Kosten und Observability in Ihrem AWS-Konto. CRACI zeichnet die Pakete auf, die jeder Job lädt, einschließlich aus Caches wiederhergestellter Pakete, und erzeugt eine CycloneDX- oder SPDX-SBOM mit Vollständigkeitsstatus. Die API liefert SBOMs, Netzwerk-Traces und Provenienz.

Kann RunsOn einschränken, was ein Build im Netzwerk erreichen kann?

RunsOn-Runner liegen in Ihrer VPC, es gelten also AWS Security Groups und Routing, und statische Egress-IPs stammen von NAT-Gateways. Für Egress-Filterung innerhalb des Jobs integriert RunsOn StepSecurity Harden-Runner, das eine Baseline des ausgehenden Datenverkehrs jedes Jobs erstellt und sie als Allowlist durchsetzen kann; auf RunsOn erfordert das eine StepSecurity-Enterprise-Lizenz. CRACI setzt eine Egress-Richtlinie am Runner selbst durch: standardmäßig sperrend oder erlaubend, 24 integrierte Presets für Softwarequellen, vor dem Start des Jobs validiert und im Zweifel blockierend (fail closed).

Kann ich CRACI in meinem eigenen AWS-Konto betreiben?

Heute nicht. CRACI-Runner sind verwaltet und laufen auf europäischer Infrastruktur; kundenseitig gehostete Runner sind für den Enterprise-Plan auf der Roadmap. Wenn Runner in Ihrem eigenen AWS-Konto eine feste Anforderung sind, ist RunsOn genau dafür gebaut.

Unterstützt CRACI Windows- oder macOS-Runner?

CRACI bietet heute Linux auf x86-64 und ARM64; Windows und macOS sind auf der Roadmap. RunsOn bietet Windows Server 2022 und 2025 sowie GPU-Instanzen; macOS-Jobs bleiben auch mit RunsOn auf GitHub-gehosteten Runnern.

Muss ich für den Wechsel meine GitHub-Actions-Workflows umschreiben?

Nein. Beide Produkte ersetzen den Runner, nicht GitHub Actions. Workflows, Trigger und die GitHub-Oberfläche bleiben gleich; auf CRACI wird das Job-Label zu runs-on: craci.