GitHub Actions self-hosted runner pro celou firmu

GitHub Actions self-hosted runner je stroj, který spravujete vy a který bere úlohy z vašich workflowů. My máme jeden pro celou organizaci. Každý repozitář si ho vybírá jednou proměnnou organizace a bez ní se vrátí na hostované runnery od GitHubu.

Fungovat nám to pomáhají tři rozhodnutí. Runner je zaregistrovaný na úrovni organizace, ne u jednoho repozitáře. Nemá přístup k Docker socketu, a to záměrně. A repozitáře, které patří našim klientům, na něm nikdy neběží.

Co je self-hosted runner a kdy se vyplatí?

Hostované runnery od GitHubu jsou čerstvé virtuálky, které GitHub spustí pro každou úlohu. Self-hosted runner je váš vlastní stroj s runner aplikací od GitHubu. Nainstalujete ho, aktualizujete a rozhodujete, kam se dostane.

Self-hosted runner se vyplatí, když úlohy běží často, když potřebují něco, co hostovaný image nemá, nebo když by dlouhé úlohy agentů snědly hostované minuty. U nás rozhodly poslední dva důvody. Naše CI spouští u většiny pull requestů validátor, AI code review a AI ověření, a to v mnoha repozitářích.

Jak vybíráme runner pro každý repozitář?

Runner nejmenujeme v žádném workflow. Každá šablona workflow má stejný řádek. Krok validate v něm pochází z wizrd, našeho interního pluginu a CLI pro Claude Code (není veřejný), a stejný vzor funguje i s vaší vlastní action:

