Economici e veloci
Runner per GitHub Actions
Illimitati, a prezzo fisso

Sì, quasi tutti. Skipbox esegue i workflow dei repository pubblici e privati di organizzazioni e account personali GitHub. La VM è Ubuntu 24.04 su x64 con Docker, git, build-essential, Node 22 e Python 3.12, e il job gira come un utente con sudo senza password, come sui runner di GitHub. L'immagine ubuntu-latest di GitHub ha più software preinstallato, quindi per altri strumenti aggiungi actions/setup-java, actions/setup-go e simili.

Con l'IA che scrive sempre più codice, la CI gira di più ogni mese, e la fatturazione al minuto cresce a ogni esecuzione. Per questo Skipbox ha scelto apposta un altro modello: noleggi al mese una VM solo per il tuo account. GitHub non fattura i minuti dei runner self-hosted, quindi per quanti job tu esegua, il prezzo resta fisso a $39 al mese per S. Fluxenic, l'azienda dietro Skipbox, usa server di provider cloud a basso costo e server propri, e li offre come VM di dimensioni utili. Skipbox fa per te la parte noiosa: registra i runner, pulisce dopo ogni job e controlla lo stato della macchina. Inoltre ricostruisce una macchina guasta e tiene aggiornata l'immagine. A pieno utilizzo, il prezzo è 1/12 di quello di GitHub e 1/8 di quello di Blacksmith.

Perché la macchina è solo del tuo account e resta accesa tra un job e l'altro. I layer Docker e le cache dei pacchetti dell'ultimo job sono ancora sul suo disco, quindi una build che li usa non deve scaricarli o ricostruirli. Un job ospitato da GitHub parte ogni volta su una VM nuova con il disco vuoto. Anche S tiene le sue cache su un disco da 80 GB tutto suo. È oltre 7 volte la cache che GitHub dà di default a un repository, e niente scade dopo 7 giorni di inutilizzo. S ha anche 4 vCPU, più dei 2 core di ubuntu-latest su un repository privato.

Anche noleggiando un VPS della stessa dimensione da un grande provider, non ottieni un runner self-hosted più economico, più veloce e meno impegnativo di Skipbox. Skipbox registra un runner nuovo per ogni job e lo rimuove dopo. Dopo ogni job cancella le credenziali del runner e conserva il checkout e l'output di build per il job successivo. Controlla lo stato della macchina, la ricostruisce quando il controllo fallisce e tiene aggiornata l'immagine. Il codice di chi non ha accesso in scrittura (come le pull request dai fork) gira su una VM usa e getta. Hai tutto questo a $39 al mese con S, cambiando una riga runs-on, senza nulla da mantenere.

Sì, sia i repository pubblici sia quelli privati. Il codice di chi non ha accesso in scrittura (come le pull request dai fork) gira su una VM nuova che legge le tue cache ma non può modificarle; la tua macchina esegue solo il codice del tuo team.

Sì. I piani costano $39, $79 o $149 al mese, con fatturazione in dollari USA mensile, oppure annuale in anticipo al prezzo di 10 mesi, e nessun costo a consumo. Un piano limita quanti job girano insieme e quanto è grande ciascuno, non i minuti: un job che non entra aspetta che uno in esecuzione finisca, e l'attesa non aggiunge nulla al conto. La pagina della tua organizzazione in Skipbox mostra quanti job sono in attesa e da quanto aspetta il più vecchio. Un job può durare fino a 6 ore.

I job simultanei si contano in job da 4 vCPU. Un piano esegue insieme job fino al suo totale di vCPU (S 4, M 8, L 16 vCPU), quindi un job da 8 vCPU conta come 2 e uno da 16 vCPU come 4. Il job singolo più grande che un piano può eseguire ha tante vCPU quante il piano: 4 su S, 8 su M, 16 su L. Aggiungi piani per eseguire più job insieme.

Ogni job S di Skipbox ha 4 vCPU e 16 GB; ubuntu-latest di GitHub su un repository privato ha 2 core e 8 GB. La tua macchina conserva anche i layer Docker e le cache dei pacchetti dell'ultimo job, quindi una build che li usa non deve scaricarli di nuovo; un job ospitato da GitHub parte ogni volta su una VM nuova. docker build e docker compose build riutilizzano i layer. Il builder predefinito di docker/setup-buildx-action parte vuoto in ogni job, quindi imposta driver: docker per usare la cache della macchina. Dopo che il tuo primo job è stato eseguito su Skipbox, la dashboard mostra il suo tempo accanto alla sua mediana su GitHub negli ultimi 30 giorni, se GitHub lo ha eseguito in quel periodo.

16 GB con il piano S, su una macchina tutta tua: 2× i 8 GB di ubuntu-latest su un repository privato, e quanto il larger runner di GitHub con 4 core. Il piano S aveva 8 GB e non bastavano per openai/codex (rust-v0.159.3): il suo cargo clippy --workspace --tests è arrivato in fondo solo spostando circa 14 GB in swap compresso. Con gli attuali 16 GB la stessa build finisce in swap per circa 20 MB. Per un job che ne richiede di più, il piano L ha 32 GB.

