Wie viele dedizierte vCPU braucht ein GitLab Runner VPS?

Wie viele CI-Jobs kann ein VPS gleichzeitig ausführen?

Ein CI-Job braucht zwei dedizierte vCPU und den dazugehörigen RAM; die concurrent-Einstellung des Runners entscheidet, wie viele solcher Jobs sich den VPS teilen. In config.toml begrenzt concurrent die Jobs über alle registrierten Runner hinweg, und limit begrenzt sie für einen einzelnen registrierten Runner (0, der Standard, bedeutet kein Limit). GitLabs Anforderungsseite nennt die drei Größen, an denen man sich orientiert: die CPU-Last der Jobs, ihren Speicherverbrauch und wie viele gleichzeitig laufen.

Wie schneiden GitLabs gehostete Runner-Größen im Vergleich zu einem VPS ab?

GitLabs gehostete Linux-Runner geben 4 GB RAM pro vCPU; Cobaltfell-Pläne geben 2 GB pro vCPU. Die vCPU-Zahlen entsprechen sich eins zu eins, wodurch die Tabelle ein direkter Weg ist, eine Größe für Pipelines zu wählen, die bereits auf GitLab.com laufen. Jobs, die den Großteil des Speichers ihrer aktuellen Maschine nutzen, brauchen den Cobaltfell-Plan eine Stufe größer oder weniger Jobs gleichzeitig.

Laut Cobaltfells Erhebung vom 2. November 2026 kostete eine dedizierte vCPU auf einem Prozessor von 2022 oder neuer einen Median von $8.20 pro Monat bei Hostern, die Krypto ohne Ausweisprüfung annehmen, also kostet jeder parallele CI-Job mit zwei vCPU etwa das Doppelte.

Jeder Hoster und jeder Preis hinter diesem Median steht in was eine dedizierte CPU-VPS pro Kern im November 2026 kostet.

Warum sind dedizierte Kerne für CI- und Compile-Jobs wichtig?

Ein Build hält die CPU minutenlang unter Volllast, genau das Muster, auf das Shared-VPS-Pläne ausgelegt sind, um es zu begrenzen. Zwei Hoster derselben Erhebung schreiben es in ihre Regeln: Spartans Hosts Bedingungen verbieten, mehr als 50 % der zugewiesenen Kerne länger als eine Stunde zu nutzen, und Advin Servers' Fair-Use-Richtlinie begrenzt die CPU-Nutzung auf 75 %.

Bei einer geteilten vCPU zeigt sich der Preis auch als Steal Time. Eine Pipeline, die in einer ruhigen Nacht schnell ist, zieht sich zu Spitzenzeiten, und Job-Timeouts schlagen aus Gründen an, die nichts mit dem Code zu tun haben; was CPU-Steal-Time ist und wie man sie auf einem VPS prüft zeigt, wie man sie liest.

Bei Cobaltfell: Volllast ist erlaubt, solange Ihre Arbeit sie benötigt: keine CPU-Credits, kein Burst-Fenster und kein Drosseln nach einigen Minuten bei 100 %. Eine vCPU ist ein Hardware-Thread des Host-Prozessors. Ihre vCPUs sind eins zu eins an Ihren VPS gebunden und werden nie an einen anderen Kunden verliehen, und die beiden Threads eines physischen Kerns bleiben zusammen, sodass je 2 vCPU einen ganzen Kern ergeben, den kein Nachbar teilt. Ohne Nachbarn auf den Threads braucht eine cache-warme Pipeline bei jedem Lauf etwa gleich lang, ein langsamer Job deutet also auf den Code. Wie die vCPU-zu-Kern-Regel funktioniert, wird in ist eine dedizierte vCPU ein Kern oder ein Thread erklärt.

Wie verhindere ich, dass parallele Builds sich um dieselbe vCPU streiten?

Geben Sie jedem Job einen festen Anteil am VPS und übergeben Sie dieselbe Zahl an das Build-Tool. Build-Tools haben unterschiedliche Standards. GNU make führt jeweils ein Rezept auf einmal aus, sofern nicht -j angegeben wird. Cargo führt so viele Jobs aus, wie es logische CPUs gibt. Ninja läuft ungefragt parallel, basierend auf der CPU-Anzahl. Vier solcher Builds auf Fell 8 würden jeweils acht Compiler starten: 32 Prozesse für 8 Threads und 16 GB RAM.

Mit dem Docker-Executor läuft jeder Job in seinem eigenen Container, und [runners.docker] nimmt ein cpus- und ein memory-Limit für diesen Container entgegen. Setzen Sie beide, und passen Sie dann die Parallelität innerhalb des Jobs an:

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

Was braucht das Kompilieren von Rust oder C++ auf einem VPS?

Compiles brauchen Threads und Speicher im Gleichschritt: jeder parallele Compiler-Prozess und jeder Link-Schritt nimmt sich seinen eigenen Anteil am RAM. Große C++-Übersetzungseinheiten und Rust-Crates mit vielen Generics sind die üblichen Speicherspitzen, und das abschließende Linken einer großen Binary kann mehr brauchen als jeder einzelne Compile.

Ein Build, der wegen Speichermangels abgebrochen wird, braucht ein niedrigeres -j oder CARGO_BUILD_JOBS, nicht mehr vCPU: Weniger Jobs laufen durch, mehr Jobs stürzen ab. Halten Sie Build-Caches auf der Festplatte des VPS selbst (NVMe-Speicher in jedem Plan) und räumen Sie alte Images mit docker image prune auf, denn ein viel genutzter Runner füllt eine Festplatte schneller, als seine Pipelines vermuten lassen.

Ein Monorepo, das pro Build Dutzende Gigabyte RAM braucht, ist Bare-Metal-Territorium, das Cobaltfell nicht verkauft. Datenbankgestützte Test-Suites haben ihre eigenen Größenregeln, behandelt in wie viel CPU und RAM PostgreSQL auf einem VPS braucht.

Welchen Executor sollte ein Runner auf einem VPS verwenden?

Der Docker-Executor ist der richtige Standard: GitLabs Executor-Leitfaden sagt, er gebe jedem Build eine saubere, isolierte Umgebung, während der Shell-Executor weder eine saubere Umgebung pro Build noch einen Schutz des Dateisystems des Runners bietet. Die Executor Shell, SSH und VirtualBox sind im Wartungsmodus.

Wer einen Job starten kann, ist ebenso wichtig: Ein Merge Request aus einem Fork führt seinen eigenen Code auf dem VPS aus. GitHubs Sicherheitsleitfaden sagt, selbst gehostete Runner sollten fast nie für öffentliche Repositories verwendet werden, und dieselbe Begründung gilt für jedes CI-System, das nicht vertrauenswürdige Pull Requests ausführt.

Bei Forgejo, Woodpecker, Jenkins und GitHub Actions Agents dimensioniert man genauso: Überlappende Jobs zählen, jedem feste Threads und Speicher geben. Planpreise für jede Größe sind aufgeführt unter wie viel eine VPS mit dedizierten Kernen kostet.