jobs:
  validate:
    runs-on: ${{ vars.CI_RUNNER_LABEL || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v4
      - uses: Digitaliko/wizrd/.github/actions/validate@v1

CI_RUNNER_LABEL je proměnná organizace s hodnotou self-hosted, viditelná pro všechny repozitáře. Když je nastavená, úloha jde na náš runner. Když chybí, výraz se vrátí na ubuntu-latest.

Právě o ten návrat jde. Když box spadne, jedna úprava proměnné pošle všechny repozitáře zpět na hostované runnery. Nikdo neupravuje ani jeden soubor s workflow.

Nastavení mělo čtyři kroky:

GitHub tuto možnost popisuje přímo: runnery přidané „at the organization level, where they can be used to process jobs for multiple repositories in an organization“ (GitHub docs, stav k 24. 10. 2026).

Proč jsme runneru vzali Docker?

Protože CI runner spouští kód z pull requestů. GitHub to říká bez obalu:

S Docker socketem je to ještě horší. Bezpečnostní stránka Dockeru píše „only trusted users should be allowed to control your Docker daemon“, protože kontejner si může připojit kořenový adresář hostitele (Docker docs, stav k 24. 10. 2026). Krok workflow, který se k socketu dostane, takový kontejner spustí a stane se rootem na boxu.

Proto jsme 28. 9. 2026 socket hostitele z runnerů odpojili. Úlohy, které potřebovaly service kontejnery, začaly padat na Initialize containers. Upřímně: jejich CI bylo červené už týdny předtím a nikdo si toho nevšiml. Změnila se jen chybová hláška.

Co na runneru běží a co ne?

Jen CI a práce agentů: validátor, AI code review, AI ověření a kroky naší pipeline pro agenty. Produkce ne. Jak krok ověření posuzuje pull request, píšeme v článku LLM as a judge.

Produkční webové servery jsou samostatný stroj. U jednoho klientského projektu kdysi běžely buildy vedle produkce, a když se přesunuly pryč, produkci šlo zmenšit. Vrátit CI vedle ní by vrátilo i souboj o výkon, který ten přesun vyřešil.

Samotný runner zůstává holý. Naše verify action začíná takto, protože recenzent potřebuje Node a skripty repozitáře svůj package manager:

steps:
  # the self-hosted runner is bare: the reviewer needs node, the repo scripts need their package manager
  - uses: actions/setup-node@v4
    with:
      node-version: 22
  - uses: oven-sh/setup-bun@v2
  - shell: bash
    run: corepack enable

Každá úloha si deklaruje, co potřebuje. Úloha, která funguje na našem runneru, funguje i na ubuntu-latest. Díky tomu je návrat bezpečný.

Proč repozitáře klientů zůstávají na hostovaných runnerech?

Některé repozitáře patří našim klientům a jsou v jejich vlastní GitHub organizaci. Jejich workflowy nechávají runs-on: ubuntu-latest. Má to tři důvody:

• Je to jejich kód a jejich CI. Klient, který vlastní repozitář, nemá záviset na stroji, který provozujeme my. Pokud spolupráce skončí, jejich CI běží dál bez jediné změny.
• Náš runner žije v naší organizaci. Runner organizace obsluhuje repozitáře té organizace. Sáhnout přes hranici organizací by znamenalo druhou registraci a druhou hranici důvěry.
• Méně vysvětlování. Nikdo se nemusí ptát, na čem a kde běží jeho kód.

Pravidlo máme zapsané v dokumentaci k validaci. Repozitáře v naší organizaci jdou podle proměnné organizace. Servisní repozitáře klientů zůstávají na ubuntu-latest.

Hodí se self-hosted runner vaší firmě?

Projděte si, co máte dnes:

Poslední bod je limit, který zabolí jako první. Jeden proces runneru bere jednu úlohu naráz a všechno ostatní čeká. Krátké úlohy to skryjí. Dlouhé úlohy agentů ne. Více procesů runneru na stejném boxu je levnější řešení než větší stroj.

Co na našem runneru běží, AI review každého pull requestu, popisujeme v článku AI code review s Claude Code v CI. Jak daleko pouštíme agenta na jeho vlastním stroji, je v článku Claude Code permissions: co smí agent a kdy bypass.

Potřebujete CI, na které se spoléhá celý tým i jeho agenti?

Runnery, sdílené CI actions a review kolem nich nastavujeme vývojovým týmům v rámci služby seniorní vývojář do týmu. Stranu agentů pokrývá AI-native SDLC pro vývojové týmy. AI dnes píše všechen náš kód a za výsledek ručí senior. Od roku 2023 jsme dodali 15+ produkčních projektů.

Ozveme se do dvou pracovních dnů a společně vybereme, co vyřešíme jako první.

Pokud si chcete nejdřív promluvit, domluvte si meeting na 15 minut s Filipem.

Kdyby váš runner dnes v noci spadl, kolik souborů s workflowy byste zítra museli upravit?

Časté otázky

Co je GitHub Actions self-hosted runner?

Stroj, který spravujete vy, běží na něm runner aplikace GitHub Actions a bere úlohy z vašich workflowů. Může to být server v cloudu, virtuálka nebo počítač v kanceláři. Ve workflow ho vyberete přes runs-on a jeho labely.

Může jeden self-hosted runner obsluhovat všechny repozitáře organizace?

Ano. Runner zaregistrovaný na úrovni organizace zpracovává úlohy pro více repozitářů v této organizaci. Přes runner groups omezíte, které repozitáře ho smějí používat.

Je self-hosted runner bezpečný pro veřejné repozitáře?

GitHub píše, že self-hosted runnery by se téměř nikdy neměly používat pro veřejné repozitáře, protože kdokoli otevře pull request a spustí kód na vašem stroji. I u soukromých repozitářů tam může spustit kód každý, kdo smí otevřít pull request.

Jak přepnout mezi self-hosted a hostovaným runnerem od GitHubu?

Výrazem v runs-on: runs-on: ${{ vars.CI_RUNNER_LABEL || 'ubuntu-latest' }}. Když je proměnná nastavená, úlohy jdou na váš runner. Když není, vrátí se na hostovaný Ubuntu od GitHubu. Jedna úprava proměnné organizace přesune všechny repozitáře.

Proč nepřipojit do runneru Docker socket?

Kdo může mluvit s Docker daemonem, spustí kontejner s připojeným souborovým systémem hostitele a stane se rootem na stroji. Na CI runneru je to každý, kdo otevře pull request. Pokud úloha potřebuje kontejnery, dejte jí vlastní daemon.