Come cambiare provider di runner GitHub Actions: etichette, cache, secret, fatturazione e fallback

Questa guida è neutrale rispetto ai fornitori. Spiega che cosa si sposta quando cambia provider di runner GitHub Actions, che cosa si rompe più spesso e come tornare indietro. Noi sviluppiamo CRACI, uno dei provider; compare dove si applica un fatto documentato e in una sezione dedicata alla fine. Per scegliere prima un provider, veda i provider di runner GitHub Actions a confronto e le alternative ai runner ospitati da GitHub.

Che cosa cambia e che cosa resta quando si cambia provider

GitHub Actions ha due metà. GitHub è il control plane: conserva il repository e i file di workflow, attiva i trigger, archivia i secret, assegna i job, mostra log e check, conserva gli artefatti ed emette i token OIDC. Il runner CI è dove un job viene eseguito: una macchina con un'immagine, CPU, disco, un percorso di rete verso internet e di solito una cache locale. GitHub assegna un job a un runner, consegna i secret del job all'avvio e il runner rimanda i log.

Un provider di runner sostituisce solo la seconda metà.

Elemento	Resta su GitHub	Passa al provider
Repository, file di workflow, trigger	Sì	No
Archivio dei secret	Sì	I secret vengono consegnati alla macchina del provider all'avvio del job
Assegnazione dei job, log, interfaccia dei check	Sì	Il runner rimanda i log
Artefatti da actions/upload-artifact	Sì	No
Emittente del token OIDC	Sì	No, ma il token indica che il runner è self-hosted
Macchina, immagine, CPU, memoria, disco	No	Sì
Percorso di rete in uscita e indirizzi IP	No	Sì
Storage della cache	Dipende dal provider	Dipende dal provider
Fatturazione al minuto dei job spostati	No	Sì

Un runner di terze parti si registra presso GitHub come runner self-hosted. Per questo gli si applicano le regole di GitHub per i runner self-hosted: come le etichette instradano i job, come i runner group limitano l'accesso, come il token OIDC lo descrive e come GitHub lo fattura.

La modifica di runs-on e le etichette

GitHub cerca un runner che corrisponda alle etichette e ai gruppi runs-on del job. Se nessun runner corrispondente è online, il job resta in coda finché uno non si connette; se un runner assegnato non prende il job entro 60 secondi, il job torna in coda; e un job che resta in coda per più di 24 ore fallisce (riferimento di GitHub sui runner self-hosted). Un refuso in un'etichetta, o un'app del provider non installata sul repository, si presenta come un job che non parte mai.

I provider codificano la macchina in uno di due modi:

• Nell'etichetta. Ubicloud usa etichette come ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 e Avrea avrea-ubuntu-latest-2-vcpu, con arm nell'etichetta per le macchine ARM. Cambiare dimensione significa cambiare etichetta.
• In uno step di setup. CRACI usa un'unica etichetta, runs-on: craci, e lo step cracicorp/setup@v1 seleziona la dimensione (da 1 a 32 unità di calcolo da 1 vCPU e 3 GB, 2 per impostazione predefinita), l'immagine, la network policy o un runner template di organizzazione tramite il suo slug. Se CRACI non riesce a interpretare un input, esegue l'ambiente predefinito e scrive un avviso nel log del job; un'immagine o un template sconosciuti vengono rifiutati.

Riduca il cambio a una variabile

Metta l'etichetta in una variabile di repository o di organizzazione invece di scriverla nel codice. Passare al nuovo provider o tornare indietro diventa così una modifica alle impostazioni, non una pull request su ogni repository.

jobs:
  build:
    # Falls back to GitHub-hosted when the variable is not set
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: make build

  deploy:
    needs: build
    # Stays on GitHub-hosted until you decide to move it
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

La scelta è per job, quindi i job di build e di test possono spostarsi mentre un job di deploy resta dov'è. Le variabili si possono impostare a livello di organizzazione e sovrascrivere per repository, così un'unica impostazione può spostare un gruppo di repository e un singolo repository può restarne fuori.

Workflow riutilizzabili

