CRACI ist der Runner, auf dem Ihre Builds laufen

Eine Zeile verlegt den Build

CRACI ersetzt den Runner, nicht GitHub Actions. Ihre Workflow-Dateien, Actions und Secrets bleiben, wo sie sind; es ändert sich nur, wo der Job ausgeführt wird:

jobs:
  build:
    runs-on: craci

Die Läufe erscheinen weiterhin in GitHub, sodass Pull Requests, Checks und Logs dort bleiben, wo Ihr Team ohnehin nachsieht. Dafür sorgt die GitHub App, die Sie auf allen oder ausgewählten Repositories installieren.

Was die Runner bieten

• Größen von 1 bis 32 Compute-Einheiten, jede mit 1 vCPU und 3 GB RAM, Standard ist 2. Die Größe legen Sie pro Job mit cracicorp/setup@v1 und dessen Eingabe size: fest.
• Natives x86-64 und ARM64 zum selben Preis.
• Images: CRACI Slim, CRACI Slim ARM64 und ein GitHub-kompatibles Ubuntu-24.04-Image, mit Docker Engine, Buildx und Compose v2.
• Isolierte virtuelle Maschinen pro Job. Verschachtelte Virtualisierung ist auf x86-64 verfügbar und auf ARM64 als Preview.
• Caching: der GitHub-Actions-Cache sowie Container-Layer-Caching: lokale, entfernte und Bind-Mount-Layer-Caches.
• Pipeline-Infrastruktur: ein fester Egress-IP-Bereich und Runner-Vorlagen auf Organisationsebene.
• Heute Linux. Windows- und macOS-Runner sind auf der Roadmap.

Die Runner werden von CRACI verwaltet und laufen auf europäischer Bare-Metal-Infrastruktur, mit Datenresidenz in der EU. Vom Kunden gehostete Runner sind für Enterprise auf der Roadmap; die Abwägung finden Sie unter verwaltete und selbst gehostete Runner.

Warum Lieferkettensicherheit in den Runner gehört

Der Produktions-Build ist nicht der Build auf dem Laptop. Versionsbereiche werden anders aufgelöst, Tags verschieben sich, Caches sind warm oder kalt, und die Umgebung ist eine andere. Die einzige verlässliche Aufzeichnung dessen, was ausgeliefert wurde, entsteht während des Release-Builds. Deshalb hat CRACI den Rekorder in den Runner gesetzt statt daneben. Die ganze Argumentation lesen Sie unter warum Lieferkettensicherheit ins CI gehört.

Weil CRACI der Runner gehört, kann es Dinge tun, die ein Scanner nicht kann:

• Aufzeichnen statt scannen. Ein paketbewusster Proxy beobachtet, was der Job tatsächlich herunterlädt, einschließlich transitiver Abhängigkeiten und Paketen aus CI-Caches. Die SBOM jedes Jobs trägt einen Vollständigkeitsstatus.
• Egress-Richtlinien durchsetzen. Die Richtlinie wird am Runner durchgesetzt, vor dem Start des Jobs geprüft und blockiert im Zweifel (fail closed).
• Die Nachweise liefern. Die API liefert SBOMs, Netzwerk-Traces und Provenienzdaten für jeden Job.

Etwa doppelt so schnell wie GitHub-gehostete Runner

CRACI führt Builds etwa doppelt so schnell aus wie die Standard-Runner von GitHub, mit denselben Workflows und ohne sie zu ändern. Der Job, der zehn Minuten dauerte, dauert etwa fünf.

Schnelleres CI ist mehr wert als die eingesparten Minuten. Ein Pull Request, der nach fünf Minuten grün ist, wird noch begutachtet; bei einem, der zwanzig Minuten braucht, hat sich die Autorin oder der Autor längst einer anderen Aufgabe zugewandt. Die Build-Zeit ist der Abstand zwischen dem Schreiben einer Änderung und dem Wissen, ob sie funktioniert, und sie fällt bei jedem Push für jede Person im Team an.

Drei Dinge machen den Unterschied: die Hardware, kürzere Wartezeiten und Caching.

Was die Beschleunigung kostet

Weil CRACI pro Sekunde abrechnet und pro Minute weniger verlangt, verstärkt sich der Effekt der doppelten Geschwindigkeit, statt sich aufzuheben. Bei einem Build, der auf einem GitHub-gehosteten 2-Core-x64-Runner zehn Minuten dauert (GitHub-Listenpreise Stand September 2026, CRACI Stand Oktober 2026):

Zehnminütiger Build, 1.000-mal im Monat	GitHub-gehostet	CRACI
Laufzeit pro Build	10 Minuten	Etwa 5 Minuten
Kosten pro Build	$0.060	$0.020
Kosten pro Monat	Etwa $60	Etwa $20

Das sind etwa 67% weniger, also ein Drittel der Kosten. Ohne die Beschleunigung bleibt nur der Unterschied der Listenpreise, etwa 33% bei 2-Core-x64. Wie viel schneller Ihre eigenen Builds werden, hängt von der Arbeitslast ab. Verlegen Sie also einen Workflow und messen Sie nach.

Abrechnung pro Sekunde

Build-Minuten werden pro Sekunde abgerechnet, auf die nächste Sekunde gerundet. GitHub rundet jeden Job auf eine volle Minute auf, sodass eine Matrix kurzer Jobs Zeit berechnet bekommt, die sie nie genutzt hat: Ein 30-Sekunden-Job kostet auf CRACI etwa 67% weniger, ein 70-Sekunden-Job etwa 61% weniger. Bei langen Jobs nähert sich der Unterschied dem der Listenpreise an.

Build-Minuten kosten $0.002 pro vCPU-Minute, also $0.004 pro Minute für einen Runner der Größe 2, zum selben Preis auf ARM64. CRACI ist nicht der günstigste Runner auf dem Markt, und der Preis ist nicht das Argument: Das Argument ist, was der Runner während der Ausführung aufzeichnet. Siehe Preise.

CRACI im Vergleich mit anderen GitHub-Actions-Runnern

Blacksmith, Depot, Namespace und WarpBuild funktionieren alle wie CRACI: Ihre Workflows bleiben in GitHub Actions, nur der Ort der Ausführung ändert sich. Bei Geschwindigkeit und Preis liegen sie nah beieinander, und mehrere nennen einen niedrigeren ARM-Preis als CRACI. Der Unterschied liegt darin, was der Runner während des Jobs aufzeichnet und kontrolliert.

CRACI ist einer der günstigsten Runner, und es ist derjenige, der eine SBOM dessen erzeugt, was der Job tatsächlich geladen hat, eine Egress-Richtlinie durchsetzt, die im Zweifel blockiert (fail closed), und Provenienzdaten über seine API liefert: als Nebenprodukt der Build-Ausführung, ohne Ergänzungen am Workflow. Den vollständigen Vergleich Zeile für Zeile finden Sie unter GitHub-Actions-Runner im Vergleich.

Was auf CRACI gut läuft

Alles, was ein GitHub-Actions-Job tut: Anwendungs-Builds, Container-Images, Testsuiten. Zwei Fälle verdienen besondere Erwähnung: Yocto- und BitBake-Builds von Embedded-Linux-Images, dokumentiert bis zu Runnern der Größe 32, und pi-gen-Builds von Raspberry Pi OS.

Auf der Roadmap

• Windows- und macOS-Runner: auf der Roadmap.
• Vom Kunden gehostete Runner: auf der Roadmap, für Enterprise.
• Weitere CI-Systeme: heute GitHub Actions, weitere auf der Roadmap, noch ohne Termin.