GitLab CI/CD Self-Hosted vs GitHub Actions — Pipeline che Controlli Davvero e Costi che Vedi

Se hai un team di sviluppo e usi GitHub Actions, conosci già il problema: il piano gratuito ti dà 2.000 minuti al mese, ma quando il progetto cresce e i runner si accumulano, il conto sale. Oppure lavori su repository privati e vuoi evitare di esporre il tuo codice a server di terze parti. Ecco perché sempre più team — e noi per primi — guardano a GitLab CI/CD in modalità self-hosted. Non perché sia l’unica strada, ma perché ti dà il controllo completo della pipeline, dei runner e dei costi. In questa guida confrontiamo le due piattaforme su ciò che conta davvero per un’azienda o un team di sviluppo: prezzo, flessibilità, sicurezza e gestione operativa. Noi di Meteora Web lo facciamo su base quotidiana e abbiamo scelto GitLab per alcuni clienti proprio per queste ragioni.

Perché scegliere GitLab CI/CD self-hosted rispetto a GitHub Actions?

GitHub Actions è un prodotto fantastico per iniziare. La configurazione è semplice, l’integrazione con il repository è nativa e la community di azioni pre-costruite è enorme. Ma ha un limite strutturale: il codice e i runner vivono nei data center di Microsoft. Per progetti interni, dati sensibili o compliance GDPR, questa è una variabile da tenere d’occhio. GitLab CI/CD self-hosted ti permette di installare l’intera piattaforma sul tuo server — o su un VPS che controlli — e configurare runner fisici o virtuali che girano dentro la tua rete. Il risultato? I dati non lasciano mai il tuo perimetro, i tempi di esecuzione dipendono dalla tua potenza di calcolo e nessun limite di minuti mensili. Noi lo abbiamo usato per un cliente bancario che non poteva assolutamente inviare codice sorgente a terze parti. Con GitLab self-hosted abbiamo risolto senza compromessi.

Il divario di controllo operativo

Con GitHub Actions sei in un ambiente multi-tenant. I runner di GitHub sono condivisi (a meno di non pagare per runner privati). Se un altro inquilino satura la CPU sul tuo stesso nodo, la tua pipeline rallenta. Con GitLab self-hosted, il runner è tuo. Puoi installarlo su una macchina dedicata, su un cluster Kubernetes, o addirittura su un Raspberry Pi per test leggeri. Gestisci tu gli aggiornamenti, la sicurezza e la capacità. In un progetto che richiede build pesanti (es. compilazione di app iOS o rendering di report complessi), questa differenza si sente in ogni pipeline.

Quanto costa gestire un runner self-hosted rispetto a GitHub Actions?

Qui entriamo nel nostro territorio preferito: i numeri. GitHub Actions ha un tier gratuito generoso (2.000 minuti/mese per account privato, 3.000 minuti/mese per organizzazioni con GitHub Free). Superato il limite, si paga: $0.008/minuto per Linux, $0.016 per Windows, $0.008 per macOS su runner standard. Un progetto con 10.000 minuti di build mensili su Linux costa circa $80/mese. Se aggiungi runner macOS per build iOS, il costo triplica. GitLab CI/CD self-hosted ha un modello diverso. La versione Community Edition (CE) è completamente gratuita, senza limiti di minuti o utenti. Paghi solo l’infrastruttura: il server che ospita GitLab (es. un VPS da €15/mese) e i runner (es. un server dedicato da €30/mese o un’istanza Kubernetes con nodi spot). Totale: circa €45-60/mese per controllo totale, nessun sovrapprezzo per macOS (se usi macchine virtuali Apple su cloud dedicato). In uno scenario di medio carico, il self-hosted è più economico e prevedibile. Attenzione: devi sommare il tempo di manutenzione — aggiornamenti di GitLab, backup, monitoraggio — ma se hai già un sysadmin in team, è un costo irrisorio rispetto al risparmio.

I costi nascosti di GitHub Actions

Oltre ai minuti di build, GitHub Actions ha un costo per lo storage degli artefatti (pacchetti, log, cache). Il piano gratuito include 500 MB. Superata la soglia, si paga $0.10/GB al mese per gli artefatti e $0.25/GB per i pacchetti. Se il tuo team produce decine di build al giorno con artefatti grandi (es. binari compilati, immagini Docker), il costo si accumula rapidamente. Con GitLab self-hosted, lo storage è sul tuo server: paghi una tantum per il disco, senza canoni mensili. Noi abbiamo visto clienti passare da $200/mese di GitHub Actions a €80/mese con GitLab CE su un VPS Hetzner.

Come configurare un pipeline CI/CD in GitLab self-hosted passo per passo?

Configurare GitLab CI/CD è più complesso di GitHub Actions perché hai più libertà. Ma con la giusta checklist, diventa naturale. Partiamo dall’assunto che hai già installato GitLab CE (o EE) su un server con Ubuntu 22.04. Se non l’hai fatto, la guida ufficiale di installazione su gitlab.com è il punto di partenza. Una volta che GitLab è raggiungibile via HTTPS, crea un progetto e aggiungi un file .gitlab-ci.yml nella root.