Se la stessa pipeline è copiata in molti repository, la sposti in un workflow riutilizzabile che legge il runner da un input o da una variabile. Cambiare runs-on lì cambia ogni repository che lo richiama. I ruleset possono imporre l'esecuzione di un workflow sui repository di un'organizzazione, il che mantiene in uso la versione condivisa.

Immagini dei runner: compatibilità e pinning

L'immagine ospitata di GitHub include un ampio set di strumenti preinstallati e una tool cache ospitata. I provider offrono un'immagine compatibile con quella di GitHub oppure una più snella. Spesso i job dipendono da elementi che non dichiarano mai:

• versioni di linguaggi e strumenti da riga di comando preinstallati;
• sudo senza password e systemd per i servizi avviati con systemctl;
• un daemon Docker in esecuzione, con Buildx e Compose;
• la tool cache ospitata che le action setup-* leggono prima di scaricare;
• spazio libero su disco per le build di grandi dimensioni.

Regola pratica: parta dall'immagine compatibile con GitHub del provider. Sposti un job su un'immagine snella solo quando è verde, e aggiunga step setup-* espliciti per tutto ciò che usava implicitamente.

Pinning: ubuntu-latest passa a una nuova release secondo il calendario di GitHub, e ubuntu-24.04 fissa la release del sistema operativo, non le versioni dei pacchetti installati. Fissi ciò che conta all'interno del job: action di setup con versioni esplicite e immagini container per digest. Chieda a ogni provider che cosa permette di fissare. L'applicazione runner stessa deve continuare ad aggiornarsi per comunicare con GitHub.

Su CRACI le immagini sono CRACI Slim su x86-64 e ARM64 (Ubuntu 24.04, senza systemd) e un'immagine Ubuntu 24.04 completa compatibile con GitHub Actions, selezionata come ubuntu-24.04 o ubuntu-latest, che segue l'immagine del runner Ubuntu 24.04 di GitHub e include la tool cache ospitata. Ogni immagine include Docker Engine, Buildx e Compose v2.

Cache: che cosa si trasferisce e che cosa parte a freddo

Le prime esecuzioni su un nuovo provider sono spesso più lente, e il motivo abituale è una cache fredda, non una macchina lenta. Il funzionamento di actions/cache determina ciò che vede (README di actions/cache):

• Una voce si trova tramite la sua chiave e una versione, che è un hash dei percorsi in cache e dello strumento di compressione.
• Le voci sono limitate al branch; le voci del branch predefinito sono disponibili agli altri branch.
• Per impostazione predefinita, un repository può contenere fino a 10 GB di cache prima che le voci più vecchie vengano rimosse. Gli amministratori del repository e i proprietari dell'organizzazione o dell'enterprise possono alzare il limite; l'uso oltre 10 GB viene addebitato all'account (GitHub sul dependency caching).
• Una cache salvata su Windows non viene ripristinata su un altro sistema operativo, né viceversa, a meno che non sia impostato enableCrossOsArchive; anche uno strumento di compressione diverso produce una versione diversa.

I provider servono la cache in uno di due modi:

Modello	Prime esecuzioni	Compromesso
Il runner usa il servizio di cache di GitHub, come i runner ospitati da GitHub	Le voci esistenti vengono ripristinate	Il traffico della cache attraversa internet tra il provider e GitHub
Il provider serve l'API della cache da uno storage accanto ai suoi runner	Di solito vuota finché le prime esecuzioni non la riempiono, a meno che il provider importi le voci di GitHub o vi ricada	Ripristini più rapidi; le voci scritte lì di solito non sono visibili ai runner ospitati da GitHub

Il secondo punto conta per le flotte miste e per il rollback: se riporta indietro un job, potrebbe partire a freddo anche su GitHub. Chieda quale modello usa il provider e dove risiedono le voci.

Distinguere una cache fredda da un runner lento. Prenda una build Node che mette in cache una grande directory node_modules. Alla prima esecuzione su un nuovo provider, actions/cache segnala un miss, lo step di installazione scarica tutto e lo step finale salva la cache. Dall'esecuzione successiva sullo stesso branch, lo step segnala un hit e lo step di installazione si accorcia. Confronti le esecuzioni solo quando la cache è calda: legga l'output cache-hit e misuri lo step di ripristino e quello di installazione separatamente dalla build vera e propria. Veda come funziona la cache di GitHub Actions per chiavi, ambiti e cache poisoning.

