Röviden: A self-hosted runner első pillantásra olcsóbb és rugalmasabb. A valódi ár viszont az üzemeltetés és a megnövelt biztonsági felület — ezt kell szembeállítani a menedzselt futtatók kényelmével.
A GitHub Actions self-hosted runnere csábító ajánlat: a menedzselt futtatók percdíja helyett a saját gépeden futtatsz, és látszólag megspórolod a CI-számlát. A valóság ennél árnyaltabb. A self-hosted runner nem ingyen van — csak a költség átkerül a számláról az üzemeltetési terhek és a biztonsági kockázat oldalára, ahol nehezebb kimutatni, de nem kevésbé valós.
Ez a cikk független elemzés a felhőnatív CI/CD gyakorlatokról szóló nyilvános szakmai anyagok kapcsán. A kérdés nem az, hogy a self-hosted "jó vagy rossz", hanem az, hogy a te terhelési profilod és biztonsági igényed mellett melyik oldal a drágább.
Amit a menedzselt runnerért kapsz
A menedzselt futtatóval minden job tiszta, eldobható környezetben indul. Nincs karbantartás, nincs patch, nincs kapacitástervezés, és a build-környezet reprodukálható. Cserébe percdíjat fizetsz, és a legnagyobb, memóriaigényes gépek drágábbak, illetve bizonyos speciális igényeket (GPU, egyedi hardver, belső hálózati elérés) nehezebb kielégíteni.
Amiért a self-hosted vonzó
A self-hosted mellett általában három érv szól: a költség nagy, tartós terhelésnél, a hozzáférés a privát hálózathoz vagy belső erőforrásokhoz, és a speciális hardver. Ha a CI napi sok órán át pörget nagy gépeket, a saját, jól kihasznált flotta fajlagosan olcsóbb lehet. Ha a build belső adatbázist vagy belső registryt ér el, a self-hosted a hálózati közelség miatt egyszerűbb.
A rejtett tételek
A látszólagos megtakarítás mögött ott vannak a nem számlázott, de valós költségek: a runner-image karbantartása, az operációs rendszer és a futtatókörnyezet patchelése, a kapacitás skálázása csúcsidőben, a leállások kezelése, és — ami a legfontosabb — a biztonsági felület.
A biztonsági felület a kulcskérdés
Egy self-hosted runner, különösen ha publikus repóhoz kötöd, komoly kockázat. Egy külső hozzájárulás pull requestje tetszőleges kódot futtathat a runneren, és ha az a gép hosszú életű, tartja az állapotát build-ek között, vagy hozzáfér belső hálózathoz, akkor egyetlen rosszindulatú futás oldalirányú mozgásra ad lehetőséget.
- Ne köss self-hosted runnert publikus repó fork-pull requestjeihez.
- Használj eldobható, egy jobra szóló, tiszta környezetet, ne hosszú életű, állapottartó gépet.
- Korlátozd a runner hálózati elérését a minimumra.
- Izoláld a runnereket a produkciós hálózattól.
Döntési szempontok sorrendben
A választás nem elvi, hanem terhelési és kockázati kérdés. Egy praktikus döntési sorrend:
- Van-e speciális igény (privát hálózat, egyedi hardver), amit menedzselt runnerrel nehéz? Ha igen, a self-hosted felé billen.
- Publikus repó, külső hozzájárulókkal? Akkor a menedzselt (vagy szigorúan izolált) megoldás az alapértelmezett.
- Tartós, magas kihasználtságú terhelés? Számold ki a fajlagos költséget üzemeltetéssel együtt.
- Van-e csapatod, aki a runner-flottát karbantartja? Ha nincs, a menedzselt olcsóbb, mint amit hinnél.
Egy köztes út
A gyakorlatban sok csapat nem választ élesen, hanem vegyesen üzemel: a hétköznapi build-eket menedzselt runneren futtatja, a speciális igényűeket (belső elérés, nagy gép) pedig izolált, eldobható self-hosted futtatókon, jellemzően automatikusan skálázva. Egy egyszerű workflow-részlet, ami címke alapján irányít:
jobs:
build:
runs-on: ubuntu-latest
integration:
runs-on: [self-hosted, ephemeral, internal-net]Így a kockázatos és drága eseteket célzottan kezeled, a többségnél pedig megmarad a menedzselt megoldás kényelme.
A hibrid modell részletei
A gyakorlatban a legjobb eredményt gyakran a hibrid felállás adja, de ezt is tudatosan kell megtervezni. A menedzselt runnerek vigyék a build-terhelés zömét — a fordítást, a tesztek nagy részét, a lint-eket —, mert ezek eldobható, izolált környezetet igényelnek, és a menedzselt kínálat pont ezt adja. A self-hosted runnereket tartsd fenn a szűk, indokolt esetekre: GPU-s tesztek, belső hálózati integrációs tesztek, speciális hardver.
Így a biztonsági felület kicsi marad (kevés self-hosted gép, jól körülhatárolt feladattal), miközben a megtakarítás ott jelentkezik, ahol a menedzselt kínálat drága vagy nem is elérhető.
A skálázás automatizálása
Ha self-hosted runnert használsz, a statikus, mindig futó gép a legrosszabb megoldás: fizetsz érte tétlenül is, és állapotot halmoz. A jó minta az igény szerinti, automatikus skálázás: a runnerek akkor jönnek létre, amikor van munka, és utána megsemmisülnek. Ez egyszerre olcsóbb (nem fizetsz tétlen kapacitásért) és biztonságosabb (minden job friss környezetben fut).
A rejtett üzemeltetési tételek
A self-hosted flotta teljes költségébe sok minden beletartozik, amit könnyű elfelejteni:
- Az operációs rendszer és az eszközök folyamatos patchelése.
- A runner szoftver verziójának karbantartása.
- A skálázási automatizmus fejlesztése és üzemeltetése.
- A monitorozás, hogy egy elakadt runner ne blokkolja a pipeline-t.
- A biztonsági kontrollok folyamatos fenntartása.
Ezeket összeadva sokszor kiderül, hogy a menedzselt runner "drágább" óradíja valójában olcsóbb, mint a self-hosted teljes birtoklási költsége — különösen kis csapatnál.
Mit jelent ez neked?
A self-hosted runner nem költségmegtakarítás, hanem költségáthelyezés: a percdíj helyett üzemeltetést és biztonsági felelősséget veszel. Akkor éri meg, ha tartós a terhelés, van csapat a karbantartásra, és izolált, eldobható futtatókkal kezelni tudod a kockázatot — különben a menedzselt runner nyugalma jellemzően olcsóbb, mint a saját flotta rejtett számlája.