Runner self-hosted di GitHub Actions e runner gestiti CRACI

Che cos'è un runner self-hosted di GitHub Actions?

Un runner self-hosted è una macchina che Lei distribuisce e gestisce e che esegue job GitHub Actions al posto di una VM ospitata da GitHub. Può essere un server fisico, una macchina virtuale, un container, on-premise o nel Suo account cloud, e GitHub afferma che Lei è responsabile della macchina e di tutto il suo software.

• Registrazione: un runner si registra presso un solo repository, un'organizzazione o un'enterprise alla volta. Lo registri a livello di organizzazione e usi i runner group per condividere i runner tra i repository.
• Piattaforme: l'applicazione runner supporta le distribuzioni Linux più comuni, Windows 10, 11 e Windows Server, e macOS 11 e successive, su x64 e ARM64.
• Rete: il runner si connette a GitHub tramite HTTPS in uscita sulla porta 443.
• Aggiornamenti: l'applicazione runner deve essere aggiornata entro 30 giorni da una nuova release. Si aggiorna da sola, a meno che Lei non disattivi questa funzione.
• Limiti: un job può durare fino a 5 giorni, contro le 6 ore sui runner ospitati da GitHub, e un job in coda per più di 24 ore fallisce.
• Scalabilità: Actions Runner Controller (ARC), un operator Kubernetes, scala i runner scale set in base al numero di workflow in esecuzione. I runner registrati con --ephemeral accettano un solo job.

Perché i team scelgono il self-hosting

I team scelgono il self-hosting per ridurre i costi al minuto, per raggiungere sistemi interni o hardware specifico e per usare capacità che pagano già. Inoltre i runner più grandi di GitHub non possono usare i minuti inclusi, quindi le macchine grandi diventano costose sui runner ospitati.

Oggi GitHub non addebita costi al minuto per i runner self-hosted. Aveva annunciato un costo di piattaforma cloud di $0.002 al minuto per i runner self-hosted dal 1º marzo 2026, poi l'ha rinviato "to take time to re-evaluate our approach." A settembre 2026, la documentazione di fatturazione di GitHub descrive l'utilizzo self-hosted come gratuito. Ciò che GitHub non paga è tutto ciò che sta intorno al runner.

Le tre componenti del costo self-hosted

Il costo self-hosted è fatto di infrastruttura, tempo di engineering e hardening di sicurezza. Solo la prima compare in fattura.

Infrastruttura

Lei paga gli host sia che eseguano job sia che restino inattivi, quindi li dimensiona per l'ora di punta. A questo si aggiungono lo storage per cache e immagini, il traffico di rete e ciò che usa per monitorare la flotta e scalarla automaticamente.

Tempo di engineering

La documentazione di GitHub è diretta sulla responsabilità: con i runner self-hosted, "you are responsible for updating the operating system and all other software." In pratica significa anche aggiornamenti di versione dei runner, disallineamento delle immagini tra gli host, pulizia dei dischi, script di autoscaling e qualcuno reperibile quando la coda si ferma.

Hardening di sicurezza

Le indicazioni di sicurezza di GitHub per i runner self-hosted includono due avvertenze che vale la pena leggere per intero:

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 raccomanda runner just-in-time che eseguono al massimo un job prima di essere rimossi. Farlo bene significa macchine effimere, isolamento tra i job, controlli sul traffico di rete in uscita e gestione attenta dei secret. Ciascuno di questi elementi è lavoro che Lei progetta, costruisce e mantiene in funzione.

Best practice per i runner self-hosted su larga scala

Le indicazioni di sicurezza di GitHub e le pratiche pubblicate da AWS per i runner su larga scala convergono sullo stesso elenco. Ogni voce è un progetto a sé:

