Runnery self-hosted GitHub Actions a zarządzane runnery CRACI

Czym jest runner self-hosted w GitHub Actions?

Runner self-hosted to maszyna, którą Państwo wdrażają i którą zarządzają, uruchamiająca zadania GitHub Actions zamiast maszyny wirtualnej hostowanej przez GitHub. Może to być serwer fizyczny, maszyna wirtualna lub kontener, w siedzibie firmy lub na koncie w chmurze, a GitHub podaje, że odpowiadają Państwo za maszynę i całe jej oprogramowanie.

• Rejestracja: runner rejestruje się w jednym repozytorium, organizacji lub przedsiębiorstwie naraz. Aby współdzielić runnery między repozytoriami, należy zarejestrować je na poziomie organizacji i użyć grup runnerów.
• Platformy: aplikacja runnera obsługuje popularne dystrybucje Linuksa, Windows 10, 11 i Windows Server oraz macOS 11 i nowsze, na x64 i ARM64.
• Sieć: runner łączy się z GitHub przez wychodzące HTTPS na porcie 443.
• Aktualizacje: aplikację runnera trzeba zaktualizować w ciągu 30 dni od nowego wydania. Aktualizuje się sama, chyba że Państwo to wyłączą.
• Limity: zadanie może działać do 5 dni, wobec 6 godzin na runnerach hostowanych przez GitHub, a zadanie pozostające w kolejce dłużej niż 24 godziny kończy się niepowodzeniem.
• Skalowanie: Actions Runner Controller (ARC), operator Kubernetes, skaluje zestawy runnerów wraz z liczbą działających workflow. Runnery zarejestrowane z --ephemeral przyjmują jedno zadanie.

Dlaczego zespoły wybierają self-hosting

Zespoły wybierają self-hosting, aby obniżyć koszty za minutę, uzyskać dostęp do systemów wewnętrznych lub konkretnego sprzętu i wykorzystać moc, za którą już płacą. Większe runnery GitHub nie mogą też korzystać z minut zawartych w planie, więc duże maszyny na runnerach hostowanych szybko drożeją.

GitHub nie pobiera dziś opłat za minutę za runnery self-hosted. Zapowiedział opłatę platformową $0.002 za minutę dla runnerów self-hosted od 1 marca 2026, a następnie odłożył ją, aby ponownie ocenić swoje podejście. Według stanu na wrzesień 2026 dokumentacja rozliczeń GitHub opisuje użycie self-hosted jako bezpłatne. To, za co GitHub nie płaci, to wszystko wokół runnera.

Trzy składniki kosztu self-hosted

Koszt self-hosted to infrastruktura, czas inżynierów i utwardzanie bezpieczeństwa. Tylko pierwszy z nich widać na fakturze.

Infrastruktura

Za hosty płaci się niezależnie od tego, czy wykonują zadania, czy stoją bezczynnie, więc wymiaruje się je na najbardziej obciążoną godzinę. Do tego dochodzą pamięć masowa na cache i obrazy, ruch sieciowy oraz to, czym monitoruje się i automatycznie skaluje flotę.

Czas inżynierów

Dokumentacja GitHub mówi wprost o odpowiedzialności: przy runnerach self-hosted aktualizacja systemu operacyjnego i całego pozostałego oprogramowania należy do Państwa. W praktyce oznacza to także aktualizacje wersji runnera, rozjeżdżanie się obrazów między hostami, czyszczenie dysków, skrypty autoskalowania i dyżury na wypadek, gdy kolejka przestaje się ruszać.

Utwardzanie bezpieczeństwa

Wskazówki bezpieczeństwa GitHub dotyczące runnerów self-hosted zawierają dwa ostrzeżenia warte przeczytania w całości:

Self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment. GitHub Docs, Secure use reference

Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. GitHub Docs, Secure use reference

GitHub zaleca runnery just-in-time, które wykonują najwyżej jedno zadanie, zanim zostaną usunięte. Dobre wykonanie tego oznacza efemeryczne maszyny, izolację między zadaniami, kontrolę ruchu wychodzącego i ostrożne obchodzenie się z sekretami. Każdy z tych elementów to praca, którą trzeba zaprojektować, zbudować i utrzymywać.

Dobre praktyki dla runnerów self-hosted w dużej skali

Wskazówki bezpieczeństwa GitHub i opublikowane przez AWS praktyki dla runnerów w dużej skali prowadzą do tej samej listy. Każda pozycja to osobny projekt:

