CRACI vs RunsOn

Krótka odpowiedź

RunsOn to self-hosted runnery GitHub Actions bez utrzymywania floty runnerów. Jeden stos CloudFormation lub moduł Terraform wdraża go na Państwa koncie AWS; każde zadanie otrzymuje następnie nową instancję EC2 dowolnego wybranego typu, a AWS rozlicza moc obliczeniową po kosztach. Jeśli chcą Państwo mieć runnery na własnym koncie w chmurze i najniższy możliwy rachunek za moc obliczeniową, zwłaszcza na instancjach spot, trudno pobić RunsOn.

CRACI to CI, które natywnie obsługuje bezpieczeństwo łańcucha dostaw. To zarządzany runner zgodny z GitHub Actions, a bezpieczeństwo jest częścią runnera, a nie dodanym do niego narzędziem: CRACI rejestruje każdą zewnętrzną zależność pobraną przez build, egzekwuje politykę ruchu wychodzącego w sieci buildu i zamienia ten zapis w SBOM-y, monitorowanie podatności i dowody. Oba produkty zastępują runner, na którym działają zadania, więc wybiera się jeden z nich.

W skrócie

Co RunsOn robi dobrze

Państwa konto, Państwa dane. Płaszczyzna sterowania, maszyny wirtualne runnerów, cache S3 i logi znajdują się na Państwa koncie AWS, a własne przepływy danych RunsOn ograniczają się do walidacji licencji, telemetrii i wsparcia. Dla zespołów, których przegląd bezpieczeństwa zatrzymuje się na tym, że strona trzecia obsługuje ich kod i sekrety, to właśnie odpowiedź, którą RunsOn ma dawać. Runnery CRACI są dziś zarządzane; runnery hostowane u klienta są w planach rozwoju CRACI dla Enterprise.

Dowolna instancja, jedna na zadanie. Etykieta runs-on wybiera maszynę, więc zadanie może zażądać dużej instancji zoptymalizowanej pod obliczenia, GPU, lokalnego dysku NVMe lub Windows. Każde zadanie otrzymuje nową instancję EC2, niszczoną po jego zakończeniu, a RunsOn podaje, że zadania zwykle startują w około 30 sekund, a z rozgrzanymi pulami w mniej niż 6.

Koszt. RunsOn nie dodaje marży do mocy obliczeniowej AWS i pobiera stałą opłatę licencyjną, od około $348 (€300) rocznie. Podaje, że dzięki temu wychodzi od 7 do 12 razy taniej niż na runnerach hostowanych przez GitHub. Instancje spot z automatycznym przejściem na on-demand dodatkowo obniżają rachunek. To dane RunsOn; rzeczywistą liczbę wyznaczają Państwa zestaw instancji i region.

Cache i obserwowalność. Cache oparty na S3 w Państwa VPC zastępuje cache GitHub bez jego limitu rozmiaru, cache warstw Docker jest wbudowany, a dyski EBS sticky i współdzielone wolumeny EFS zachowują stan między zadaniami. Metryki i raporty kosztów dla każdego zadania trafiają do CloudWatch i OpenTelemetry.

Dodatki bezpieczeństwa. Integracja ze StepSecurity Harden-Runner dodaje monitorowanie i filtrowanie ruchu wychodzącego oraz wykrywanie manipulacji kodem źródłowym podczas buildu, przy licencji enterprise StepSecurity.

Cena i rozmiary

Pod względem samej mocy obliczeniowej RunsOn na instancjach spot kosztuje ułamek stawki CRACI wynoszącej $0.004 za minutę 2 vCPU. Porównanie nie dotyczy jednak tylko minut. Przy RunsOn płacą Państwo także licencję i usługi AWS wokół runnerów, takie jak bramy NAT dla statycznych adresów IP, a Państwa zespół odpowiada za stos: aktualizacje, limity AWS i incydenty. CRACI to jedna cena za minutę, naliczana co sekundę, bez opłaty miesięcznej, a infrastrukturę prowadzi CRACI. Aktualne warunki podaje strona cennika CRACI, a szerzej o kompromisach piszemy na stronie runnery zarządzane a self-hosted.

Pod względem szybkości CRACI uruchamia buildy około dwa razy szybciej niż runnery hostowane przez GitHub dzięki szybszemu sprzętowi, krótszym kolejkom i cache. Szybkość RunsOn zależy od wybranego typu instancji. Nie porównywaliśmy obu rozwiązań w benchmarku.

Czym różni się CRACI

Zapis tego, co pobrał build

