CRACI to runner, na którym działają Państwa buildy

Jedna linia przenosi build

CRACI zastępuje runner, a nie GitHub Actions. Pliki workflow, akcje i sekrety zostają tam, gdzie są; zmienia się tylko miejsce, w którym działa zadanie:

jobs:
  build:
    runs-on: craci

Uruchomienia nadal widać w GitHub, więc pull requesty, checki i logi zostają tam, gdzie Państwa zespół i tak zagląda. Za to połączenie odpowiada GitHub App, którą instalują Państwo we wszystkich lub wybranych repozytoriach.

Czym są runnery

• Rozmiary od 1 do 32 jednostek obliczeniowych, każda to 1 vCPU i 3 GB RAM, domyślnie 2. Rozmiar ustawia się dla każdego zadania za pomocą cracicorp/setup@v1 i jego parametru size:.
• Natywne x86-64 i ARM64 według tej samej stawki.
• Obrazy: CRACI Slim, CRACI Slim ARM64 oraz zgodny z GitHub obraz Ubuntu 24.04 z Docker Engine, Buildx i Compose v2.
• Izolowane maszyny wirtualne dla każdego zadania. Wirtualizacja zagnieżdżona jest dostępna na x86-64, a na ARM64 w wersji preview.
• Cache: cache GitHub Actions oraz cache warstw kontenerów: lokalny, zdalny i oparty na bind mount.
• Infrastruktura pipeline'u: stała pula adresów IP ruchu wychodzącego i szablony runnerów na poziomie organizacji.
• Dziś Linux. Runnery Windows i macOS są w planach rozwoju.

Runnerami zarządza CRACI, a działają one na europejskiej infrastrukturze bare metal, z przechowywaniem danych w UE. Runnery hostowane przez klienta są w planach rozwoju dla planu Enterprise; o kompromisach piszemy w artykule runnery zarządzane a self-hosted.

Dlaczego bezpieczeństwo łańcucha dostaw należy do runnera

Build produkcyjny to nie build na laptopie. Zakresy wersji rozwiązują się inaczej, tagi się przesuwają, cache jest ciepły albo zimny, a środowisko nie jest takie samo. Jedynym wiarygodnym zapisem tego, co zostało wydane, jest zapis wykonany w trakcie buildu wydania. Dlatego CRACI umieścił rejestrator w runnerze, a nie obok niego. Pełną argumentację przedstawiamy w artykule dlaczego bezpieczeństwo łańcucha dostaw należy do CI.

Ponieważ runner należy do CRACI, CRACI może robić rzeczy, których skaner nie potrafi:

• Rejestrowanie zamiast skanowania. Proxy rozpoznające pakiety obserwuje, co zadanie faktycznie pobiera, łącznie z zależnościami przechodnimi i pakietami przywróconymi z cache CI. SBOM każdego zadania ma stan kompletności.
• Egzekwowanie polityki ruchu wychodzącego. Polityka jest egzekwowana na runnerze, weryfikowana przed startem zadania i w razie awarii blokuje ruch (fail closed).
• Zwracanie dowodów. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu dla każdego zadania.

Około dwa razy szybciej niż runnery hostowane przez GitHub

CRACI wykonuje buildy około dwa razy szybciej niż standardowe runnery hostowane przez GitHub, na tych samych workflow i bez ich zmieniania. Zadanie, które trwało dziesięć minut, trwa około pięciu.

Szybsze CI jest warte więcej niż zaoszczędzone minuty. Pull request, który przechodzi na zielono w pięć minut, recenzent wciąż ma przed oczami; przy dwudziestu minutach autor zdążył już przełączyć się na coś innego. Czas buildu to odstęp między napisaniem zmiany a sprawdzeniem, czy działa, a płaci go przy każdym pushu każdy inżynier w zespole.

Składają się na to trzy rzeczy: sprzęt, krótszy czas oczekiwania i cache.

Ile kosztuje przyspieszenie

Ponieważ CRACI nalicza opłaty co do sekundy i bierze mniej za minutę, dwukrotnie szybsze działanie sumuje się z niższą stawką, zamiast się z nią znosić. Dla buildu, który na runnerze hostowanym przez GitHub z 2 rdzeniami x64 trwa dziesięć minut (cennik GitHub według stanu na wrzesień 2026, CRACI na październik 2026):

Dziesięciominutowy build, 1000 razy w miesiącu	Hostowane przez GitHub	CRACI
Rzeczywisty czas jednego buildu	10 minut	Około 5 minut
Koszt jednego buildu	$0.060	$0.020
Koszt miesięczny	Około $60	Około $20

To około 67% mniej, czyli 3 razy taniej. Bez przyspieszenia oszczędnością jest sama różnica w cennikach, około 33% dla 2 rdzeni x64. O ile szybsze będą Państwa własne buildy, zależy od obciążenia, dlatego warto przenieść jeden workflow i to zmierzyć.

Rozliczanie co do sekundy

Minuty buildu są naliczane co do sekundy, z zaokrągleniem do najbliższej sekundy. GitHub zaokrągla każde zadanie w górę do pełnej minuty, więc macierz krótkich zadań jest rozliczana za czas, którego nigdy nie wykorzystała: 30-sekundowe zadanie kosztuje w CRACI około 67% mniej, a 70-sekundowe około 61% mniej. W przypadku długich zadań różnica zbliża się do różnicy w cennikach.

Minuty buildu kosztują $0.002 za vCPU-minutę, czyli $0.004 za minutę dla runnera w rozmiarze 2, według tej samej stawki na ARM64. CRACI nie jest najtańszym runnerem na rynku, a cena nie jest tu argumentem: argumentem jest to, co runner rejestruje w trakcie działania. Zob. cennik.

CRACI na tle innych runnerów GitHub Actions

Blacksmith, Depot, Namespace i WarpBuild działają tak samo jak CRACI: workflow zostają w GitHub Actions, zmienia się miejsce, w którym działa zadanie. Pod względem szybkości i ceny są do siebie zbliżone, a kilka z nich podaje niższą cenę za ARM niż CRACI. Różnica polega na tym, co runner rejestruje i kontroluje w trakcie działania zadania.

CRACI jest jednym z najbardziej przystępnych cenowo runnerów i to właśnie on tworzy SBOM tego, co zadanie faktycznie pobrało, egzekwuje politykę ruchu wychodzącego blokującą ruch w razie awarii (fail closed) i zwraca dane o pochodzeniu przez swoje API, jako produkt uboczny uruchomienia buildu, bez dodawania czegokolwiek do workflow. Pełne porównanie wiersz po wierszu: porównanie runnerów GitHub Actions.

Co dobrze działa na CRACI

Wszystko, co robi zadanie GitHub Actions: buildy aplikacji, obrazy kontenerów, zestawy testów. Dwa przypadki warte wyróżnienia to buildy Yocto i BitBake obrazów Embedded Linux, udokumentowane do runnerów w rozmiarze 32, oraz buildy Raspberry Pi OS w pi-gen.

W planach rozwoju

• Runnery Windows i macOS: w planach rozwoju.
• Runnery hostowane przez klienta: w planach rozwoju, dla planu Enterprise.
• Inne systemy CI: dziś GitHub Actions, pozostałe w planach rozwoju, na razie bez daty.