Runner ospitati da GitHub e 7 alternative

Che cosa sono i runner ospitati da GitHub?

I runner ospitati da GitHub sono le macchine virtuali che GitHub mette a disposizione per eseguire i Suoi job GitHub Actions. Ogni job riceve una nuova VM in Microsoft Azure con Ubuntu, Windows o macOS e un insieme di strumenti preinstallati, e Lei la sceglie con un'etichetta come runs-on: ubuntu-latest.

GitHub mantiene le immagini nel repository actions/runner-images e ne aggiorna il software ogni settimana. Supporta al massimo due immagini generalmente disponibili e un'immagine beta alla volta, e inizia a ritirare l'etichetta più vecchia quando una nuova raggiunge la disponibilità generale. I runner Linux e macOS offrono sudo senza password.

Specifiche e prezzi dei runner standard

Nei repository privati un runner Linux standard ha 2 vCPU, 8 GB di RAM e un SSD da 14 GB, per $0.006 al minuto su x64. I repository pubblici dispongono di 4 vCPU e 16 GB di RAM su Linux e Windows, gratuitamente.

Limiti da mettere in conto

• Fatturazione: ogni job viene arrotondato al minuto intero. I piani includono 2.000 minuti con Free, 3.000 con Pro e Team e 50.000 con Enterprise Cloud.
• Durata dei job: fino a 6 ore per job; ubuntu-slim interrompe i job dopo 15 minuti.
• Concorrenza: 20 job simultanei con Free, 40 con Pro, 60 con Team e 500 con Enterprise, con macOS limitato a 5 con Free, Pro e Team.
• Runner più grandi: fino a 96 core su Linux x64, con IP statici e rete privata Azure, nei piani Team ed Enterprise Cloud. Costano da $0.012 al minuto in su e non usano mai i minuti inclusi.
• Evidenze: il runner non registra quali pacchetti ha scaricato un job. Il dependency graph di GitHub descrive il repository, non una build specifica.

Costo di GitHub Actions: quanto costa un minuto e come ridurlo

Perché i team cercano alternative

I team sostituiscono i runner ospitati da GitHub quando la fattura, la capacità, il controllo della rete o le evidenze di release non sono più adeguati. Per molti team le impostazioni predefinite bastano: non c'è nulla da gestire, tutti e tre i sistemi operativi sono disponibili e i runner standard sono gratuiti nei repository pubblici.

Noi sviluppiamo CRACI: ne tenga conto; descriviamo ogni opzione in base alla sua documentazione e diciamo quando un altro strumento è più adatto. I team guardano altrove quando la loro situazione cambia:

• Volume. A settembre 2026, GitHub indica per un runner standard Linux x64 a 2 core $0.006 al minuto e arrotonda ogni job al minuto intero. Con molti job brevi, questo arrotondamento pesa.
• Capacità e caching. Le build superano la configurazione predefinita, o passano il tempo a ripristinare le cache.
• Controllo della rete. Vuole limitare ciò che una build può raggiungere, non solo ciò che esegue.
• Evidenze. Un cliente o una normativa chiede che cosa è entrato in una release, e un runner generico non lo registra.
• Collocazione. Alcuni job devono girare all'interno della Sua rete o del Suo account cloud.

Che cosa valutare

• Prezzo per vCPU-minuto, memoria per vCPU e modalità di arrotondamento dell'utilizzo.
• I sistemi operativi e le architetture di cui ha bisogno, compreso ARM64.
• Caching delle dipendenze e dei layer Docker.
• Controllo dell'egress, e se si tratta di una policy sul job o di un'infrastruttura di rete da mantenere.
• Evidenze di build: SBOM, provenance e un record di ciò che ogni job ha scaricato.
• Dove risiedono i runner, e le evidenze di build richieste dal Suo ufficio acquisti.

Dove un vendor qui sotto pubblica un dato sulla velocità, lo riportiamo come dato di quel vendor. L'unico benchmark corretto è la Sua pipeline.

Le opzioni

CRACI (il nostro prodotto)

CRACI è un runner compatibile con GitHub Actions costruito attorno alla sicurezza della supply chain. Installi la GitHub App di CRACI e imposti runs-on: craci. La fatturazione è di $0.002 per vCPU-minuto ($0.004 per 2 vCPU), misurati al secondo, con ARM64 alla stessa tariffa. Le dimensioni vanno da 1 a 32 unità di calcolo da 1 vCPU e 3 GB di RAM. Ogni job produce una SBOM di ciò che ha scaricato, con uno stato di completezza, e gira sotto una policy di egress in modalità fail closed.