Su CRACI, actions/cache funziona come oggi, e il record della build indica per ogni pacchetto se è stato ripristinato da una cache CI invece di essere scaricato.

Cache dei layer Docker

Meccanismo	Dove risiedono i layer	Che cosa sapere
BuildKit type=gha	La cache di GitHub Actions	Stesse regole di ambito e dimensione indicate sopra; richiede un builder che lo supporti
BuildKit type=registry	Un'immagine separata nel Suo registry	Funziona su qualsiasi runner e sopravvive a un cambio di provider; paga storage e trasferimento del registry
Cache dei layer locale al provider o disco persistente	Accanto ai runner del provider	Di solito la più veloce; resta indietro se lascia il provider

Una cache nel registry è l'opzione portabile (backend di cache Docker):

- uses: docker/build-push-action@v7
  with:
    push: true
    tags: ghcr.io/acme/app:latest
    cache-from: type=registry,ref=ghcr.io/acme/app:buildcache
    cache-to: type=registry,ref=ghcr.io/acme/app:buildcache,mode=max

Due job che partono nello stesso momento ripristinano la stessa cache ed entrambi costruiscono i layer mancanti. Succede su qualsiasi CI, quindi non lo interpreti come un problema del provider.

CRACI offre la cache dei layer dei container con una cache dei layer locale, una cache dei layer remota e una cache bind mount.

Secret, OIDC e credenziali cloud

GitHub archivia i Suoi secret e li consegna al runner che esegue il job, qualunque esso sia. Spostare un job su un provider significa affidare a quel provider i secret di quel job. Chieda:

• Ogni job riceve una propria macchina virtuale o un container su un host condiviso?
• La macchina viene distrutta dopo il job, e viene conservato qualcosa?
• Quali log conserva il provider? GitHub maschera i secret registrati nei log dei job e precisa che l'oscuramento automatico non è garantito per i valori trasformati; chieda anche dei log di sistema del provider.

OIDC continua a funzionare, con un limite. È GitHub a emettere il token OIDC, non il runner, quindi permissions: id-token: write funziona su qualsiasi runner. Ma il claim runner_environment del token vale github-hosted o self-hosted (riferimento OIDC di GitHub), e su un runner di terze parti vale self-hosted. Una trust policy cloud che richiede github-hosted rifiuta il job. Per esempio, un workload identity pool di Google Cloud con questa condizione sugli attributi:

# Before: only GitHub-hosted runners in the acme organization
assertion.repository_owner == 'acme' && assertion.runner_environment == 'github-hosted'

# After: drop the runner check, and narrow by repository and branch instead
assertion.repository == 'acme/app' && assertion.ref == 'refs/heads/main'

Rimuovere il controllo sul runner amplia chi può ottenere le credenziali, quindi restringa un'altra condizione nello stesso momento. Prima del cambio, cerchi runner_environment in ogni trust policy cloud e in ogni configurazione di workload identity.

Push delle immagini: GITHUB_TOKEN con packages: write esegue il push su GitHub Container Registry da qualsiasi runner, e i login ai registry che usano secret archiviati funzionano senza modifiche.

Su CRACI, la GitHub App legge il Suo codice e le Sue esecuzioni Actions e gestisce i runner che registra per la Sua organizzazione. Ogni job viene eseguito nella propria macchina virtuale isolata e CRACI non archivia il Suo codice sorgente.

Identità di rete: allowlist IP ed egress

Il nuovo runner esce da nuovi indirizzi IP. Elenchi tutto ciò che filtra per indirizzo di origine:

• allowlist di database e di repository di artefatti;
• API SaaS con restrizioni IP;
• server SFTP dei partner e servizi interni dietro un firewall.

