Combien de vCPU dédiés un VPS pour GitLab Runner nécessite-t-il ?

Combien de jobs CI un seul VPS peut-il exécuter en même temps ?

Un job CI a besoin de deux vCPU dédiés et de la RAM qui va avec ; le paramètre concurrent du runner décide combien de tels jobs partagent le VPS. Dans config.toml, concurrent plafonne les jobs sur tous les runners enregistrés, et limit les plafonne pour un runner enregistré (0, la valeur par défaut, signifie aucune limite). La page des prérequis de GitLab nomme les trois éléments pour dimensionner : la charge CPU des jobs, leur usage mémoire et le nombre qui s'exécutent en parallèle.

Comment les tailles des runners hébergés de GitLab se comparent-elles à un VPS ?

Les runners Linux hébergés de GitLab offrent 4 GB de RAM par vCPU ; les plans Cobaltfell offrent 2 GB par vCPU. Les nombres de vCPU correspondent un pour un, ce qui fait du tableau un moyen direct de choisir une taille pour des pipelines qui tournent déjà sur GitLab.com. Les jobs qui utilisent la majeure partie de la mémoire de leur machine actuelle ont besoin du plan Cobaltfell une taille au-dessus, ou de moins de jobs à la fois.

Selon l'enquête de Cobaltfell du 2 novembre 2026, un vCPU dédié sur un processeur de 2022 ou plus récent coûtait une médiane de $8.20 par mois chez des hébergeurs qui acceptent la crypto sans vérification d'identité, donc chaque job CI parallèle de deux vCPU coûte environ le double.

Chaque hébergeur et prix derrière cette médiane figure dans combien coûte un vCPU dédié de VPS par cœur en novembre 2026.

Pourquoi les cœurs dédiés comptent-ils pour les jobs CI et de compilation ?

Un build maintient le CPU à pleine charge pendant plusieurs minutes d'affilée, exactement le schéma que les plans VPS mutualisés sont conçus pour limiter. Deux hébergeurs de la même enquête l'inscrivent dans leurs règles : les conditions de Spartan Host interdisent d'utiliser plus de 50 % des cœurs alloués pendant plus d'une heure, et la politique d'usage raisonnable d'Advin Servers plafonne l'usage CPU à 75 %.

Sur un vCPU mutualisé, le coût apparaît aussi sous forme de steal time. Un pipeline rapide une nuit calme s'allonge aux heures de pointe, et les timeouts de job se déclenchent pour des raisons sans rapport avec le code ; ce qu'est le steal time CPU et comment le vérifier sur un VPS montre comment le lire.

Chez Cobaltfell : La pleine charge est autorisée aussi longtemps que votre travail l'exige : aucun crédit CPU, aucune fenêtre de burst et aucun throttling après quelques minutes à 100 %. Un vCPU correspond à un thread matériel du processeur hôte. Les vôtres sont épinglés un à un à votre VPS et ne sont jamais prêtés à un autre client, et les deux threads d'un cœur physique restent ensemble : ainsi, chaque 2 vCPU forment un cœur entier que nul voisin ne partage. Sans voisin sur les threads, un pipeline à cache chaud prend environ le même temps à chaque exécution, donc un job lent pointe vers le code. Le fonctionnement de la règle vCPU-vers-cœur est expliqué dans un vCPU dédié est-il un cœur ou un thread.

Comment empêcher des builds parallèles de se disputer le même vCPU ?

Donnez à chaque job une part fixe du VPS et passez le même nombre à l'outil de build. Les outils de build ne s'accordent pas sur les valeurs par défaut. GNU make exécute une recette à la fois sauf si on lui donne -j. Cargo exécute autant de jobs qu'il y a de CPU logiques. Ninja s'exécute en parallèle selon le nombre de CPU sans qu'on le lui demande. Quatre tels builds sur Fell 8 lanceraient chacun huit compilateurs : 32 processus pour 8 threads et 16 GB de RAM.

Avec l'executor Docker, chaque job s'exécute dans son propre conteneur, et [runners.docker] prend une limite cpus et une limite memory pour ce conteneur. Définissez les deux, puis alignez le parallélisme à l'intérieur du 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

De quoi a besoin la compilation de Rust ou C++ sur un VPS ?

Les compilations ont besoin de threads et de mémoire en phase : chaque processus de compilation parallèle et chaque étape de link prend sa propre part de RAM. Les grosses unités de traduction C++ et les crates Rust à génériques lourds sont les pics de mémoire habituels, et le link final d'un gros binaire peut demander plus que n'importe quelle compilation individuelle.

Un build tué par manque de mémoire a besoin d'un -j ou d'un CARGO_BUILD_JOBS plus bas, pas de plus de vCPU : moins de jobs finissent, plus de jobs plantent. Gardez les caches de build sur le disque propre du VPS (Stockage NVMe sur toutes les offres) et élaguez les vieilles images avec docker image prune, car un runner occupé remplit un disque plus vite que ses pipelines ne le laissent penser.

Un monorepo qui a besoin de dizaines de gigaoctets de RAM par build relève du bare-metal, que Cobaltfell ne vend pas. Les suites de tests adossées à une base de données ont leurs propres règles de dimensionnement, traitées dans de combien de CPU et de RAM PostgreSQL a besoin sur un VPS.

Quel executor un runner sur un VPS doit-il utiliser ?

L'executor Docker est le bon choix par défaut : le guide des executors de GitLab indique qu'il donne à chaque build un environnement propre et isolé, tandis que l'executor Shell n'offre ni environnement propre par build ni protection du système de fichiers du runner. Les executors Shell, SSH et VirtualBox sont en mode maintenance.

Qui peut lancer un job compte tout autant : une merge request issue d'un fork exécute son propre code sur le VPS. Le guide de sécurité de GitHub indique que les runners auto-hébergés ne devraient presque jamais être utilisés pour des dépôts publics, et le même raisonnement vaut pour tout système CI qui exécute des pull requests non fiables.

Les agents Forgejo, Woodpecker, Jenkins et GitHub Actions se dimensionnent de la même façon : comptez les jobs qui se chevauchent, donnez à chacun des threads et une mémoire fixes. Les prix des plans pour chaque taille sont listés sous combien coûte un VPS à cœurs dédiés.