• Runner effimeri: un job per macchina, così nulla passa da un job all'altro.
• Runner group: separare i runner per repository e ambiente, idealmente in account separati.
• Credenziali a breve durata: OpenID Connect verso il Suo cloud invece di chiavi di accesso a lunga durata.
• Controllo dell'egress: limitare ciò che un job può raggiungere, non solo ciò che esegue.
• Tempi di avvio: warm pool e immagini personalizzate, perché le macchine effimere si avviano più lentamente.
• Costi: istanze spot con un fallback per i job di lunga durata.
• Monitoraggio: metriche sui job in coda, in esecuzione e completati, con alert.

Su CRACI la prima e la quarta voce sono comprese nel runner: ogni job viene eseguito in una macchina virtuale isolata sotto una policy di egress convalidata prima dell'avvio del job e in modalità fail-closed.

Un modello di costo da compilare

Esempio A

Valori illustrativi, non benchmark. 60.000 minuti di build al mese su runner da 2 vCPU, $350 al mese per gli host dei runner e 8 ore al mese di manutenzione a $85 l'ora.

• Self-hosted: $350 + (8 × $85) = $350 + $680 = $1,030 al mese
• CRACI: 60.000 × $0.004 = $240 al mese

Esempio B

Valori illustrativi, non benchmark. Gli stessi 60.000 minuti, ma gli host costano $115 al mese e la manutenzione richiede 2 ore a $85 l'ora.

• Self-hosted: $115 + (2 × $85) = $115 + $170 = $285 al mese
• CRACI: $240 al mese

Nell'esempio B, le due opzioni sono vicine sul solo calcolo. È un risultato reale per i team con host economici e una configurazione stabile. Per trovare il Suo punto di pareggio, sottragga il costo degli host dalla cifra di CRACI e divida per il Suo costo orario. Con gli host dell'esempio B, si ottiene ($240 meno $115) ÷ $85, ovvero circa 1,5 ore di manutenzione al mese.

Due cose che la formula non mostra. Primo, la cifra di CRACI comprende più del calcolo (veda la sezione successiva). Secondo, le ore sono il valore che la maggior parte dei team sottostima. Conti gli aggiornamenti delle immagini, le patch di sicurezza, la scalabilità, la pulizia dei dischi e il tempo speso sui job falliti, non solo la configurazione iniziale.

Che cosa i runner self-hosted non Le danno

Un runner self-hosted esegue il Suo job, ma non registra ciò che il job ha fatto. Sui runner CRACI, ogni build produce evidenze durante l'esecuzione:

• Una SBOM in fase di build in CycloneDX o SPDX, da un proxy che riconosce i pacchetti e osserva ciò che il job scarica, compresi i pacchetti ripristinati dalle cache CI. La completezza è dichiarata per job e per cache.
• Policy di egress di rete, default deny o allow, con 24 preset integrati di sorgenti software e sorgenti personalizzate tipizzate. Le policy vengono convalidate prima dell'avvio del job e operano in modalità fail-closed. Le violazioni generano alert.
• Una traccia di rete per job, disponibile tramite l'API.
• Dati di provenance, disponibili tramite l'API.
• Monitoraggio delle vulnerabilità tra build e repository, con le SBOM monitorate rivalutate continuamente.

Può costruire parte di tutto questo sui runner self-hosted con un Suo proxy, strumenti SBOM e logging di rete. In tal caso, il tempo per costruirli e mantenerli va inserito nel modello di costo qui sopra.

Che cosa CRACI non offre

Oggi CRACI non offre runner ospitati dal cliente o on-premise; sono in roadmap per Enterprise. Le build vengono eseguite sui runner gestiti di CRACI su infrastruttura europea. Se un job deve essere eseguito all'interno della Sua rete, su hardware di Sua proprietà o in un ambiente air-gapped, mantenga un runner self-hosted per quel job.

• Oggi i runner CRACI sono solo Linux; Windows e macOS sono in roadmap. Le build macOS e Windows restano dove sono.
• x86-64 e ARM64 hanno la stessa tariffa.
• Immagini: CRACI Slim, CRACI Slim ARM64 e un'immagine Ubuntu 24.04 compatibile con GitHub. La virtualizzazione annidata è disponibile su x86-64 e in anteprima su ARM64.
• GitHub Actions è l'integrazione CI supportata.

