Self-hosted runnery GitHub Actions vs spravované runnery CRACI

Co je self-hosted runner pro GitHub Actions?

Self-hosted runner je stroj, který sami nasadíte a spravujete a který spouští joby GitHub Actions místo virtuálního stroje hostovaného na GitHubu. Může to být fyzický server, virtuální stroj, kontejner, u vás v serverovně nebo ve vašem cloudovém účtu, a GitHub uvádí, že za stroj a veškerý jeho software odpovídáte vy.

• Registrace: runner se registruje vždy k jednomu repozitáři, organizaci nebo enterprise účtu. Zaregistrujte ho na úrovni organizace a pomocí skupin runnerů je sdílejte mezi repozitáři.
• Platformy: aplikace runneru podporuje běžné linuxové distribuce, Windows 10, 11 a Windows Server a macOS 11 a novější, na x64 a ARM64.
• Síť: runner se ke GitHubu připojuje odchozím HTTPS na portu 443.
• Aktualizace: aplikaci runneru je nutné aktualizovat do 30 dnů od nového vydání. Aktualizuje se sama, pokud to nevypnete.
• Limity: job může běžet až 5 dní, oproti 6 hodinám na runnerech hostovaných na GitHubu, a job, který je ve frontě déle než 24 hodin, selže.
• Škálování: Actions Runner Controller (ARC), operátor pro Kubernetes, škáluje runner scale sets podle počtu běžících workflow. Runnery registrované s --ephemeral převezmou jediný job.

Proč týmy provozují vlastní runnery

Týmy provozují vlastní runnery, aby snížily náklady za minutu, dostaly se k interním systémům nebo specifickému hardwaru a využily kapacitu, kterou už platí. Větší runnery GitHubu navíc stojí za minutu tím víc, čím jsou větší, takže velké stroje jsou na hostovaných runnerech drahé.

GitHub dnes za self-hosted runnery neúčtuje poplatek za minutu. Oznámil poplatek za cloudovou platformu $0.002 za minutu pro self-hosted runnery od 1. března 2026 a pak ho odložil, aby svůj přístup přehodnotil. K září 2026 popisuje dokumentace GitHubu k účtování používání self-hosted runnerů jako bezplatné. GitHub ale neplatí za všechno kolem runneru.

Tři složky nákladů na self-hosted runnery

Náklady na self-hosted runnery tvoří infrastruktura, čas inženýrů a zabezpečení (hardening). Na faktuře se objeví jen první z nich.

Infrastruktura

Za hosty platíte, ať joby spouštějí, nebo nečinně stojí, takže je dimenzujete na nejvytíženější hodinu. Připočtěte úložiště pro cache a image, síťový provoz a cokoli, čím flotilu monitorujete a automaticky škálujete.

Čas inženýrů

Dokumentace GitHubu mluví o odpovědnosti přímo: u self-hosted runnerů odpovídáte za aktualizace operačního systému a veškerého dalšího softwaru. V praxi to znamená i upgrady verzí runneru, rozcházející se image mezi hosty, čištění disků, skripty pro automatické škálování a někoho na pohotovosti, když se fronta zastaví.

Zabezpečení (hardening)

Bezpečnostní doporučení GitHubu pro self-hosted runnery obsahují dvě varování, která stojí za přečtení celá:

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 doporučuje runnery just-in-time, které spustí nejvýše jeden job a pak jsou odstraněny. Udělat to dobře znamená dočasné stroje, izolaci mezi joby, kontrolu odchozího síťového provozu a pečlivé zacházení s tajnými klíči. Každou z těchto věcí musíte navrhnout, postavit a udržovat v chodu.

Osvědčené postupy pro self-hosted runnery ve velkém

Bezpečnostní doporučení GitHubu a zveřejněné postupy AWS pro runnery ve velkém se shodují na stejném seznamu. Každá položka je samostatný projekt:

• Dočasné runnery: jeden job na stroj, aby se mezi joby nic nepřenášelo.
• Skupiny runnerů: oddělte runnery podle repozitáře a prostředí, ideálně v samostatných účtech.
• Krátkodobé přihlašovací údaje: OpenID Connect do vašeho cloudu místo dlouhodobých přístupových klíčů.
• Kontrola odchozího provozu: omezte, kam se job může připojit, nejen co spouští.
• Doba spuštění: předehřáté pooly a vlastní image, protože dočasné stroje startují pomaleji.
• Náklady: spot instance se zálohou pro dlouho běžící joby.
• Monitorování: metriky jobů ve frontě, běžících a dokončených, s upozorněními.

