Hoeveel dedicated vCPU heeft een GitLab Runner VPS nodig?

Hoeveel CI-jobs kan één VPS tegelijk draaien?

Eén CI-job heeft twee dedicated vCPU nodig en het RAM dat daarbij hoort; de concurrent-instelling van de runner bepaalt hoeveel van zulke jobs de VPS delen. In config.toml begrenst concurrent de jobs over alle geregistreerde runners, en limit begrenst ze voor één geregistreerde runner (0, de standaard, betekent geen limiet). GitLab's requirements-pagina noemt de drie inputs om op te dimensioneren: de CPU-belasting van de jobs, hun geheugengebruik en hoeveel er gelijktijdig draaien.

Hoe verhouden GitLab's gehoste runner-formaten zich tot een VPS?

GitLab's gehoste Linux-runners geven 4 GB RAM per vCPU; Cobaltfell-plannen geven 2 GB per vCPU. De vCPU-aantallen komen één op één overeen, waardoor de tabel een directe manier is om een maat te kiezen voor pipelines die al op GitLab.com draaien. Jobs die het meeste geheugen van hun huidige machine gebruiken, hebben het Cobaltfell-plan één maat groter nodig, of minder jobs tegelijk.

Volgens Cobaltfell's onderzoek van 2 november 2026 kostte één dedicated vCPU op een processor uit 2022 of later een mediaan van $8.20 per maand bij hosts die crypto aannemen zonder ID-check, dus elke parallelle CI-job van twee vCPU kost ongeveer het dubbele daarvan.

Elke host en prijs achter die mediaan staat in wat een dedicated CPU VPS per core kost in november 2026.

Waarom maken dedicated cores uit voor CI- en compileerjobs?

Een build houdt de CPU minutenlang op volle belasting, precies het patroon dat gedeelde VPS-plannen juist begrenzen. Twee hosts in hetzelfde onderzoek zetten het in hun regels: de voorwaarden van Spartan Host verbieden meer dan 50% van de toegewezen cores langer dan een uur te gebruiken, en het fair-use-beleid van Advin Servers begrenst CPU-gebruik op 75%.

Op een gedeelde vCPU komt de kost ook terug als steal time. Een pipeline die op een rustige nacht snel is, rekt uit tijdens piekuren, en job-timeouts vuren om redenen die niets met de code te maken hebben; wat CPU steal time is en hoe je het op een VPS controleert laat zien hoe je het leest.

Bij Cobaltfell: Volledige belasting is toegestaan zolang je werk het nodig heeft: geen CPU-credits, geen burst-venster en geen throttling na een paar minuten op 100%. Een vCPU is één hardwarethread van de hostprocessor. Die van jou zijn één op één vastgezet aan je VPS en worden nooit aan een andere klant uitgeleend, en de twee threads van een fysieke core blijven bij elkaar, dus elke 2 vCPU vormen één hele core die geen buur deelt. Zonder buur op de threads duurt een cache-warme pipeline ongeveer even lang bij elke run, dus een trage job wijst naar de code. Hoe de vCPU-tot-core-regel werkt, staat uitgelegd in is een dedicated vCPU een core of een thread.

Hoe voorkom ik dat parallelle builds om dezelfde vCPU vechten?

Geef elke job een vast deel van de VPS en geef hetzelfde aantal door aan de build-tool. Build-tools verschillen van mening over standaarden. GNU make draait één recipe tegelijk tenzij je -j meegeeft. Cargo draait zoveel jobs als er logische CPU's zijn. Ninja draait parallel op basis van het CPU-aantal zonder dat je erom vraagt. Vier zulke builds op Fell 8 zouden elk acht compilers starten: 32 processen voor 8 threads en 16 GB RAM.

Met de Docker executor draait elke job in zijn eigen container, en [runners.docker] neemt een cpus- en een memory-limiet voor die container. Stel beide in en stem dan de parallelliteit binnen de job af:

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

Wat heeft het compileren van Rust of C++ nodig op een VPS?

Compiles hebben threads en geheugen in gelijke tred nodig: elk parallel compilerproces en elke link-stap neemt zijn eigen deel RAM. Grote C++ translation units en Rust crates met veel generics zijn de gebruikelijke geheugenpieken, en de laatste link van een grote binary kan meer nodig hebben dan welke losse compile dan ook.

Een build die wordt gestopt wegens geheugengebrek heeft een lagere -j of CARGO_BUILD_JOBS nodig, niet meer vCPU: minder jobs ronden af, meer jobs crashen. Houd build-caches op de eigen schijf van de VPS (NVMe-opslag op elk plan) en ruim oude images op met docker image prune, want een drukke runner vult een schijf sneller dan zijn pipelines suggereren.

Een monorepo die tientallen gigabytes RAM per build nodig heeft, is bare-metal-terrein, wat Cobaltfell niet verkoopt. Test-suites met een database erachter hebben hun eigen dimensioneringsregels, behandeld in hoeveel CPU en RAM PostgreSQL nodig heeft op een VPS.

Welke executor moet een runner op een VPS gebruiken?

De Docker executor is de juiste standaard: GitLab's executor-gids zegt dat hij elke build een schone, geïsoleerde omgeving geeft, terwijl de Shell executor noch een schone omgeving per build noch bescherming van het bestandssysteem van de runner biedt. De Shell-, SSH- en VirtualBox-executors zitten in maintenance mode.

Wie een job kan starten, maakt evenveel uit: een merge request van een fork draait zijn eigen code op de VPS. GitHub's security-gids zegt dat self-hosted runners bijna nooit gebruikt zouden moeten worden voor publieke repositories, en dezelfde redenering geldt voor elk CI-systeem dat niet-vertrouwde pull requests draait.

Forgejo, Woodpecker, Jenkins en GitHub Actions-agents dimensioneren hetzelfde: tel overlappende jobs en geef elk vaste threads en geheugen. Planprijzen per maat staan onder wat een dedicated-core VPS kost.