Una configurazione mista è comune. Spostare un job significa modificare la sua riga runs-on, quindi può spostare la maggior parte dei job e tenerne alcuni sui runner self-hosted. Solo i job sui runner CRACI ottengono SBOM in fase di build e policy di rete.

Come decidere

Decida in base ai Suoi numeri: il costo e le ore dei runner del mese scorso, le evidenze che Le vengono richieste e un workflow reale eseguito su ciascuna opzione.

1. Sommi la fattura degli host del mese scorso e le ore dedicate dal Suo team ai runner, compresi gli incidenti.
2. Conti i Suoi minuti di build.
3. Inserisca entrambi i valori nelle formule qui sopra.
4. Elenchi le evidenze che Le vengono richieste (SBOM, provenance, controlli di rete) e che cosa servirebbe per produrle sui Suoi runner attuali.
5. Prenoti una demo ed esegua un workflow reale su CRACI per fare il confronto.

Per saperne di più sul funzionamento dei runner: integrazione CI/CD, la sicurezza in CRACI e la documentazione.

Runner self-hosted di GitHub Actions: domande frequenti

Risposte brevi su costi, configurazione, sicurezza e limiti.

Che cos'è un runner self-hosted di GitHub Actions?

Un runner self-hosted è una macchina che Lei distribuisce e gestisce e che esegue job GitHub Actions. Può essere fisica, virtuale, un container, on-premise o in un account cloud. Vi installa l'applicazione runner di GitHub, la registra presso un repository, un'organizzazione o un'enterprise e la seleziona con runs-on: self-hosted o con etichette proprie.

I runner self-hosted di GitHub Actions sono gratuiti?

A settembre 2026 GitHub non addebita costi al minuto per i runner self-hosted. Aveva annunciato un costo di piattaforma di $0.002 al minuto dal 1º marzo 2026, poi l'ha rinviato per rivalutare il proprio approccio. Lei paga comunque le macchine, il loro storage e la rete, oltre al tempo per tenerle aggiornate e sicure.

Un solo runner self-hosted può servire più repository?

Un runner si registra presso un solo repository, un'organizzazione o un'enterprise alla volta. Per condividerne uno tra più repository, lo registri a livello di organizzazione e controlli gli accessi con i runner group, oppure esegua più istanze di runner sulla stessa macchina, ciascuna registrata separatamente.

Quali sistemi operativi possono eseguire un runner self-hosted?

GitHub supporta l'applicazione runner sulle distribuzioni Linux più comuni, come Ubuntu 20.04 e successive, Debian 10 e successive e RHEL 8 e successive, su Windows 10, 11 e Windows Server da 2016 a 2022, e su macOS 11 e successive. Funziona su x64 e ARM64, e su ARM32 per Linux.

Quanto può durare un job su un runner self-hosted?

Fino a 5 giorni, contro le 6 ore sui runner ospitati da GitHub. Un job che resta in coda per più di 24 ore fallisce.

I runner self-hosted sono sicuri per i repository pubblici?

GitHub afferma che i runner self-hosted non dovrebbero quasi mai essere usati per i repository pubblici, perché chiunque può aprire una pull request ed eseguire codice sulla macchina. La sua raccomandazione sono runner effimeri just-in-time che eseguono al massimo un job, oltre a isolamento, controllo dell'egress e gestione attenta dei secret.

Che cosa fa Actions Runner Controller?

Actions Runner Controller (ARC) è un operator Kubernetes che orchestra e scala i runner self-hosted per GitHub Actions. I runner scale set crescono e si riducono in base al numero di workflow in esecuzione. Lei continua a gestire il cluster, le immagini e la rete circostante.

I runner CRACI possono funzionare nella mia rete?

Non oggi. CRACI offre runner gestiti su infrastruttura europea, con runner ospitati dal cliente in roadmap per Enterprise. I job che devono essere eseguiti all'interno della Sua rete possono restare sui runner self-hosted mentre gli altri passano a CRACI.