Quante vCPU dedicate servono per un VPS per GitLab Runner?

Quanti job CI può eseguire contemporaneamente un solo VPS?

Un job CI richiede due vCPU dedicati e la RAM che li accompagna; l'impostazione concurrent del runner decide quanti di questi job condividono il VPS. In config.toml, concurrent limita i job su tutti i runner registrati, mentre limit li limita per un singolo runner registrato (0, il valore predefinito, significa nessun limite). La pagina dei requisiti di GitLab indica tre input su cui dimensionare: il carico CPU dei job, il loro uso di memoria e quanti ne girano in contemporanea.

Come si confrontano le dimensioni dei runner ospitati di GitLab con un VPS?

I runner Linux ospitati di GitLab danno 4 GB di RAM per vCPU; i piani Cobaltfell danno 2 GB per vCPU. I conteggi di vCPU corrispondono uno a uno, il che rende la tabella un modo diretto per scegliere una dimensione per le pipeline che già girano su GitLab.com. I job che usano la maggior parte della memoria della loro macchina attuale richiedono il piano Cobaltfell di una dimensione superiore, oppure meno job insieme.

Secondo l'indagine di Cobaltfell del 2 novembre 2026, un vCPU dedicato su un processore del 2022 o successivo costava una mediana di $8.20 al mese presso host che accettano criptovalute senza controllo d'identità, quindi ogni job CI parallelo da due vCPU costa circa il doppio.

Ogni host e prezzo dietro quella mediana è in quanto costa un VPS con CPU dedicata per core a novembre 2026.

Perché i core dedicati contano per i job CI e di compilazione?

Una build tiene la CPU a pieno carico per minuti interi, esattamente il pattern che i piani VPS condivisi sono pensati per limitare. Due host nella stessa indagine lo mettono nelle loro regole: i termini di Spartan Host vietano di usare oltre il 50% dei core allocati per più di un'ora, e la policy di fair use di Advin Servers limita l'uso della CPU al 75%.

Su un vCPU condiviso il costo appare anche come steal time. Una pipeline veloce in una notte tranquilla si allunga nelle ore di punta, e i timeout dei job scattano per motivi non legati al codice; cos'è lo steal time della CPU e come verificarlo su un VPS mostra come leggerlo.

Su Cobaltfell: Il carico pieno è consentito per tutto il tempo che il tuo lavoro richiede: nessun credito CPU, nessuna finestra di burst e nessun throttling dopo qualche minuto al 100%. Un vCPU è un thread hardware del processore host. I tuoi sono assegnati uno a uno al tuo VPS e non vengono mai prestati a un altro cliente, e i due thread di un core fisico restano insieme, quindi ogni 2 vCPU formano un core intero che nessun vicino condivide. Senza vicini sui thread, una pipeline con cache calda impiega circa lo stesso tempo a ogni esecuzione, quindi un job lento rimanda al codice. Come funziona la regola vCPU-core è spiegato in un vCPU dedicato è un core o un thread.

Come impedisco alle build parallele di contendersi gli stessi vCPU?

Assegna a ogni job una quota fissa del VPS e passa lo stesso numero allo strumento di build. Gli strumenti di build non concordano sui valori predefiniti. GNU make esegue una ricetta alla volta se non gli si passa -j. Cargo esegue tanti job quanti sono i CPU logici. Ninja esegue in parallelo in base al numero di CPU senza che glielo si chieda. Quattro build di questo tipo su Fell 8 avvierebbero ciascuna otto compilatori: 32 processi per 8 thread e 16 GB di RAM.

Con l'executor Docker, ogni job gira nel proprio container, e [runners.docker] accetta un limite cpus e uno memory per quel container. Imposta entrambi, poi allinea il parallelismo all'interno del job:

concurrent = 4            # jobs at once, all runners together
check_interval = 3

[[runners]]
  name = "fell-8-docker"
  url = "https://gitlab.com"
  token = "REPLACE_WITH_YOUR_RUNNER_TOKEN"
  executor = "docker"
  limit = 4
  [runners.docker]
    image = "debian:13"
    cpus = "2"             # CPUs for each job container
    memory = "3g"          # leaves room for the system and Docker

variables:
  MAKEFLAGS: "-j2"          # GNU make
  CARGO_BUILD_JOBS: "2"     # cargo (build.jobs)

build:
  script:
    - make
    - cargo build --release
    - ninja -C build -j 2

Cosa serve per compilare Rust o C++ su un VPS?

Le compilazioni richiedono thread e memoria in proporzione: ogni processo di compilazione parallelo e ogni fase di linking prende la propria quota di RAM. Le grandi unità di traduzione C++ e i crate Rust con generici pesanti sono i picchi di memoria abituali, e il link finale di un binario grande può richiedere più di qualsiasi singola compilazione.

Una build uccisa per mancanza di memoria ha bisogno di un -j o CARGO_BUILD_JOBS più basso, non di più vCPU: meno job finiscono, più job vanno in crash. Tieni le cache di build sul disco del VPS stesso (Archiviazione NVMe su ogni piano) e fai pulizia delle vecchie immagini con docker image prune, perché un runner molto attivo riempie un disco più in fretta di quanto suggeriscano le sue pipeline.

Un monorepo che richiede decine di gigabyte di RAM per build è territorio da bare-metal, che Cobaltfell non vende. Le suite di test basate su database hanno le proprie regole di dimensionamento, trattate in quanta CPU e RAM serve a PostgreSQL su un VPS.

Quale executor dovrebbe usare un runner su un VPS?

L'executor Docker è il default giusto: la guida agli executor di GitLab dice che offre a ogni build un ambiente pulito e isolato, mentre l'executor Shell non offre né un ambiente pulito per ogni build né la protezione del file system del runner. Gli executor Shell, SSH e VirtualBox sono in modalità manutenzione.

Conta altrettanto chi può avviare un job: una merge request da un fork esegue il proprio codice sul VPS. La guida alla sicurezza di GitHub dice che i runner self-hosted non dovrebbero quasi mai essere usati per repository pubblici, e lo stesso ragionamento vale per qualsiasi sistema CI che esegue pull request non fidate.

Forgejo, Woodpecker, Jenkins e gli agenti di GitHub Actions si dimensionano allo stesso modo: conta i job sovrapposti, assegna a ciascuno thread e memoria fissi. I prezzi dei piani per ogni dimensione sono elencati sotto quanto costa un VPS con core dedicati.