Le opzioni sono gli indirizzi IP di egress statici o stabili del provider, oppure un proxy che controlla Lei. È anche il momento di decidere che cosa i job possono raggiungere: una policy di egress sul runner impedisce a una dipendenza compromessa di inviare i secret a un host di cui la build non ha mai avuto bisogno. Veda la policy di egress per GitHub Actions.

CRACI offre un intervallo di IP di egress stabile e una policy di egress, default deny o allow, che viene convalidata prima dell'avvio del job e opera in modalità fail-closed. Senza un input network, il template predefinito consente le altre connessioni in uscita, quindi il controllo dell'egress è qualcosa che configura Lei.

Flotte miste: spostare Linux, lasciare macOS e iOS dove sono

Il runner si sceglie per job, quindi un workflow può eseguire i suoi job Linux su un provider e i suoi job macOS sui runner ospitati da GitHub. Gli artefatti caricati con actions/upload-artifact sono archiviati da GitHub, quindi un job su un runner può passare file a un job su un altro.

jobs:
  backend:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew test

  android:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v7
        with:
          name: android
          path: app/build/outputs/apk/release/

  ios:
    # Signing and the iOS build stay on GitHub-hosted macOS
    runs-on: macos-latest
    needs: backend
    steps:
      - uses: actions/checkout@v7
      - run: xcodebuild -scheme App -configuration Release archive

I job rimasti su GitHub continuano a consumare l'utilizzo incluso nel Suo piano e oltre quello sono fatturati da GitHub. CRACI esegue oggi Linux su x86-64 e ARM64, con Windows e macOS in roadmap, quindi una flotta mista con CRACI significa CRACI per Linux e runner ospitati da GitHub per il resto.

Fallback quando un provider non è disponibile

GitHub non prevede un fallback integrato tra etichette di runner. Se nessun runner per l'etichetta è online, il job attende e dopo 24 ore fallisce. Lo metta in conto:

• Il cambio tramite variabile descritto sopra: la reimposti su ubuntu-latest e le nuove esecuzioni vanno ai runner ospitati da GitHub.
• Un override manuale per le esecuzioni urgenti: un input workflow_dispatch, letto come runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes sui job, così un job bloccato non trattiene un deploy per ore.
• Monitoraggio del tempo in coda, così si accorge quando i job attendono più del solito.

Chieda a ogni provider se offre un fallback automatico e che cosa lo attiva. Pianifichi anche la direzione opposta: GitHub mette in coda e assegna ogni job, quindi un'interruzione di GitHub Actions ferma i job anche su ogni provider di runner.

Fatturazione: GitHub addebita ancora?

GitHub non addebita costi al minuto per i runner self-hosted, e i runner di terze parti si registrano come self-hosted, quindi i minuti che sposta non compaiono più nella fattura di GitHub (fatturazione di GitHub Actions). GitHub continua a fatturare:

• le licenze del Suo piano;
• lo storage di artefatti e cache che conserva oltre la quota inclusa;
• i job rimasti sui runner ospitati da GitHub, oltre l'utilizzo incluso nel Suo piano, che non viene rimborsato.

Durante il pilota paga due fatture. I provider contano i minuti di build in modo diverso: GitHub arrotonda ogni job per eccesso al minuto intero, e alcuni provider misurano al secondo. Per stimare il Suo utilizzo prima e dopo, usi il calcolatore dei costi di GitHub Actions. CRACI addebita solo i minuti di build: $0.002 per minuto vCPU ($0.004 per un runner predefinito da 2 vCPU), misurati al secondo, senza canone mensile.

Isolamento di sicurezza: che cosa chiedere a qualsiasi provider

Domanda	Perché conta
Una macchina virtuale per job, o container su un host condiviso?	Un host condiviso permette a un job compromesso di raggiungere i job vicini
La macchina viene distrutta dopo il job?	Una macchina persistente porta file, credenziali e processi nel job successivo
Dove si trova l'hardware e chi lo gestisce?	Ubicazione dei dati, giurisdizione e contratti dei Suoi clienti
Che cosa archivia il provider e per quanto tempo?	Log, cache e dati di rete possono contenere materiale sensibile
Quali certificazioni possiede?	La Sua valutazione dei fornitori lo chiederà
È possibile controllare l'egress?	Impedisce ai secret di uscire attraverso un pacchetto malevolo
Che cosa può leggere e modificare la sua GitHub App?	I permessi dell'app valgono per ogni repository su cui la installa