Na CRACI jsou první a čtvrtý bod součástí runneru: každý job běží v izolovaném virtuálním stroji pod egress policy, která se ověří před startem jobu a při selhání vše zablokuje.

Model nákladů k vyplnění

Příklad A

Ilustrativní vstupy, ne benchmarky. 60 000 minut buildu měsíčně na runnerech se 2 vCPU, $350 měsíčně za hosty runnerů a 8 hodin údržby měsíčně po $85 za hodinu.

• Self-hosted: $350 + (8 × $85) = $350 + $680 = $1,030 měsíčně
• CRACI: 60 000 × $0.004 = $240 měsíčně

Příklad B

Ilustrativní vstupy, ne benchmarky. Stejných 60 000 minut, ale hosty stojí $115 měsíčně a údržba zabere 2 hodiny po $85 za hodinu.

• Self-hosted: $115 + (2 × $85) = $115 + $170 = $285 měsíčně
• CRACI: $240 měsíčně

V příkladu B jsou obě možnosti, pokud jde jen o výpočetní výkon, blízko sebe. To je reálný výsledek pro týmy s levnými hosty a stabilním nastavením. Svůj bod zvratu zjistíte tak, že od částky za CRACI odečtete náklady na hosty a vydělíte svou hodinovou sazbou. S hosty z příkladu B je to ($240 minus $115) ÷ $85, tedy zhruba 1,5 hodiny údržby měsíčně.

Dvě věci, které vzorec neukazuje. Zaprvé částka za CRACI zahrnuje víc než výpočetní výkon (viz další sekce). Zadruhé hodiny jsou vstup, který většina týmů podceňuje. Započítejte aktualizace image, bezpečnostní záplaty, škálování, čištění disků a čas strávený nad neúspěšnými joby, nejen počáteční nastavení.

Co vám self-hosted runnery nedají

Self-hosted runner váš job spustí, ale nezaznamená, co job dělal. Na runnerech CRACI vytváří každý build důkazy už během běhu:

• SBOM z doby buildu ve formátu CycloneDX nebo SPDX, z proxy, která rozumí balíčkům a sleduje, co job stahuje, včetně balíčků obnovených z cache CI. Úplnost je uvedena pro každý job a každou cache.
• Egress policy pro síť, výchozí zákaz nebo povolení, s 24 vestavěnými předvolbami softwarových zdrojů a typovanými vlastními zdroji. Politiky se ověřují před startem jobu a při selhání vše zablokují. Porušení spouštějí upozornění.
• Síťová stopa pro každý job, dostupná přes API.
• Údaje o původu (provenance), dostupné přes API.
• Sledování zranitelností napříč buildy a repozitáři, s průběžně přehodnocovanými monitorovanými SBOM.

Části z toho si můžete na self-hosted runnerech postavit sami s vlastní proxy, nástroji pro SBOM a síťovým logováním. Pokud to uděláte, čas na vybudování a údržbu patří do modelu nákladů výše.

Co CRACI nenabízí

CRACI dnes nenabízí runnery hostované zákazníkem ani on-premise runnery; jsou v plánu vývoje pro Enterprise. Buildy běží na spravovaných runnerech CRACI na evropské infrastruktuře. Pokud job musí běžet uvnitř vaší vlastní sítě, na vašem vlastním hardwaru nebo v izolovaném (air-gapped) prostředí, ponechte pro něj self-hosted runner.

• Runnery CRACI jsou dnes jen pro Linux; Windows a macOS jsou v plánu vývoje. Buildy pro macOS a Windows zůstávají, kde jsou.
• x86-64 a ARM64 běží za stejnou sazbu.
• Image: CRACI Slim, CRACI Slim ARM64 a image Ubuntu 24.04 kompatibilní s GitHubem. Vnořená virtualizace je k dispozici na x86-64 a ve verzi preview na ARM64.
• GitHub Actions je podporovanou integrací CI.