W trakcie każdego zadania proxy rozpoznające pakiety rejestruje ruch do źródeł pakietów: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także presety pobierania. Dowody zależności przemieszczają się razem z cache CI, więc pakiety przywrócone z cache nadal są uwzględniane. Obejmuje to ukryte zależności, których nie wymienia żaden lockfile, takie jak kod pobierany przez hooki instalacyjne lub skrypty buildu, oraz warstwy obrazów bazowych. Każde zadanie tworzy SBOM CycloneDX lub SPDX ze stanem kompletności dla każdego zadania i każdego cache.

Kontrola nad tym, do czego build może dotrzeć

Grupy zabezpieczeń decydują, do których sieci runner RunsOn może dotrzeć; nie wiedzą, którego rejestru pakietów ma używać zadanie. Polityka ruchu wychodzącego CRACI to wie: domyślna odmowa lub domyślne zezwolenie, 24 wbudowane presety źródeł oprogramowania, typowane źródła niestandardowe dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git przez HTTPS i SSH oraz jawne reguły TLS, TCP, UDP i ICMP. Polityki są walidowane przed uruchomieniem zadania, w razie awarii blokują ruch, a przy naruszeniu wysyłają alert. Ponieważ polityka zezwala tylko na to, czego build potrzebuje, blokuje wyprowadzanie danych na hosty, których build nie potrzebuje, nawet przy ataku, którego nikt wcześniej nie widział.

Harden-Runner na RunsOn idzie dalej w jednym miejscu: obserwuje także modyfikowanie plików źródłowych podczas buildu, czego CRACI nie robi.

Pochodzenie i monitorowanie

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu i nie deklaruje żadnego poziomu SLSA. Agreguje podatności z wielu buildów i repozytoriów oraz stale ponownie ocenia monitorowane SBOM-y.

Dwa różne pytania o bezpieczeństwo

RunsOn odpowiada na pytanie, kto przechowuje Państwa kod, sekrety i stan runnera, zatrzymując to wszystko na Państwa koncie AWS. CRACI odpowiada na inne pytanie: co ten build pobrał i z czym się łączył. CRACI uruchamia każde zadanie we własnej izolowanej maszynie wirtualnej, nie przechowuje Państwa kodu źródłowego i ma certyfikat ISO 27001. O tę drugą odpowiedź prosi audytor, klient lub Cyber Resilience Act.

Proszę umówić demo, aby zobaczyć SBOM, ślad sieciowy i dane o pochodzeniu z jednego z Państwa workflow.

Które rozwiązanie pasuje

RunsOn sprawdzi się lepiej, gdy

• Runnery muszą działać na Państwa własnym koncie AWS, obok zasobów VPC.
• Najważniejszy jest najniższy koszt mocy obliczeniowej, a prowadzenie stosu w AWS nie stanowi problemu.
• Potrzebują Państwo już dziś runnerów Windows, instancji GPU lub konkretnych typów instancji EC2.
• Państwa projekty są niekomercyjne, co RunsOn obejmuje bezpłatnie.

CRACI sprawdzi się lepiej, gdy

• Dostarczają Państwo oprogramowanie, przy którym trzeba wykazać, co trafiło do każdego wydania, na podstawie samego buildu.
• Chcą Państwo ograniczyć, do czego buildy mogą dotrzeć, za pomocą polityki blokującej w razie awarii i bez dodatkowej licencji.
• Potrzebują Państwo monitorowania tego, co dostarczono, bez dodawania narzędzi do każdego workflow.
• Wolą Państwo nie prowadzić infrastruktury CI i chcą budować na europejskiej infrastrukturze.

Z czego rezygnują Państwo przy CRACI. Z runnerów na własnym koncie AWS, które są w planach rozwoju dla Enterprise, z runnerów Windows, które także są w planach rozwoju, oraz z najniższego rachunku za moc obliczeniową. W zamian otrzymują Państwo zapis buildu, z którego zespoły bezpieczeństwa i zgodności mogą korzystać bez kolejnego skanera w pipeline, na infrastrukturze, której nie muszą Państwo prowadzić.

Na potrzeby Cyber Resilience Act

Unijny Cyber Resilience Act oczekuje, że producenci będą wiedzieć, co zawiera każde wydanie, i obsługiwać jego podatności, z obowiązkami zgłaszania od września 2026 i pełnym stosowaniem od grudnia 2027. Self-hosted runner sam nie wytwarza tych dowodów; trzeba by dodać do workflow narzędzia SBOM i skanery. CRACI wytwarza je z zapisu buildu i eksportuje SBOM-y w formacie CycloneDX lub SPDX. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA.

Przejście z RunsOn

