# GitHub Actions lento? Perché, e come non ripartire da zero

> GitHub Actions è lento perché ogni job parte su una VM vuota e scarica i tool, reinstalla le dipendenze e ricostruisce le immagini Docker prima del primo test. Skipbox conserva tutto sulla tua macchina tra un job e l'altro, a un prezzo fisso di $39 al mese con minuti illimitati: con 20.000 minuti su 4 vCPU sono $183 al mese in meno rispetto a GitHub.

Gran parte di un job lento di GitHub Actions avviene prima che parta il primo test. Configurare Node, scaricare le dipendenze, costruire l'immagine Docker: gli stessi minuti, a ogni push, mentre qualcuno del tuo team aspetta la spunta verde. Con la fatturazione al minuto, paghi anche quei minuti.

Skipbox è un runner GitHub Actions che conserva la sua macchina tra un job e l'altro, quindi quello che un job ha installato è ancora sul disco per il successivo. Cambia una riga, `runs-on: skipbox`, e il job gira sulla tua macchina a un prezzo fisso di $39 al mese con minuti illimitati.

- Dipendenze, layer Docker e tool restano sul disco, quindi i job saltano download e ricostruzioni
- Almeno 7× lo spazio cache di GitHub, senza scadenza dopo 7 giorni e senza chiavi di cache da regolare
- 20.000 minuti al mese su 4 vCPU: $222 su GitHub, $39 su Skipbox

**GitHub Actions a prezzo fisso, minuti illimitati** Skipbox esegue i tuoi job di GitHub Actions su una macchina dedicata tutta tua: $39 al mese, per quanti minuti tu esegua. I layer Docker e le cache delle dipendenze restano tra un job e l'altro, così il job successivo parte subito.

Un runner da 4 vCPU, 20.000 minuti al mese: GitHub $222 → Skipbox $39. Risparmi $183 ogni mese.

Per passare basta una riga: `runs-on: skipbox`.

