Come faccio girare un runner GitHub Actions self-hosted su un VPS?

Fai il provisioning di un VPS Linux (Small — 4 vCPU / 4 GB — è il default sensato), installa il pacchetto runner da Settings → Actions → Runners del tuo repo, registralo con il token che GitHub ti dà, e avvialo come servizio. I passi completi copia-incolla sono sotto; ottieni root in circa un minuto.

Posso far girare il runner in Docker?

Sì. Fai girare l'immagine runner ufficiale (o la tua) in un container, o usala per dare a ogni job un ambiente isolato e usa-e-getta. Un piano con IP dedicato non è richiesto — il runner fa solo connessioni in uscita verso GitHub, quindi anche un piano NAT funziona.

Come tengo il runner in funzione come servizio?

Il runner viene con un helper svc.sh che installa una unit systemd: ./svc.sh install && ./svc.sh start. Poi sopravvive ai riavvii e si riavvia in caso di fallimento. La guida sotto mostra i comandi esatti.

Un runner self-hosted è più economico dei minuti ospitati da GitHub?

Per CI pesante o frequente, sì. I runner ospitati da GitHub fatturano al minuto oltre il piano gratuito; un VPS da $8/mese fa girare minuti illimitati a un prezzo fisso, e resta caldo (niente cold-start, dipendenze in cache). Un repo trafficato di solito ripaga la macchina.

Chiedete un documento o una carta di credito?

No. Registrati con un'email, paga con USDC o USDT. Niente documenti, niente carta, niente KYC — mai.

VPS per runner GitHub Actions self-hosted

Fai girare il tuo runner GitHub Actions self-hosted su un VPS — CI più veloce, niente fatturazione al minuto, controllo completo dell'ambiente di build. Pagamento in crypto, niente KYC. Da $8/mese.

I runner ospitati da GitHub sono comodi finché il conto o il tempo di attesa non iniziano a far male. Oltre il piano gratuito paghi al minuto, fai cold-start a ogni job, e riscarichi le dipendenze a ogni run. Un runner self-hosted sul tuo VPS ribalta tutti e tre: costo mensile fisso, una macchina calda con le tue cache già su disco, e un ambiente di build che controlli completamente — versioni specifiche di tool, più RAM, cache dei layer Docker che persiste davvero.

Un runner ha solo bisogno di raggiungere GitHub in uscita, quindi funziona sui nostri piani più economici, paga in crypto, e non necessita di KYC.

Cosa serve a un runner

CPU e RAM per le tue build. Small ($8/mese — 4 vCPU, 4 GB RAM, 35 GB NVMe) è il default comodo per la maggior parte della CI: build Node/Go/Rust, suite di test, build di immagini Docker. Compilazione pesante o job paralleli? Sali a Medium o a un piano Pro.
Disco NVMe per le cache. Tutto il senso del self-hosting è la persistenza — cache delle dipendenze, layer Docker, artefatti di build restano su disco tra i run. NVMe tiene veloci i ripristini.
Nessun IP dedicato richiesto. Il runner compone verso GitHub via HTTPS; nulla deve raggiungerlo in entrata. Un piano NAT (da $3/mese) basta. Prendi un IP dedicato solo se fai anche self-hosting di qualcosa che serve traffico.

Configura un runner (Ubuntu 24.04)

Crea il runner nel tuo repo (o org): Settings → Actions → Runners → New self-hosted runner → Linux. GitHub mostra un comando di download e un token di registrazione una tantum. Sul VPS:

# come utente non-root (il runner si rifiuta di girare come root)
adduser --disabled-password --gecos "" runner
su - runner

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz

# registra con l'URL + token dalla UI di GitHub
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Tienilo in funzione come servizio

Non eseguire ./run.sh in un terminale — installalo come servizio systemd così sopravvive ai riavvii:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

Il runner ora appare come Idle nella UI di GitHub e prende qualsiasi job che lo punta.

Usalo da un workflow

Punta un job al tuo runner con runs-on:

jobs:
  build:
    runs-on: self-hosted        # o una label personalizzata che imposti alla registrazione
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Job basati su Docker

Installa Docker una volta e i tuoi workflow possono costruire immagini o far girare service container, con la cache dei layer che persiste tra i run:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # lascia che il runner usi Docker senza sudo

Per isolamento usa-e-getta per-job, fai girare il runner stesso dentro un container e ricrealo a ogni run — uno schema comune per build non fidate o a matrice.

Perché EQVPS per la CI

Costo fisso, minuti illimitati. Nessun contatore al minuto — una pipeline trafficata costa quanto una inattiva.
Cache calde. Dipendenze e layer Docker restano su NVMe tra i run; le build diventano più veloci, non più lente.
Root in ~60 secondi, immagini pulite. Ubuntu, Debian e altro via cloud-init; installa esattamente la toolchain che ti serve.
Niente KYC, pagamento in crypto. Email per registrarti, USDC/USDT per pagare. Tira su runner extra per i picchi di release e cancellali dopo — il tempo pagato inutilizzato viene accreditato al tuo saldo.

Guida completa di setup passo-passo →