Ideale per: build Linux di software che distribuisce, quando deve mostrare che cosa è entrato in ogni release.

Da valutare se: evidenze e controllo dell'egress contano quanto il costo. Oggi CRACI è solo Linux (Windows e macOS sono in roadmap) e non ha un piano gratuito. CRACI esegue le build circa due volte più velocemente dei runner ospitati da GitHub, grazie a hardware più veloce, tempi di coda più brevi e caching.

CRACI vs runner ospitati da GitHub

Blacksmith

Blacksmith esegue i job GitHub Actions in microVM Firecracker, con Ubuntu su x64 e ARM da 2 a 32 vCPU, Windows in beta pubblica e macOS su Apple M4. Dichiara che i suoi runner sono due volte più veloci dei runner ospitati da GitHub. Una cache co-locata funziona con le cache action standard, e gli sticky disk forniscono il caching dei layer Docker a $0.50 per GB al mese. A settembre 2026, 2 vCPU x64 costano $0.004 al minuto e ARM $0.0025, con 3.000 minuti gratuiti al mese.

Ideale per: Actions più veloci ed economiche, con caching Docker e debug via SSH.

Da valutare se: gli obiettivi sono velocità e costo.

CRACI vs Blacksmith

Depot

Depot offre runner Linux da 2 a 64 vCPU, Windows e, dal piano Startup in su, macOS, collegati a una cache distribuita. Descrive i suoi runner come "up to 3x faster than a GitHub-hosted runner." Il suo servizio di build Docker remote mantiene una cache persistente dei layer, i runner Linux supportano il filtraggio dell'egress e, nel piano Business, i runner possono risiedere nel Suo account AWS. A settembre 2026, 2 vCPU costano $0.006 al minuto oltre i minuti del piano, conteggiati al secondo.

Ideale per: team il cui tempo di CI è dominato dalle build di immagini Docker.

Da valutare se: desidera anche il caching remoto delle build per Bazel, Gradle o Turborepo.

CRACI vs Depot

Namespace

Namespace esegue runner Linux, Windows e macOS su hardware gestito direttamente, selezionati tramite profili di runner. I cache volume conservano i dati su storage locale tra un'esecuzione e l'altra. Le sue policy di egress funzionano in modalità di blocco o in modalità advisory, che registra le decisioni senza bloccare, così può costruire una allowlist dal traffico reale. A settembre 2026, un runner Linux da 2 vCPU e 4 GB costa $0.002 al minuto nel piano e $0.003 in eccedenza.

Ideale per: runner Linux, Windows e macOS da un solo vendor, con cache volume.

Da valutare se: vuole provare una policy di egress prima di applicarla.

CRACI vs Namespace

WarpBuild

WarpBuild offre runner Linux su x86-64 e arm64 fino a 32 vCPU, Windows Server e macOS su Apple M4 Pro, con caching dei layer dei container e snapshot runner. La sua opzione bring-your-own-cloud esegue gli stessi runner nel Suo account AWS, GCP o Azure a $0.002 al minuto più la Sua fattura cloud. Il runner ospitato x86-64 da 2 vCPU costa $0.004 al minuto (a settembre 2026). WarpBuild pubblicizza build da due a dieci volte più veloci.

Ideale per: runner gestiti all'interno del Suo account cloud.

Da valutare se: Le servono il supporto per GitHub Enterprise Server o uno SLA di uptime del 99,9%.

CRACI vs WarpBuild

Confrontiamo CRACI uno a uno anche con RunsOn, che esegue i runner nel Suo account AWS, Ubicloud e Avrea.

Runner self-hosted con Actions Runner Controller

Actions Runner Controller (ARC) è "a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions." I runner scale set crescono e si riducono in base al numero di workflow in esecuzione, e i runner possono essere container effimeri. A settembre 2026 GitHub non addebita costi al minuto per l'utilizzo self-hosted, ma Lei è responsabile del sistema operativo e del software, e GitHub avverte che i runner self-hosted non dovrebbero quasi mai essere usati per repository pubblici.

Ideale per: job che devono girare nella Sua rete o sul Suo hardware.

Da valutare se: usa già Kubernetes e ha il tempo per metterlo in sicurezza e mantenerlo.

Runner gestiti e self-hosted

Add-on: StepSecurity Harden-Runner