Solo a ciò che serve per registrare i runner e controllare i job. Su un'organizzazione, l'app Skipbox CI chiede tre autorizzazioni: Self-hosted runners (scrittura), per registrare su GitHub un runner per ogni job e rimuoverlo alla fine del job; Actions (lettura e scrittura), per vedere quali job sono in attesa, controllarne lo stato, leggere quanto sono durati i tuoi job negli ultimi 30 giorni per il tuo preventivo e rieseguire un job la cui macchina Skipbox si è fermata a metà; e Metadata (lettura). L'app Skipbox CI non modifica né fa push dei tuoi workflow, e non può leggere il tuo codice: ogni job fa da sé il checkout del codice, sulla VM su cui gira. Su un account personale, GitHub registra un runner per un repository solo con l'autorizzazione Administration, che copre anche le impostazioni del repository, i collaboratori e le deploy key. Skipbox (personal) la chiede e la usa solo per registrare e rimuovere i runner. C'è un'unica eccezione, e solo se la installi: il pulsante “Apri una pull request” della dashboard usa un'app separata, Skipbox Migrate, che installi solo sui repository che scegli. Lì chiede l'accesso in scrittura a Contents, Workflows e Pull requests, fa push di un branch (skipbox/run-ci-on-skipbox) che cambia solo le righe runs-on e apre una pull request da quel branch. Non fa mai merge e non tocca mai il tuo branch predefinito. Quando accedi, Skipbox legge anche il tuo indirizzo email, per gli avvisi sulla prova e sulla fatturazione. Come su qualsiasi runner, la VM di un job contiene i secret del workflow e il token di GitHub per quel job, quindi il codice eseguito dal job può leggerli.

Sulla macchina della tua organizzazione: una VM della dimensione del tuo piano (anche durante la prova), più una per ogni piano aggiuntivo. Nessun'altra organizzazione la usa. Resta accesa tra un job e l'altro, quindi le immagini Docker, le cache, il checkout e il suo output di build (target/ di Cargo e, con turbo 2, la cache di Turborepo) restano per i job successivi. Gira su server che Fluxenic, l'azienda dietro Skipbox, noleggia da provider cloud o gestisce in proprio. L'informativa sulla privacy elenca ogni provider e paese. Dopo ogni job vengono cancellate le credenziali del runner, le credenziali git nel checkout e i file di credenziali più comuni. I job oltre le tue macchine, il codice di chi non ha accesso in scrittura (come le pull request dai fork) e tutti i job con “VM nuova per ogni job” attiva girano su una VM nuova, eliminata insieme al suo disco alla fine del job. Un job ancora in esecuzione dopo 6 ore viene fermato. Nessuno può connettersi dall'esterno via internet. La posta in uscita (porta TCP 25) è bloccata. Il resto di internet è accessibile, come sui runner ospitati da GitHub. Il traffico non si paga.

Sì. Premi “Ripristina macchina” in Piani e fatturazione, quando vuoi. Attiva lì “VM nuova per ogni job”, e ogni job girerà su una VM nuova.

Puoi disdire quando vuoi; il piano resta attivo fino alla fine del mese, o dell'anno, pagato. Se su Skipbox i tuoi job non sono più veloci di quanto lo erano su GitHub, ti restituiamo tutto quello che hai pagato, sia sui piani mensili sia su quelli annuali: chiedilo dalla pagina Piani e fatturazione del tuo account entro 30 giorni dal primo pagamento. Skipbox prende il tempo mediano di ogni job su Skipbox e su GitHub (nei 30 giorni prima dell'installazione di Skipbox), pesa ogni job in base a quante volte è stato eseguito su GitHub e confronta i due totali; un job conta quando è stato eseguito almeno 3 volte su ciascuno, e se non c'è nessun job da confrontare non c'è nulla da rimborsare. Se il primo job che esegui dopo l'abbonamento non parte entro 10 minuti, senza contare il tempo in cui aspetta dietro ai tuoi altri job, ti rimborsiamo automaticamente l'intero pagamento e chiudiamo il piano. Negli altri casi un mese o un anno pagato non viene rimborsato, salvo i casi elencati nei Termini.

Non viene addebitato nulla: la prova non richiede una carta. Inizia al tuo primo job su Skipbox, non quando accedi o installi l'app, ed esegue un job 4 vCPU · 16 GB alla volta per 7 giorni o 3000 minuti, a seconda di cosa arriva prima. Ogni account ha diritto a 1 prova, e ogni persona a 1. Quando finisce, i nuovi job aspettano su GitHub finché non scegli un piano.

Cambia runs-on in skipbox per passare a Skipbox, e di nuovo in ubuntu-latest per tornare indietro. Accedi con GitHub, installa l'app Skipbox CI sulla tua organizzazione o Skipbox (personal) sul tuo account personale, cambia la riga runs-on del job in skipbox e fai commit; per una VM più grande, sui piani che la includono, usa skipbox-8x16 o skipbox-16x32. Per tornare indietro, riporta runs-on: skipbox a runs-on: ubuntu-latest. Nient'altro è cambiato nel tuo repository.