Kombinované nastavení je běžné. Přesun jobu znamená změnu jeho řádku runs-on, takže můžete přesunout většinu jobů a několik ponechat na self-hosted runnerech. SBOM z doby buildu a síťové politiky získají jen joby na runnerech CRACI.

Jak se rozhodnout

Rozhodněte se podle vlastních čísel: nákladů na runnery a hodin za minulý měsíc, důkazů, které po vás chtějí, a jednoho skutečného workflow spuštěného na každé z možností.

1. Sečtěte účet za hosty za minulý měsíc a hodiny, které váš tým strávil s runnery, včetně incidentů.
2. Spočítejte své minuty buildu.
3. Dosaďte obojí do vzorců výše.
4. Sepište důkazy, které po vás chtějí (SBOM, provenance, síťové kontroly), a co by stálo je vytvořit na vašich současných runnerech.
5. Rezervujte si demo a pro srovnání spusťte jeden skutečný workflow na CRACI.

Více o tom, jak runnery fungují: integrace CI/CD, bezpečnost v CRACI a dokumentace.

Self-hosted runnery GitHub Actions: časté dotazy

Krátké odpovědi o nákladech, nastavení, bezpečnosti a limitech.

Co je self-hosted runner pro GitHub Actions?

Self-hosted runner je stroj, který sami nasadíte a spravujete a který spouští joby GitHub Actions. Může být fyzický, virtuální, kontejner, u vás v serverovně nebo ve vašem cloudovém účtu. Nainstalujete na něj aplikaci GitHub runner, zaregistrujete ho u repozitáře, organizace nebo enterprise účtu a cílíte na něj pomocí runs-on: self-hosted nebo vlastních štítků.

Jsou self-hosted runnery pro GitHub Actions zdarma?

GitHub za self-hosted runnery k září 2026 neúčtuje poplatek za minutu. Oznámil poplatek za platformu $0.002 za minutu od 1. března 2026 a pak ho odložil, aby svůj přístup přehodnotil. Stále platíte za stroje, jejich úložiště a síť a za čas strávený jejich aktualizací a zabezpečením.

Může jeden self-hosted runner obsluhovat více repozitářů?

Runner se registruje vždy k jednomu repozitáři, organizaci nebo enterprise účtu. Chcete-li ho sdílet mezi repozitáři, zaregistrujte ho na úrovni organizace a přístup řiďte skupinami runnerů, nebo na stejném stroji spusťte několik instancí runneru, každou registrovanou zvlášť.

Na jakých operačních systémech může self-hosted runner běžet?

GitHub podporuje aplikaci runneru na běžných linuxových distribucích, jako je Ubuntu 20.04 a novější, Debian 10 a novější a RHEL 8 a novější, na Windows 10, 11 a Windows Server 2016 až 2022 a na macOS 11 a novějším. Běží na x64 a ARM64, u Linuxu i na ARM32.

Jak dlouho může job na self-hosted runneru běžet?

Až 5 dní, oproti 6 hodinám na runnerech hostovaných na GitHubu. Job, který zůstane ve frontě déle než 24 hodin, selže.

Jsou self-hosted runnery bezpečné pro veřejné repozitáře?

GitHub uvádí, že self-hosted runnery by se pro veřejné repozitáře neměly používat téměř nikdy, protože kdokoli může otevřít pull request a spustit na stroji kód. Doporučuje dočasné runnery just-in-time, které spustí nejvýše jeden job, k tomu izolaci, kontrolu odchozího provozu a pečlivé zacházení s tajnými klíči.

Co dělá Actions Runner Controller?

Actions Runner Controller (ARC) je operátor pro Kubernetes, který orchestruje a škáluje self-hosted runnery pro GitHub Actions. Runner scale sets rostou a zmenšují se podle počtu běžících workflow. Cluster, image a síť kolem nich ale stále provozujete vy.

Mohou runnery CRACI běžet v mé vlastní síti?

Dnes ne. CRACI nabízí spravované runnery na evropské infrastruktuře a runnery hostované zákazníkem jsou v plánu vývoje pro Enterprise. Joby, které musí běžet uvnitř vaší sítě, mohou zůstat na self-hosted runnerech, zatímco ostatní joby přejdou na CRACI.