GitHub afferma che i runner self-hosted non dovrebbero quasi mai essere usati per i repository pubblici, perché chiunque può aprire una pull request e compromettere l'ambiente, e che i runner just-in-time eseguono al massimo un job prima di essere rimossi (riferimento di GitHub sull'uso sicuro). Una macchina virtuale nuova per ogni job risponde alla maggior parte di questa preoccupazione.

Le risposte di CRACI: ogni job viene eseguito nella propria macchina virtuale isolata su infrastruttura bare metal europea. Il sistema di gestione della sicurezza delle informazioni di CRACI Corporation Oy, per lo sviluppo e la gestione della piattaforma CRACI, è certificato ISO/IEC 27001 da Into Certification, con i dettagli nel Trust Center. CRACI archivia metadati di build, dati sui pacchetti, tracce di rete, SBOM, provenance, cache e record di audit, e mai il Suo codice sorgente. Veda che cosa può raggiungere CRACI e la sicurezza.

Provi prima su un solo repository

1. Scelga un repository con un workflow Linux rappresentativo ed eseguito spesso, non la pipeline di release.
2. Registri una baseline sui runner ospitati da GitHub: durata mediana e tempo in coda nelle ultime 30 esecuzioni, e minuti fatturati.
3. Installi la GitHub App del provider solo su quel repository.
4. Sposti un job tramite la variabile di repository, su un branch.
5. Lo esegua almeno dieci volte e scarti le prime tre come riscaldamento della cache.
6. Confronti durata, tempo in coda, percentuale di cache hit, fallimenti e costo; verifichi log, OIDC e chiamate in uscita.
7. Torni indietro cambiando la variabile e verifichi che il job ritorni sui runner ospitati da GitHub.

Metrica	Baseline sui runner ospitati da GitHub	Provider	Soglia di superamento
Durata mediana del job			Il Suo obiettivo, per esempio il 30% in meno
Tempo mediano in coda			Non peggiore della baseline
Percentuale di cache hit dopo il riscaldamento			Pari alla baseline
Esecuzioni fallite non causate dal codice			Nessuna
Costo per esecuzione			Inferiore alla baseline
OIDC, allowlist e chiamate in uscita			Tutto funziona

Misuri la velocità sul Suo workflow. Ogni provider pubblica i propri dati, e l'unico numero che decide il Suo caso è quello della Sua pipeline.

Come si inserisce CRACI

CRACI è un runner GitHub Actions. Sostituisce il runner, non GitHub Actions: un job si sposta con runs-on: craci, dimensioni e immagini si impostano con cracicorp/setup@v1 o con un runner template di organizzazione, e le esecuzioni continuano a comparire in GitHub. CRACI esegue le build circa due volte più velocemente dei runner ospitati da GitHub, grazie a hardware più veloce, tempi in coda più brevi e caching.

Il motivo per sceglierlo rispetto ad altri provider è ciò che ogni job lascia dietro di sé: una SBOM di ciò che la build ha scaricato, con uno stato di completezza, registrata sotto una policy di egress in modalità fail-closed. docs.craci.com offre anche un prompt per coding agent che propone un piano di migrazione per job per i Suoi workflow. Veda l'integrazione CI/CD.

Quando CRACI non è la risposta

• Le servono runner macOS o Windows: sono nella roadmap di CRACI.
• Usa GitHub Enterprise Server, che CRACI non supporta.
• La Sua CI è GitLab CI o Jenkins: entrambi sono in roadmap.
• I runner devono risiedere nel Suo account cloud: i runner ospitati dal cliente sono in roadmap. RunsOn e l'opzione bring-your-own-cloud di WarpBuild lo fanno già oggi; veda CRACI vs RunsOn e CRACI vs WarpBuild.
• Il Suo obiettivo principale è l'osservabilità e il debugging della CI; veda CRACI vs Avrea. Per gestire runner propri, veda runner gestiti e self-hosted a confronto.