[Inizia la prova gratuita di 7 giorni](https://app.skipbox.dev/sign-in?ref=g-github-actions-slow-it)

## Ogni job parte da una VM vuota

Un runner ospitato da GitHub è una macchina virtuale nuova per ogni job. Su di essa non c'è niente di quello che l'ultimo job ha scaricato o costruito, quindi ogni job ricostruisce lo stesso stato:

| Step | Runner ospitato da GitHub | Skipbox |
|---|---|---|
| Configurare Node, Python, Java | Scarica la toolchain | La trova nella tool cache dell'ultimo job |
| Installare le dipendenze | Scarica e scompatta l'archivio della cache; se manca, tutto il download dal registry | Legge dal disco la cache del package manager |
| Costruire l'immagine Docker | Parte senza layer e ricostruisce ogni step | Riusa i layer dell'ultima build |
| Eseguire i test | 2 CPU con `ubuntu-latest` in un repository privato | Da 4 vCPU in su |

Le prime tre righe non producono niente di nuovo. Riportano la macchina dov'era ieri.

La cache di GitHub attenua il problema senza cambiarlo. Contiene 10 GB per repository, elimina le voci che nessun job ha letto per 7 giorni, e un nuovo branch di feature non può leggere la cache di un altro branch di feature. Anche un hit scarica e scompatta un archivio a ogni esecuzione.

## Quanto ti costa l'attesa

Supponi che la preparazione occupi 3 minuti di ogni job e che il tuo team esegua 100 job al giorno. Sono 300 minuti al giorno di tempo del runner spesi a rimettere a posto la macchina, e ogni pull request aspetta la sua parte. Le review iniziano più tardi, i merge arrivano più tardi, e gli sviluppatori passano ad altro mentre aspettano.

Con la fatturazione al minuto, quei minuti finiscono in fattura. Un runner a 4 vCPU, per minuti al mese:

| Minuti al mese (4 vCPU) | GitHub | Skipbox S | Risparmi ogni mese |
|---|---|---|---|
| 10.000 | $102 | $39 | **$63** |
| 20.000 | $222 | $39 | **$183** |
| 30.000 | $342 | $39 | **$303** |

Gli importi di GitHub sono il conto al netto dell'utilizzo incluso in GitHub Team. Inserisci i tuoi minuti nel [calcolatore della home](https://skipbox.dev/?ref=g-github-actions-slow-it#cost); non serve accedere.

E il numero di esecuzioni può solo salire:

- **Agenti di coding IA.** Ogni push di un agente avvia la CI. L'attesa e il conto crescono con i push, non con il numero di persone.
- **Più test.** Una suite E2E o una matrice ripete la preparazione in ogni job che aggiunge.
- **Budget.** Limita il conto con un budget di GitHub e i job smettono di partire a metà mese, il che blocca i merge.

## Velocizzarlo da solo è un progetto

Restare sui runner ospitati da GitHub e renderli veloci significa farsi carico di lavori come questi:

- Basare le chiavi della cache sugli hash dei lockfile e regolare `restore-keys` finché non fanno hit
- Aggiungere buildx ed esportare la cache di Docker con `cache-to`, dentro gli stessi 10 GB
- Suddividere i test in shard, dove ogni shard ripete la preparazione e i minuti fatturati salgono
- Oppure gestire un tuo runner self-hosted: preparare le macchine, aggiornare il sistema operativo, fare pulizia tra un job e l'altro e sistemarlo quando cade

Ognuno di questi aggira una macchina che dimentica tutto. Skipbox conserva la macchina, quindi non serve niente di tutto ciò.

## Cosa cambia con Skipbox

**La preparazione resta sul disco.** I tuoi job girano sulla macchina del tuo account, che resta tra un job e l'altro. Immagini Docker, layer e cache di build; le cache dei pacchetti di npm, pip, Gradle e altri; i tool che installano `setup-node` e simili. Almeno 7× lo spazio cache di GitHub, senza scadenza dopo 7 giorni e senza regole sui branch.

**Macchine più grandi a prezzo fisso.** Compilatori e test runner avviano un worker per core, quindi più core accorciano gli step limitati dalla CPU.

| Piano | Macchina | Prezzo |
|---|---|---|
| S | 4 vCPU · 16 GB | $39 al mese |
| M | 8 vCPU · 16 GB | $79 al mese |
| L | 16 vCPU · 32 GB | $149 al mese |

I minuti sono illimitati con ogni piano. I job su Skipbox non usano minuti GitHub, quindi un budget di GitHub non li ferma mai.

**Nessuna macchina da curare.** Skipbox prepara la macchina, aggiorna il sistema operativo e i tool, fa pulizia dopo ogni job, esegue un controllo di integrità e ricostruisce una macchina che non lo supera.

## Passare a Skipbox è una riga

```yaml
jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
```

1. Accedi a Skipbox con GitHub.
2. Installa la GitHub App di Skipbox e scegli i repository.
3. Cambia `runs-on` e fai push.

Quello che il primo job installa è sul disco per il secondo.

## Sicurezza

- La macchina è solo del tuo account. Nessun job di un'altra azienda gira su di essa.
- Dopo ogni job vengono cancellati credenziali, processi e container del runner. Dal 13 novembre 2026 il tuo checkout e il suo output di build (il `target/` di Cargo) restano sulla tua macchina per i job successivi; “VM nuova per ogni job” dà a ogni job una macchina nuova.
- Il codice di chi non ha accesso in scrittura (come le pull request dai fork) gira su una macchina nuova, usa e getta.

I dettagli sono in [come vengono isolati i job](https://docs.skipbox.dev/isolation).

## Provalo sul tuo job più lento

La prova è gratuita per 7 giorni o 3000 minuti di job, quello che arriva prima, e non richiede una carta. Sposta il tuo job più lento su `runs-on: skipbox`, eseguilo due volte di fila e metti i tempi degli step accanto a quelli di GitHub.

## Domande frequenti

### Perché GitHub Actions è così lento?

Ogni job su un runner ospitato da GitHub parte su una VM nuova senza niente dell'esecuzione precedente, quindi scarica i tool, reinstalla le dipendenze e ricostruisce le immagini Docker prima che partano i tuoi test. Skipbox esegue i tuoi job sulla macchina del tuo account e conserva tutto questo sul suo disco, così il job successivo riparte da dove si era fermato l'ultimo.

### Ho aggiunto actions/cache. Perché il workflow è ancora lento?

Anche un hit della cache scarica e scompatta un archivio a ogni job, perché la VM è sempre nuova. E la cache di GitHub contiene 10 GB per repository, elimina le voci non usate da 7 giorni e non si può leggere da un branch parallelo. Su Skipbox le cache dei pacchetti e i layer Docker sono già sul disco della macchina, senza chiavi da gestire.

### Come velocizzare le build Docker in GitHub Actions?

Dai alla build i layer della build precedente. Sui runner ospitati da GitHub significa esportare la cache con buildx e importarla a ogni esecuzione, dentro lo stesso limite di 10 GB. Su Skipbox le immagini e la cache di build di Docker restano sulla macchina tra un job e l'altro, quindi docker build riusa i layer da solo.

### Devo riscrivere i miei workflow per usare Skipbox?

No. Per i job Linux, cambia runs-on in skipbox. La macchina usa Ubuntu 24.04 con Docker, Node.js e Python, e step e action girano come sono.

### Posso provarlo gratis sul mio job lento?

Sì. La prova dura 7 giorni o 3000 minuti di job, quello che arriva prima, senza carta. Sposta il tuo job più lento su runs-on: skipbox, eseguilo due volte di fila e confronta i tempi degli step con quelli di GitHub.

Aggiornata il giorno 2026-11-11 · https://skipbox.dev/it/guides/github-actions-slow