Se desidera mantenere i runner ospitati da GitHub, Harden-Runner aggiunge loro sicurezza invece di sostituirli. È un agente aggiunto come primo step di un job. Associa connessioni in uscita, processi e scritture su file a ogni step del workflow, costruisce una baseline in modalità audit e blocca l'egress verso tutto ciò che non è in una allowlist. Supporta pienamente i runner Linux ospitati da GitHub e gira in modalità audit su Windows e macOS. Il piano Community è gratuito per i repository pubblici; Enterprise costa $16 per sviluppatore che contribuisce al mese (a settembre 2026).

Ideale per: controllo dell'egress e visibilità a runtime senza cambiare runner.

CRACI vs StepSecurity

Fianco a fianco

"Non dichiarato" significa che non abbiamo potuto verificarlo nelle pagine pubbliche del vendor.

Quando restare sui runner ospitati da GitHub

• Il Suo utilizzo rientra nei minuti inclusi nel piano, oppure i Suoi repository sono pubblici.
• Vuole zero configurazione e nessun vendor in più.
• Le serve un livello SLSA documentato: GitHub dichiara che le sue artifact attestations forniscono SLSA v1.0 Build Level 2, e Level 3 con i reusable workflow.
• Può combinare: la scelta è per job, quindi i job macOS e Windows possono restare mentre quelli Linux si spostano.

Scopra di più sull'integrazione CI/CD, sui prezzi di CRACI e sul programma per startup, oppure prenoti una demo per vedere uno dei Suoi workflow su CRACI.

Runner ospitati da GitHub: domande frequenti

Specifiche, prezzi, limiti e alternative, in risposte brevi.

Che cosa sono i runner ospitati da GitHub?

Sono le macchine che GitHub mette a disposizione per eseguire i job GitHub Actions. Ogni job riceve una nuova macchina virtuale ospitata da GitHub in Microsoft Azure, con Ubuntu, Windows o macOS e un insieme di strumenti preinstallati dal repository actions/runner-images. Si seleziona con un'etichetta come runs-on: ubuntu-latest.

Quali sono le specifiche di ubuntu-latest?

Nei repository privati, ubuntu-latest è Ubuntu 24.04 su 2 vCPU x64 con 8 GB di RAM e un SSD da 14 GB. Nei repository pubblici la stessa etichetta dispone di 4 vCPU e 16 GB di RAM.

Quanto costano i runner ospitati da GitHub?

A settembre 2026, il runner standard Linux x64 a 2 core costa $0.006 al minuto, arm64 $0.005, Windows $0.010 e macOS $0.062. I piani includono da 2.000 a 50.000 minuti al mese per i runner standard, che sono gratuiti nei repository pubblici. GitHub arrotonda ogni job al minuto intero.

Quanto può durare un job su un runner ospitato da GitHub?

Fino a 6 ore per job. Il runner a singola CPU ubuntu-slim interrompe i job dopo 15 minuti. La concorrenza è limitata in base al piano: 20 job simultanei con Free, 40 con Pro, 60 con Team e 500 con Enterprise.

Che cosa sono i runner più grandi?

I runner più grandi sono runner ospitati da GitHub con più CPU, RAM e disco, fino a 96 core su Linux x64, con opzioni come indirizzi IP statici, rete privata Azure e GPU. Richiedono un piano Team o Enterprise Cloud, sono fatturati al minuto a partire da $0.012 per 4 core e non usano mai i minuti inclusi.

Devo usare runner ospitati da GitHub o self-hosted?

I runner ospitati da GitHub non richiedono manutenzione e sono adatti alla maggior parte dei team il cui utilizzo rientra nei minuti inclusi. I runner self-hosted oggi non hanno costi GitHub al minuto, ma è Lei a dover gestire, aggiornare e proteggere le macchine, e GitHub sconsiglia di usarli su repository pubblici. Un runner gestito come CRACI si colloca a metà: nulla da gestire, un prezzo di listino più basso sui runner Linux standard ed evidenze di build su ogni job.

Posso cambiare runner senza modificare i miei workflow?

Sì. Ogni alternativa gestita in questa pagina mantiene i Suoi workflow su GitHub Actions e cambia solo l'etichetta runs-on, job per job. Su CRACI installa la GitHub App e imposta runs-on: craci.

CRACI ha un piano gratuito?

No. Paga per minuto di build dal primo minuto, $0.004 su un runner da 2 vCPU, misurati al secondo, senza canone mensile né costo per SBOM. Il programma per startup offre almeno 100.000 minuti di build gratuiti e un onboarding guidato.