• Runnery efemeryczne: jedno zadanie na maszynę, aby nic nie przechodziło między zadaniami.
• Grupy runnerów: rozdzielenie runnerów według repozytorium i środowiska, najlepiej na osobnych kontach.
• Krótkotrwałe poświadczenia: OpenID Connect do chmury zamiast długotrwałych kluczy dostępu.
• Kontrola ruchu wychodzącego: ograniczenie tego, z czym zadanie może się łączyć, a nie tylko tego, co uruchamia.
• Czas startu: pule gotowych maszyn i własne obrazy, ponieważ maszyny efemeryczne uruchamiają się wolniej.
• Koszt: instancje spot z rozwiązaniem awaryjnym dla długotrwałych zadań.
• Monitorowanie: wskaźniki zadań w kolejce, działających i ukończonych, z alertami.

W CRACI pierwsza i czwarta pozycja są częścią runnera: każde zadanie działa w izolowanej maszynie wirtualnej w ramach polityki ruchu wychodzącego, która jest walidowana przed startem zadania i blokuje ruch w razie awarii (fail closed).

Model kosztów do wypełnienia

Przykład A

Dane przykładowe, a nie benchmarki. 60 000 minut buildu miesięcznie na runnerach z 2 vCPU, $350 miesięcznie za hosty runnerów i 8 godzin utrzymania miesięcznie po $85 za godzinę.

• Self-hosted: $350 + (8 × $85) = $350 + $680 = $1,030 miesięcznie
• CRACI: 60 000 × $0.004 = $240 miesięcznie

Przykład B

Dane przykładowe, a nie benchmarki. Te same 60 000 minut, ale hosty kosztują $115 miesięcznie, a utrzymanie zajmuje 2 godziny po $85 za godzinę.

• Self-hosted: $115 + (2 × $85) = $115 + $170 = $285 miesięcznie
• CRACI: $240 miesięcznie

W przykładzie B obie opcje są zbliżone pod względem samej mocy obliczeniowej. To realny wynik dla zespołów z tanimi hostami i stabilną konfiguracją. Aby znaleźć własny próg opłacalności, należy odjąć koszt hostów od kwoty CRACI i podzielić przez swój koszt godzinowy. Przy hostach z przykładu B to ($240 minus $115) ÷ $85, czyli około 1,5 godziny utrzymania miesięcznie.

Dwóch rzeczy wzór nie pokazuje. Po pierwsze, kwota CRACI obejmuje więcej niż moc obliczeniową (zob. następna sekcja). Po drugie, godziny to dana, którą większość zespołów zaniża. Należy liczyć aktualizacje obrazów, poprawki bezpieczeństwa, skalowanie, czyszczenie dysków i czas poświęcony na nieudane zadania, a nie tylko początkową konfigurację.

Czego nie dają runnery self-hosted

Runner self-hosted uruchamia zadanie, ale nie rejestruje tego, co ono zrobiło. Na runnerach CRACI każdy build tworzy dowody w trakcie działania:

• SBOM z buildu w CycloneDX lub SPDX, z proxy rozpoznającego pakiety, które obserwuje, co pobiera zadanie, łącznie z pakietami przywróconymi z cache CI. Kompletność jest określona dla każdego zadania i cache.
• Polityka ruchu wychodzącego, domyślne blokowanie lub zezwalanie, z 24 wbudowanymi presetami źródeł oprogramowania i typowanymi własnymi źródłami. Polityki są walidowane przed startem zadania i blokują ruch w razie awarii (fail closed). Naruszenia wywołują alerty.
• Ślad sieciowy każdego zadania, dostępny przez API.
• Dane o pochodzeniu, dostępne przez API.
• Śledzenie podatności w obrębie buildów i repozytoriów, z ciągłą ponowną oceną monitorowanych SBOM-ów.

Część tego można zbudować na runnerach self-hosted z własnym proxy, narzędziami SBOM i logowaniem sieci. Jeśli Państwo to zrobią, czas budowy i utrzymania należy dodać do powyższego modelu kosztów.

Czego CRACI nie oferuje

CRACI nie oferuje dziś runnerów hostowanych przez klienta ani on-premise; są one w planach rozwoju dla Enterprise. Buildy działają na zarządzanych runnerach CRACI na europejskiej infrastrukturze. Jeśli zadanie musi działać w Państwa własnej sieci, na Państwa sprzęcie lub w środowisku air-gapped, należy zachować dla niego runner self-hosted.

• Runnery CRACI działają dziś tylko na Linuksie; Windows i macOS są w planach rozwoju. Buildy macOS i Windows pozostają tam, gdzie są.
• x86-64 i ARM64 działają według tej samej stawki.
• Obrazy: CRACI Slim, CRACI Slim ARM64 i kompatybilny z GitHub obraz Ubuntu 24.04. Zagnieżdżona wirtualizacja jest dostępna na x86-64 i w wersji preview na ARM64.
• GitHub Actions to obsługiwana integracja CI.