Cambiare provider di runner: domande frequenti

Che cosa devo cambiare per usare un altro provider di runner GitHub Actions?

Installi la GitHub App del provider, poi sostituisca l'etichetta runs-on del job con quella del provider. Workflow, trigger, secret e interfaccia di GitHub restano invariati. Prima di spostare job importanti, verifichi l'immagine del runner, le cache, gli indirizzi IP in uscita, le trust policy cloud che usano OIDC, il fallback e la fatturazione.

Le cache di GitHub Actions passano al nuovo provider di runner?

Dipende da dove il provider serve la cache. Se i suoi runner usano il servizio di cache di GitHub, le voci esistenti vengono ripristinate. Se serve l'API della cache da uno storage accanto ai suoi runner, la cache di solito parte vuota e si riempie nelle prime esecuzioni. Chieda al provider quale modello usa e se le voci scritte sui suoi runner sono visibili ai runner ospitati da GitHub.

La cache dei layer Docker funziona sui runner di terze parti?

Sì, con uno di tre meccanismi: il backend type=gha di BuildKit, che usa la cache di Actions; una cache nel registry con type=registry, che funziona su qualsiasi runner; oppure una cache dei layer o un disco persistente che il provider mantiene accanto ai suoi runner.

Posso tenere le build macOS e iOS su GitHub mentre sposto i job Linux?

Sì. Il runner si sceglie per job, quindi nello stesso workflow i job Linux possono girare su un provider mentre i job macOS restano sui runner ospitati da GitHub. Li colleghi con needs: e passi i file con actions/upload-artifact e actions/download-artifact, che GitHub archivia.

Che cosa succede a un job se il runner di terze parti non è disponibile? Esiste un fallback?

GitHub non prevede un fallback integrato tra etichette di runner. Un job la cui etichetta non corrisponde a nessun runner online resta in coda e fallisce dopo 24 ore. Tenga l'etichetta in una variabile di repository o di organizzazione, così tornare indietro richiede una sola modifica, imposti timeout-minutes e chieda a ogni provider se offre un proprio fallback.

Secret e OIDC funzionano ancora sui runner di terze parti?

Sì. GitHub archivia i secret e li consegna al runner all'avvio del job, ed è GitHub a emettere il token OIDC, quindi id-token: write funziona su qualsiasi runner. Il limite: su un runner di terze parti il claim runner_environment del token vale self-hosted, quindi una trust policy cloud che richiede github-hosted rifiuta il job.

GitHub mi fattura ancora i minuti se uso un altro provider di runner?

Non per i job che sposta. I runner di terze parti si registrano presso GitHub come runner self-hosted, e GitHub indica i runner self-hosted come esenti da costi al minuto. GitHub continua a fatturare le licenze, lo storage che conserva oltre la quota inclusa e i job rimasti sui runner ospitati da GitHub. Il provider fattura i propri minuti.

Come fisso l'immagine del runner perché non cambi a mia insaputa?

ubuntu-latest cambia secondo il calendario di GitHub, e ubuntu-24.04 fissa la release del sistema operativo ma non le versioni dei pacchetti installati. Fissi ciò che conta all'interno del job: action di setup con versioni esplicite e immagini container per digest. Chieda a ogni provider che cosa permette di fissare; l'applicazione runner stessa deve aggiornarsi per continuare a funzionare con GitHub.

Come sono isolati i job tra loro su un runner di terze parti?

Dipende dal provider. Chieda se ogni job riceve una propria macchina virtuale o un container su un host condiviso, se la macchina viene distrutta dopo il job e che cosa il provider conserva in seguito. Una macchina virtuale nuova per ogni job è il più solido tra i modelli comuni, perché nulla di un job resta al successivo.

Come provo un provider di runner prima su un solo repository?

Installi la GitHub App del provider su un repository, sposti un job Linux eseguito spesso tramite una variabile di repository su un branch, lo esegua almeno dieci volte e confronti durata, tempo in coda, cache hit, fallimenti e costo con una baseline sui runner ospitati da GitHub. Per tornare indietro basta cambiare la variabile.