Runner GitHub Actions self-hosted, nell'UE
Gli stessi workflow, su una macchina a Praga o Covilhã che è vostra al mese anziché al minuto - con la cache di build ancora calda e un indirizzo che un firewall può davvero autorizzare.
Per chi è
Un team che guarda il contatore dei minuti
Un minuto Linux a 2 core costa 0,006 USD e uno a 16 core 0,042 USD, quindi la build a matrice che ha reso veloce la suite è la stessa cosa che ha reso interessante la fattura.
Un workflow che deve raggiungere qualcosa di privato
Il passo di deploy deve parlare con un database, un registry o un apparato che accetta solo indirizzi noti, e i runner ospitati di GitHub arrivano da un intervallo troppo ampio per autorizzarlo.
Una build che serve più di quanto l'immagine porti
Un compilatore con licenza, un emulatore, 30 GB di fixture, o semplicemente più disco di quello che il runner ospitato ha - e reinstallarlo a ogni job è gran parte della pipeline.
Che cosa cambia quando il runner è vostro
- Lo spazio di lavoro e le cache persistono tra i job, così il ripristino delle dipendenze smette di essere il passo più lungo del workflow.
- Un IPv4 statico da AS204057 che il vostro database, il vostro registry o la vostra VPN possono autorizzare per indirizzo.
- Quello che installate resta installato - toolchain, SDK con licenza, emulatori, grandi set di fixture, tutto ciò che l'immagine ospitata non porta.
- Runner registrati a livello di repository, organizzazione o azienda, con le etichette che scegliete e un workflow che li seleziona con runs-on.
- Disco e RAM che scegliete voi, invece della forma fissa in cui arriva un runner ospitato.
- Una macchina a Praga o Covilhã con contratto cipriota, che è una risposta sulla residenza dei dati e non un'impostazione di regione.
Dimensionato su quello che la pipeline fa davvero
Un servizio runner è un job alla volta, quindi qui la parallelizzazione è un conteggio di processi runner e non uno scalino di piano - diversi su un host, ciascuno nella propria cartella, è la forma normale. Dimensionate sul job più pesante e non sulla media, e lasciate margine sul disco: lo spazio di lavoro, la cache degli strumenti e i layer dei container vivono tutti lì, ed è proprio quella persistenza la ragione per il self-hosting. La metà onesta dello scambio: un host mensile fisso costa lo stesso in una settimana senza push, dove i minuti ospitati non costano nulla. Conviene appena la pipeline gira quasi tutti i giorni.
Come installare un runner GitHub Actions su un host nuovo
Linux x64, nell'ordine in cui GitHub lo documenta. Il token di registrazione viene generato per runner e scade un'ora dopo l'apertura della pagina: prendetelo per ultimo.
-
Creare un utente non privilegiato
sudo adduser --disabled-password --gecos "" runner sudo -iu runnerIl runner esegue quello che gli dice un workflow, quindi non dovrebbe essere root né condividere la home con altro. Tutto quanto segue gira come questo utente.
-
Scaricare e scompattare il runner
mkdir actions-runner && cd actions-runner curl -O -L https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-x64-2.336.0.tar.gz echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d actions-runner-linux-x64-2.336.0.tar.gz" | shasum -a 256 -c tar xzf ./actions-runner-linux-x64-2.336.0.tar.gzQuella versione e quel checksum sono quelli pubblicati con la release v2.336.0. Controllate se ne esiste una più recente sulla pagina delle release prima di copiare questo: il runner poi si aggiorna da solo, ma il primo download tocca a voi verificarlo.
-
Configurarlo su un repository o un'organizzazione
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token AXXXXXXXXXXXXXXXXXXXXXXXXX --labels self-hosted,linux,x64,euPrendete il token da Settings, poi Actions, poi Runners, poi New self-hosted runner - è a tempo e scade un'ora dopo l'emissione. Puntate l'URL all'organizzazione invece che al repository per condividere un runner tra più repository.
-
Farlo girare come servizio
sudo ./svc.sh install runner sudo ./svc.sh start sudo ./svc.sh statussvc.sh riceve l'utente con cui il servizio deve girare, ed è per questo che l'utente runner è stato creato prima. Usate invece ./run.sh se volete solo vedere un job atterrare prima di impegnarvi con un servizio.
-
Impedire a needrestart di uccidere job a metà
echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.confSu Debian e Ubuntu, needrestart riavvia i servizi le cui librerie sono state aggiornate - compreso un runner nel mezzo di un job. GitHub documenta esattamente questo file come il modo per escluderlo.
-
Puntargli contro un workflow
name: smoke on: [push] jobs: build: runs-on: [self-hosted, linux, x64, eu] steps: - uses: actions/checkout@v6 - run: cat /etc/os-releaseruns-on corrisponde a ogni etichetta dell'elenco, quindi un job che ne chiede quattro atterra solo su un runner che le porta tutte e quattro. Se resta in coda, manca un'etichetta - e un job in coda da più di 24 ore fallisce.
Verificato sulla documentazione ufficiale il 2026-08-15 — leggi la fonte
Cosa non siamo
- Non siamo GitHub. GitHub, GitHub Actions e il runner sono loro, e nulla in questa pagina è approvato da loro. Vendiamo la macchina su cui gira il runner.
- Questo non sostituisce il vostro piano GitHub. I runner self-hosted non costano minuti di Actions, ed è il punto, ma licenze, spazio e tutto il resto restano sulla loro fattura.
- Non gestiamo il runner se non lo chiedete. Lo installate voi, oppure aggiungete il nostro servizio di amministrazione e lo teniamo aggiornato, registrato e sorvegliato.
- I runner self-hosted sono documentati come poco adatti ai repository pubblici: un fork può proporre una modifica al workflow, e quel workflow modificato girerebbe sulla vostra macchina. Teneteli su repository privati se non ci avete ragionato a fondo.
- Qui non c'è un piano di controllo con autoscaling. Se volete runner creati e distrutti per job, quello è Actions Runner Controller su un cluster Kubernetes - che ospitiamo volentieri, su un'altra pagina.
Le parti che i team scoprono in ritardo
- Un servizio runner esegue un job alla volta. La parallelizzazione nasce dall'installarne diversi, ciascuno nella propria cartella con il proprio servizio, non da un'impostazione.
- Il token di registrazione scade un'ora dopo l'emissione: generatelo quando siete pronti a lanciare config.sh e non all'inizio del pomeriggio.
- Le etichette sono l'intero meccanismo di instradamento. runs-on corrisponde a ogni etichetta dell'elenco, quindi un refuso non dà errore - il job semplicemente aspetta, e fallisce dopo 24 ore in coda.
- Al runner servono lttng-ust, OpenSSL, Kerberos, zlib e libicu. Debian e Ubuntu li portano; un'immagine di container minimale spesso no.
- x64 e ARM64 sono supportati su Linux, e ARM32 solo su Linux. Debian 10 e successive e Ubuntu 20.04 e successive sono le basi documentate.
- Tutto ciò che il workflow lascia dietro di sé resta sul disco - è il vantaggio, ed è anche il motivo per cui un runner self-hosted vuole un job di pulizia pianificato e uno snapshot.
Minuti di CI ospitati contro un runner vostro
| Minuti di CI ospitati dal fornitore | Un runner su DCXV | |
|---|---|---|
| Che cosa pagate | Ogni minuto di ogni job, finché il progetto esiste | Un host mensile fisso, qualunque cosa faccia la pipeline quel mese |
| Una build che rallenta | Costa di più ogni mese in cui resta lenta | Non costa nulla in più - la macchina è già pagata |
| Cache dei layer Docker | Fredda a ogni job, se non la caricate e la riscaricate voi stessi | Calda su NVMe locale, tra i job e tra i giorni |
| Parallelizzazione | Uno scalino di piano che si aumenta | Un numero che impostate nel vostro file di configurazione |
| Dove atterra il checkout | Una flotta condivisa, spesso in una regione che non potete fissare | Una macchina a Praga o Covilhã, con contratto cipriota |
| Indirizzo in uscita | Un vasto intervallo condiviso che nulla può autorizzare | Un IPv4 statico da AS204057, vostro da autorizzare |
| Che cosa può contenere la macchina | Quello che l'immagine del runner porta per caso | Qualsiasi toolchain, licenza o set di fixture installato una volta sola |
Come si mette in moto sul vostro host
Diteci che cosa fa la pipeline
Il job più pesante che eseguite oggi, quanti ne volete in parallelo e se costruisce immagini di container. Basta questo per dimensionare un host senza tirare a indovinare.
Vi consegniamo la macchina
Praga o Covilhã, accesso root e un IPv4 statico, in meno di dieci minuti. Portate la vostra immagine se il runner è già dentro.
Seguite la procedura di questa pagina
È la sequenza del produttore, presa dalla sua documentazione attuale e non da un post di blog, e su un host pulito richiede pochi minuti.
Fate uno snapshot, poi aggiungete il secondo
Fate uno snapshot appena la prima pipeline è verde, così la macchina successiva è un ripristino e non una ricostruzione. Un pool cresce aggiungendo host, non rendendone uno enorme.
Perché sceglierci
- Strutture certificate Tier III, SLA della struttura 99,982 %
- Rete propria, AS204057, IPv4 e IPv6
- Supporto 24/7/365 con circa 10 minuti di risposta media
- Società cipriota, giurisdizione UE, conforme al GDPR dal 2007
FAQ
- Quanto costano i runner ospitati di GitHub rispetto al self-hosting?
GitHub fattura i runner Linux ospitati al minuto: 0,006 USD per 2 core, 0,012 per 4, 0,022 per 8 e 0,042 per 16, con Windows a 0,010 per 2 core e macOS a 0,062 per una macchina a 3 o 4 core. I runner self-hosted non consumano minuti di Actions. Un host qui parte da 16,49 EUR al mese, all'incirca quanto costano 2.700 minuti su un runner ospitato a 2 core - quindi il punto di pareggio è intorno alle 45 ore di build al mese
- Come configuro un runner GitHub Actions self-hosted?
Create un utente non privilegiato, scaricate l'archivio del runner per linux-x64 dalle release di actions/runner e verificatene il checksum, eseguite ./config.sh con l'URL del vostro repository o della vostra organizzazione e il token di registrazione preso da Settings, Actions, Runners, poi installatelo come servizio con sudo ./svc.sh install e avviatelo. I comandi esatti sono su questa pagina. Il token di registrazione scade un'ora dopo l'emissione
- Quanti job può eseguire un runner contemporaneamente?
Uno. Un servizio runner prende un singolo job alla volta, quindi parallelizzare significa installare più servizi runner sull'host, ciascuno nella propria cartella. Per questo il dimensionamento di questa pagina conta servizi runner e non job, e per questo una macchina a 8 vCPU regge comodamente una piccola build a matrice
- Quali sistemi operativi e architetture sono supportati?
Su Linux, Debian 10 e successive, Ubuntu 20.04 e successive, RHEL 8 e successive, CentOS 8 e successive, Fedora 29 e successive, openSUSE 15.2 e successive e i loro parenti, su x64, ARM64 e ARM32. Al runner servono inoltre lttng-ust, OpenSSL, Kerberos, zlib e libicu, che Debian e Ubuntu portano di serie
- È sicuro usare un runner self-hosted su un repository pubblico?
GitHub lo sconsiglia, e il motivo è concreto: chiunque può aprire una pull request che modifica il file del workflow, e quel workflow modificato girerebbe sulla vostra macchina. Tenete i runner self-hosted su repository privati se non avete letto bene la questione e messo un isolamento vero. Tutto ciò che un job lascia dietro persiste inoltre sul disco, vantaggio per la cache e rischio per i segreti
- Un runner può servire più repository?
Sì. Registratelo a livello di organizzazione invece che di repository e ogni repository dell'organizzazione potrà selezionarlo, usando le etichette in runs-on per instradare il lavoro. Un job che chiede un'etichetta che nessun runner porta semplicemente aspetta, e fallisce dopo 24 ore in coda - ecco l'aspetto di un refuso in runs-on
Se hai bisogno di assistenza o hai domande aggiuntive, contatta i manager o scrivi al team di supporto a support@dcxv.com
Pronto per iniziare?
Fatturazione mensile, nessun costo di attivazione, nessun vincolo