Konfiguracja mieszana jest powszechna. Przeniesienie zadania to zmiana jego linii runs-on, więc można przenieść większość zadań, a kilka zostawić na runnerach self-hosted. Tylko zadania na runnerach CRACI otrzymują SBOM-y z buildu i politykę sieciową.

Jak podjąć decyzję

Decyzję warto oprzeć na własnych liczbach: koszcie runnerów i godzinach z ostatniego miesiąca, wymaganych dowodach i jednym prawdziwym workflow uruchomionym na każdej z opcji.

1. Proszę zsumować rachunek za hosty z ostatniego miesiąca i godziny, które zespół poświęcił na runnery, łącznie z incydentami.
2. Proszę policzyć swoje minuty buildu.
3. Proszę wstawić obie wartości do powyższych wzorów.
4. Proszę wypisać wymagane dowody (SBOM-y, pochodzenie, kontrole sieciowe) i to, czego wymagałoby ich uzyskanie na obecnych runnerach.
5. Proszę umówić demo i uruchomić jeden prawdziwy workflow na CRACI, aby porównać.

Więcej o działaniu runnerów: integracja CI/CD, bezpieczeństwo w CRACI i dokumentacja.

Runnery self-hosted GitHub Actions: FAQ

Krótkie odpowiedzi o koszcie, konfiguracji, bezpieczeństwie i limitach.

Czym jest runner self-hosted w GitHub Actions?

Runner self-hosted to maszyna, którą Państwo wdrażają i którą zarządzają, uruchamiająca zadania GitHub Actions. Może być fizyczna, wirtualna, może to być kontener, w siedzibie firmy lub na koncie w chmurze. Instaluje się na niej aplikację runnera GitHub, rejestruje ją w repozytorium, organizacji lub przedsiębiorstwie i wskazuje przez runs-on: self-hosted lub własne etykiety.

Czy runnery self-hosted w GitHub Actions są darmowe?

Według stanu na wrzesień 2026 GitHub nie pobiera opłat za minutę za runnery self-hosted. Zapowiedział opłatę platformową $0.002 za minutę od 1 marca 2026, a następnie odłożył ją, aby ponownie ocenić swoje podejście. Nadal płacą Państwo za maszyny, ich pamięć masową i sieć oraz za czas potrzebny na aktualizacje i zabezpieczanie.

Czy jeden runner self-hosted może obsługiwać kilka repozytoriów?

Runner rejestruje się w jednym repozytorium, organizacji lub przedsiębiorstwie naraz. Aby współdzielić go między repozytoriami, należy zarejestrować go na poziomie organizacji i kontrolować dostęp za pomocą grup runnerów albo uruchomić na tej samej maszynie kilka instancji runnera, każdą zarejestrowaną osobno.

Na jakich systemach operacyjnych może działać runner self-hosted?

GitHub obsługuje aplikację runnera na popularnych dystrybucjach Linuksa, takich jak Ubuntu 20.04 i nowsze, Debian 10 i nowsze oraz RHEL 8 i nowsze, na Windows 10, 11 i Windows Server 2016 do 2022 oraz na macOS 11 i nowszych. Działa na x64 i ARM64, a na Linuksie także na ARM32.

Jak długo może działać zadanie na runnerze self-hosted?

Do 5 dni, wobec 6 godzin na runnerach hostowanych przez GitHub. Zadanie, które pozostaje w kolejce dłużej niż 24 godziny, kończy się niepowodzeniem.

Czy runnery self-hosted są bezpieczne dla repozytoriów publicznych?

GitHub podaje, że runnerów self-hosted prawie nigdy nie należy używać w repozytoriach publicznych, ponieważ każdy może otworzyć pull request i uruchomić kod na maszynie. Zaleca efemeryczne runnery just-in-time, które wykonują najwyżej jedno zadanie, a do tego izolację, kontrolę ruchu wychodzącego i ostrożne obchodzenie się z sekretami.

Co robi Actions Runner Controller?

Actions Runner Controller (ARC) to operator Kubernetes, który orkiestruje i skaluje runnery self-hosted dla GitHub Actions. Zestawy skalowania runnerów rosną i maleją wraz z liczbą działających workflow. Nadal to Państwo obsługują klaster, obrazy i otaczającą je sieć.

Czy runnery CRACI mogą działać w mojej własnej sieci?

Nie dziś. CRACI oferuje runnery zarządzane na europejskiej infrastrukturze, a runnery hostowane przez klienta są w planach rozwoju dla Enterprise. Zadania, które muszą działać w Państwa sieci, mogą pozostać na runnerach self-hosted, podczas gdy pozostałe przechodzą na CRACI.