How many dedicated vCPU does a GitLab Runner VPS need?

How many CI jobs can one VPS run at the same time?

One CI job needs two dedicated vCPU and the RAM that comes with them; the runner's concurrent setting decides how many such jobs share the VPS. In config.toml, concurrent caps the jobs across all registered runners, and limit caps them for one registered runner (0, the default, means no limit). GitLab's requirements page names the three inputs to size from: the CPU load of the jobs, their memory use and how many run concurrently.

How do GitLab's hosted runner sizes compare with a VPS?

GitLab's hosted Linux runners give 4 GB of RAM per vCPU; Cobaltfell plans give 2 GB per vCPU. The vCPU counts line up one for one, which makes the table a direct way to pick a size for pipelines that already run on GitLab.com. Jobs that use most of the memory of their current machine need the Cobaltfell plan one size up, or fewer jobs at once.

According to Cobaltfell's survey of 2 November 2026, one dedicated vCPU on a processor from 2022 or later cost a median $8.20 a month at hosts that take crypto without an ID check, so each parallel CI job of two vCPU costs about twice that.

Every host and price behind that median is in what a dedicated CPU VPS costs per core in November 2026.

Why do dedicated cores matter for CI and compile jobs?

A build holds the CPU at full load for minutes at a time, the exact pattern that shared VPS plans are written to limit. Two hosts in the same survey put it in their rules: Spartan Host's terms forbid using more than 50% of the allocated cores for more than an hour, and Advin Servers' fair-use policy caps CPU use at 75%.

On a shared vCPU the cost also appears as steal time. A pipeline that is quick on a quiet night stretches at peak hours, and job timeouts fire for reasons unrelated to the code; what CPU steal time is and how to check it on a VPS shows how to read it.

At Cobaltfell: Full load is allowed for as long as your work needs it: no CPU credits, no burst window and no throttling after some minutes at 100%. A vCPU is one hardware thread of the host processor. Yours are pinned one to one to your VPS and never lent to another customer, and the two threads of a physical core stay together, so every 2 vCPU make one whole core that no neighbour shares. With no neighbour on the threads, a cache-warm pipeline takes about the same time on every run, so a slow job points at the code. How the vCPU-to-core rule works is explained in is a dedicated vCPU a core or a thread.

How do I stop parallel builds from fighting over the same vCPU?

Give each job a fixed share of the VPS and pass the same number to the build tool. Build tools disagree on defaults. GNU make runs one recipe at a time unless given -j. Cargo runs as many jobs as there are logical CPUs. Ninja runs in parallel based on the CPU count without being asked. Four such builds on Fell 8 would each start eight compilers: 32 processes for 8 threads and 16 GB of RAM.

With the Docker executor, each job runs in its own container, and [runners.docker] takes a cpus and a memory limit for that container. Set both, then match the parallelism inside the 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

What does compiling Rust or C++ need on a VPS?

Compiles need threads and memory in step: every parallel compiler process and every link step takes its own share of RAM. Large C++ translation units and Rust crates with heavy generics are the usual memory peaks, and the final link of a big binary can need more than any single compile.

A build killed for lack of memory needs a lower -j or CARGO_BUILD_JOBS, not more vCPU: fewer jobs finish, more jobs crash. Keep build caches on the VPS's own disk (NVMe storage on every plan) and prune old images with docker image prune, because a busy runner fills a disk faster than its pipelines suggest.

A monorepo that needs tens of gigabytes of RAM per build is bare-metal territory, which Cobaltfell does not sell. Database-backed test suites have their own sizing rules, covered in how much CPU and RAM PostgreSQL needs on a VPS.

Which executor should a runner on a VPS use?

The Docker executor is the right default: GitLab's executor guide says it gives each build a clean, isolated environment, while the Shell executor offers neither a clean environment per build nor protection of the runner's file system. The Shell, SSH and VirtualBox executors are in maintenance mode.

Who can start a job matters as much: a merge request from a fork runs its own code on the VPS. GitHub's security guide says self-hosted runners should almost never be used for public repositories, and the same reasoning applies to any CI system that runs untrusted pull requests.

Forgejo, Woodpecker, Jenkins and GitHub Actions agents size the same way: count overlapping jobs, give each fixed threads and memory. Plan prices for each size are listed under how much a dedicated-core VPS costs.