CRACI zastępuje runner, a nie GitHub Actions. Workflow i interfejs GitHub pozostają bez zmian, a etykieta zadania przyjmuje postać runs-on: craci. Zadania otrzymują Docker Engine, Buildx i Compose v2, zgodny z GitHub obraz Ubuntu 24.04 oraz zagnieżdżoną wirtualizację na x86-64. Więcej o integracji CI/CD i generowaniu SBOM w czasie buildu. Startupy mogą ubiegać się o udział w programie dla startupów.

RunsOn vs CRACI: najczęściej zadawane pytania

Ceny, hosting, platformy i bezpieczeństwo, na podstawie opublikowanych informacji dostawców

Czym jest RunsOn?

RunsOn to self-hosted runnery GitHub Actions w formie produktu. Wdrażają Państwo jeden stos CloudFormation lub moduł Terraform na własnym koncie AWS, a RunsOn uruchamia nową instancję EC2 dla każdego zadania i kończy ją po zakończeniu zadania. Runnery, cache, logi i poświadczenia pozostają na Państwa koncie AWS. Założył go w 2023 roku Cyril Rohr z Rennes we Francji.

Ile kosztuje RunsOn?

Według stanu na wrzesień 2026 RunsOn pobiera stałą roczną opłatę licencyjną za podmiot prawny: od około $348 (€300) rocznie w planie Starter, około $1,044 (€900) w Growth, około $2,088 (€1,800) w Scale i około $4,176 (€3,600) w Enterprise, w zależności od liczby runnerów uruchamianych miesięcznie. AWS rozlicza moc obliczeniową bezpośrednio, co sekundę, bez marży RunsOn. RunsOn podaje dla instancji spot x64 z 2 vCPU w us-east-1 około $0.0009 za minutę. Jest bezpłatny do użytku niekomercyjnego i ma 15-dniowy okres próbny.

Czy RunsOn jest tańszy niż CRACI?

Pod względem mocy obliczeniowej tak, a na instancjach spot z dużą różnicą. CRACI pobiera $0.004 za minutę 2 vCPU, a instancja spot z 2 vCPU przez RunsOn kosztuje około $0.0009 za minutę w us-east-1, plus licencja. Do sumy dochodzą też sieć i pamięć masowa AWS oraz czas na utrzymanie stosu. CRACI dodaje na runnerze zapis buildu: SBOM dla każdego zadania, politykę ruchu wychodzącego, dane o pochodzeniu i monitorowanie podatności.

Czy RunsOn generuje SBOM-y lub dane o pochodzeniu buildu?

Nie ma tego wśród jego udokumentowanych funkcji. RunsOn koncentruje się na mocy obliczeniowej, cache, kosztach i obserwowalności na Państwa koncie AWS. CRACI rejestruje pakiety pobierane przez każde zadanie, łącznie z pakietami przywróconymi z cache, i tworzy SBOM CycloneDX lub SPDX ze stanem kompletności. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Czy RunsOn może ograniczyć, do czego build dociera w sieci?

Runnery RunsOn znajdują się w Państwa VPC, więc obowiązują grupy zabezpieczeń i routing AWS, a statyczne adresy IP ruchu wychodzącego pochodzą z bram NAT. Do filtrowania ruchu wychodzącego wewnątrz zadania RunsOn integruje StepSecurity Harden-Runner, który tworzy punkt odniesienia ruchu wychodzącego każdego zadania i może egzekwować go jako listę dozwolonych; na RunsOn wymaga licencji enterprise StepSecurity. CRACI egzekwuje politykę ruchu wychodzącego na samym runnerze: domyślna odmowa lub zezwolenie, 24 wbudowane presety źródeł oprogramowania, walidacja przed uruchomieniem zadania i blokowanie w razie awarii.

Czy mogę uruchamiać CRACI na własnym koncie AWS?

Dziś nie. Runnery CRACI są zarządzane, na europejskiej infrastrukturze, a runnery hostowane u klienta są w planach rozwoju dla planu Enterprise. Jeśli runnery na własnym koncie AWS są bezwzględnym wymogiem, RunsOn powstał właśnie do tego.

Czy CRACI obsługuje runnery Windows lub macOS?

CRACI obsługuje dziś Linuksa na x86-64 i ARM64, a Windows i macOS są w planach rozwoju. RunsOn oferuje Windows Server 2022 i 2025 oraz instancje GPU; zadania macOS także przy RunsOn pozostają na runnerach hostowanych przez GitHub.

Czy przy zmianie muszę przepisywać workflow GitHub Actions?

Nie. Oba produkty zastępują runner, a nie GitHub Actions. Workflow, wyzwalacze i interfejs GitHub pozostają bez zmian; na CRACI etykieta zadania przyjmuje postać runs-on: craci.