stages:
  - build
  - test
  - deploy

variables:
  DOCKER_IMAGE: "nostro-app:${CI_COMMIT_SHORT_SHA}"

build:
  stage: build
  image: docker:20.10.16
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  only:
    - main

test:
  stage: test
  image: php:8.2-cli
  script:
    - composer install
    - php vendor/bin/phpunit
  only:
    - main

deploy:
  stage: deploy
  image: alpine:latest
  script:
    - apk add --no-cache rsync openssh
    - rsync -avz --delete build/ user@server:/var/www/app/
  only:
    - main
  when: manual

Questo esempio esegue build Docker, test PHP e deploy manuale su server remoto. La differenza chiave rispetto a GitHub Actions: qui ogni job specifica esplicitamente l’immagine Docker in cui gira, e i servizi (come Docker-in-Docker) sono configurati a livello di job. Inoltre, il runner deve essere registrato con token di accesso. Per registrare un runner self-hosted:

# Su macchina runner
sudo gitlab-runner register \
  --url https://tuo-gitlab.azienda.it \
  --registration-token $TOKEN \
  --executor docker \
  --description "Runner Docker su VPS" \
  --docker-image alpine:latest \
  --docker-privileged

Il token lo trovi nelle impostazioni del progetto: Settings → CI/CD → Runners. Una volta registrato, il runner compare nella lista dei runner attivi del progetto. Da quel momento, ogni push avvia automaticamente la pipeline.

Differenze pratiche nella sintassi

GitLab CI/CD usa stages esplicite (non il concetto di “job dipendente da” di GitHub Actions). I job in uno stesso stage eseguono in parallelo; quelli in stage successivi attendono il completamento. Le variabili predefinite come $CI_COMMIT_SHORT_SHA sostituiscono ${{ github.sha }}. Per chi arriva da GitHub Actions, il passaggio richiede un paio di ore di adattamento, ma poi risulta più logico e deterministico.

Quali sono i limiti di GitLab CI/CD rispetto a GitHub Actions?

Non è tutto oro. GitHub Actions ha un ecosistema di azioni enormemente più ricco: migliaia di azioni pubblicate nel Marketplace, molte manutenute da team dedicati (es. azioni per deploy su AWS, Firebase, Azure). GitLab ha un concetto simile (componenti CI/CD) ma il catalogo è molto più piccolo. Inoltre, la documentazione di GitHub Actions è più lineare per i principianti. GitLab CI/CD ha una curva di apprendimento più ripida e alcune configurazioni (es. pipeline multi-progetto o inclusione di file esterni) possono diventare complesse. Un altro aspetto: il supporto per ambienti paralleli con matrice. GitHub Actions permette di definire una matrice (matrix:), mentre GitLab richiede l’uso di parallel: con sintassi diversa. Non è un limite insormontabile, ma è una differenza.

La questione del debug

Quando una pipeline fallisce, su GitHub Actions puoi esplorare i log direttamente nell’interfaccia, e se hai configurato debug logging (attivabile con ACTIONS_STEP_DEBUG=true), ottieni output dettagliato. Su GitLab self-hosted, i log sono altrettanto accessibili, ma se il runner è lento o la connessione cade, l’esperienza può essere meno fluida. Inoltre, gli artefatti in GitLab si conservano per default 30 giorni (configurabile), mentre su GitHub Actions il periodo è di 90 giorni. Piccoli dettagli che fanno la differenza in un flusso di lavoro quotidiano.

Cosa fare adesso per migrare a GitLab CI/CD self-hosted

1. Installa GitLab CE su un VPS o server on-premises usando Docker o Omnibus. Segui la guida ufficiale e configura HTTPS con Let’s Encrypt.
2. Configura un runner — anche su un singolo VPS con Docker executor. Registra il runner nel tuo progetto o a livello globale (Admin Area → Runners).
3. Converti i tuoi workflow di GitHub Actions in file .gitlab-ci.yml. Mappa gli stages, le variabili e gli step uno a uno. Usa image: per ogni job e services: per i servizi esterni (es. database di test).
4. Testa una pipeline su un ramo feature prima di migrare il main. Verifica che i tempi di esecuzione siano accettabili e che gli artefatti vengano conservati correttamente.
5. Pianifica il backup del server GitLab (database e file repository) e del runner. Imposta un cron per backup giornalieri su storage esterno. Non dimenticare i certificati SSL.

Noi, di Meteora Web, abbiamo aiutato diversi team a fare questo passaggio. Se vuoi approfondire il contesto DevOps più ampio, leggi il nostro Pillar DevOps e CI/CD — Pipeline automatizzate e deploy senza dolore. Lì trovi anche collegamenti ad articoli su log analysis e incident response, utili per completare la sicurezza della tua pipeline.