# Wie viele dedizierte vCPU braucht ein GitLab Runner VPS?

> Welchen VPS brauche ich für einen GitLab Runner? Etwa 2 dedizierte vCPU pro parallelem CI-Job, auf 2 bis 16 vCPU, ohne KYC bei Cobaltfell.

- URL: https://cobaltfell.com/de/vps-for-ci-builds/
- Zuletzt aktualisiert: 2026-11-02
- Herausgeber: Cobaltfell (https://cobaltfell.com)

Welchen VPS brauche ich für einen GitLab Runner oder eine CI/CD-Pipeline? Wie viele Jobs ein Dedicated-vCPU-VPS gleichzeitig ausführt, wie GitLabs gehostete Runner in der Dimensionierung abschneiden und wie Sie verhindern, dass parallele Builds um Threads konkurrieren.

**Kurze Antwort — Welchen VPS brauche ich für einen GitLab Runner oder eine CI/CD-Pipeline?**

Ein GitLab-Runner-VPS braucht etwa 2 dedizierte vCPU für jeden CI-Job, der gleichzeitig läuft: Bei **Cobaltfell** übernimmt Fell 2 einen Job, Fell 4 zwei und Fell 8 vier. GitLabs standardmäßig gehosteter Linux-Runner hat 2 vCPU und 8 GB RAM (geprüft am 2. November 2026), ein Cobaltfell-Plan mit derselben vCPU-Zahl hat also halb so viel Speicher, und speicherhungrige Builds brauchen die nächstgrößere Stufe.

## 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.

*Ausgangswerte aus Tool-Standards, nicht aus Messungen. Unsere eigenen YABS- und Geekbench-6-Ergebnisse sowie die von uns gemessene Steal Time werden mit Datum veröffentlicht, sobald unsere erste Testmaschine geliefert ist. Bis dahin nennen wir keinen eigenen Performance-Wert.*

| Plan | vCPU | RAM | gleichzeitig | Geeignet für |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 | Eine Pipeline auf einmal: ein persönliches Projekt oder ein Team, das ein paar Mal pro Stunde pusht |
| Fell 4 | 4 | 8 GB | 2 | Zwei kurze Jobs gleichzeitig oder ein langer Build auf vier Threads |
| Fell 8 | 8 | 16 GB | 4 | Vier Jobs mit zwei vCPU oder zwei mit vier |
| Fell 16 | 16 | 32 GB | 4 bis 8 | Ein Team, dessen Merge Requests mehrere Pipelines gleichzeitig starten |

## 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](https://cobaltfell.com/de/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026").

*GitLab-Maschinentypen wie in GitLabs Dokumentation zu gehosteten Runnern am 2. November 2026 aufgeführt. Ein gehosteter Runner bedient einen Job pro Maschine; ein selbst gehosteter Runner auf einem VPS teilt seine vCPU zwischen mehreren Jobs.*

| Von GitLab gehosteter Maschinentyp | vCPU | RAM | Festplatte | VPS-Plan mit derselben vCPU | Dessen RAM und NVMe |
| --- | --- | --- | --- | --- | --- |
| saas-linux-small-amd64 (Standard) | 2 | 8 GB | 30 GB | Fell 2 | 4 GB, 80 GB NVMe |
| saas-linux-medium-amd64 | 4 | 16 GB | 50 GB | Fell 4 | 8 GB, 160 GB NVMe |
| saas-linux-large-amd64 (Premium und Ultimate) | 8 | 32 GB | 100 GB | Fell 8 | 16 GB, 320 GB NVMe |
| saas-linux-xlarge-amd64 (Premium und Ultimate) | 16 | 64 GB | 200 GB | Fell 16 | 32 GB, 640 GB NVMe |

*Preise geprüft am 2. November 2026.*

## 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](https://cobaltfell.com/de/cpu-steal-time/ "Was ist CPU Steal Time und wie prüfe ich sie auf meinem VPS?") 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](https://cobaltfell.com/de/vcpu-vs-core/ "Ist ein dedizierter vCPU auf einem VPS ein Core 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:

*config.toml für vier Jobs mit je zwei vCPU auf Fell 8*

```toml
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
```

*Passende Parallelität in .gitlab-ci.yml*

```yaml
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](https://cobaltfell.com/de/vps-for-postgresql/ "Wie viel CPU und RAM braucht PostgreSQL auf einem VPS mit dedizierten vCPU?").

## 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](https://cobaltfell.com/de/pricing/ "Wie viel kostet ein Dedicated-vCPU-VPS?").

## Welche anderen Fragen stellen Leute zu CI-Runnern auf einem VPS?

### Kann ein Cobaltfell-VPS selbst gehostete GitHub Actions Runner ausführen?

Ja. Jeder Linux-Runner-Agent funktioniert: Nur Linux-Images: Debian, Ubuntu, AlmaLinux und Rocky Linux. Windows wird nicht angeboten. Dimensionieren Sie ihn wie einen GitLab Runner, etwa zwei vCPU pro überlappendem Job, und halten Sie ihn von öffentlichen Repositories fern, in denen Fremde Pull Requests öffnen können.

### Wird ein Build, der eine Stunde lang mit 100 % CPU läuft, gedrosselt?

Bei Cobaltfell nicht. Volllast ist erlaubt, solange Ihre Arbeit sie benötigt: keine CPU-Credits, kein Burst-Fenster und kein Drosseln nach einigen Minuten bei 100 %. Die einzige verbotene CPU-intensive Nutzung: Das Mining jeglicher Kryptowährung ist nicht erlaubt, in keinem Plan und mit keiner Software. Ihre eigene schwere CPU-Arbeit wie Builds, Encoding, Inferenz oder Datenbanken darf bei Volllast laufen, und ein Node, der nur eine Blockchain validiert, ist kein Mining.

### Braucht GitLab Runner Docker?

Nein, der Shell-Executor führt Jobs direkt auf dem VPS aus. GitLab merkt an, dass er keine saubere Umgebung pro Build bietet und im Wartungsmodus ist, also ist Docker der bessere Standard für alles, was Sie nicht von Hand als root ausführen würden.

### Sollte GitLab selbst auf demselben VPS laufen wie der Runner?

Nein. GitLab und sein Runner konkurrieren dann um dieselben Threads und denselben Arbeitsspeicher, und eine schwere Pipeline bremst die Weboberfläche, mit der man sie beobachtet. Ein Runner gehört auf einen eigenen VPS.

### Wie schnell ist eine Pipeline bei den einzelnen Tarifen?

Es sind noch keine Laufzeiten veröffentlicht. Unsere eigenen YABS- und Geekbench-6-Ergebnisse sowie die von uns gemessene Steal Time werden mit Datum veröffentlicht, sobald unsere erste Testmaschine geliefert ist. Bis dahin nennen wir keinen eigenen Performance-Wert. Lassen Sie dieselbe Pipeline zweimal im gewählten Tarif laufen und nehmen Sie die zweite Zeit mit warmem Cache als Referenzwert.

## Quellen

1. [Erweiterte Konfiguration des GitLab Runner (concurrent, limit, [runners.docker])](https://docs.gitlab.com/runner/configuration/advanced-configuration/) — GitLab (checked 2026-11-02)
2. [Systemanforderungen für GitLab Runner](https://docs.gitlab.com/runner/install/requirements/) — GitLab (checked 2026-11-02)
3. [Von GitLab gehostete Runner unter Linux: Maschinentypen](https://docs.gitlab.com/ci/runners/hosted_runners/linux/) — GitLab (checked 2026-11-02)
4. [GitLab Runner Executors](https://docs.gitlab.com/runner/executors/) — GitLab (checked 2026-11-02)
5. [GNU make Handbuch: parallele Ausführung](https://www.gnu.org/software/make/manual/html_node/Parallel.html) — GNU Project (checked 2026-11-02)
6. [cargo build: die Option --jobs](https://doc.rust-lang.org/cargo/commands/cargo-build.html) — The Rust Project (checked 2026-11-02)
7. [Das Handbuch des Ninja-Buildsystems](https://ninja-build.org/manual.html) — Ninja (checked 2026-11-02)
8. [Secure use reference: self-hosted runners](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub (checked 2026-11-02)
9. [Nutzungsbedingungen von Spartan Host](https://spartanhost.org/tos) — Spartan Host (checked 2026-11-02)
10. [Fair-Use-Richtlinie von Advin Servers](https://docs.advinservers.com/policies/fair-use) — Advin Servers (checked 2026-11-02)

---

Cobaltfell: Cobaltfell ist ein VPS-Anbieter mit dedizierten vCPU-Kernen, zahlbar mit Krypto ohne ID-Upload, betrieben von DomaineGoat LLC, einem in Panama registrierten Unternehmen. Jede vCPU ist ausschließlich Ihrem Server zugewiesen, auf AMD EPYC 9004/9005 Prozessoren (Zen 4 / Zen 5) mit NVMe-Speicher, in Amsterdam (Niederlande), Zürich (Schweiz) und Bukarest (Rumänien). Bei 12-monatiger Laufzeit liegt jeder Plan mindestens 25% unter einem namentlich genannten vergleichbaren Dedicated-CPU-Plan, ausgewählt aus 6 No-KYC-Krypto-VPS-Hostern und ausgelesen am 2. November 2026.