Ile dedykowanych vCPU potrzebuje VPS do GitLab Runner?

Ile zadań CI może uruchamiać jeden VPS jednocześnie?

Jedno zadanie CI potrzebuje dwóch dedykowanych vCPU i pamięci RAM, która z nimi przychodzi; ustawienie concurrent runnera decyduje, ile takich zadań współdzieli VPS. W config.toml opcja concurrent ogranicza zadania we wszystkich zarejestrowanych runnerach, a limit ogranicza je dla jednego zarejestrowanego runnera (0, wartość domyślna, oznacza brak limitu). Strona wymagań GitLaba podaje trzy dane wejściowe do doboru rozmiaru: obciążenie CPU przez zadania, ich zużycie pamięci i liczbę uruchamianych jednocześnie.

Jak rozmiary hostowanych runnerów GitLaba mają się do VPS?

Hostowane runnery Linux GitLaba dają 4 GB RAM na vCPU; plany Cobaltfell dają 2 GB na vCPU. Liczby vCPU pokrywają się jeden do jednego, co czyni tabelę prostym sposobem wyboru rozmiaru dla pipeline'ów, które już działają na GitLab.com. Zadania zużywające większość pamięci swojej obecnej maszyny potrzebują planu Cobaltfell o stopień wyżej albo mniejszej liczby zadań naraz.

Według ankiety Cobaltfell z 2 listopada 2026 jeden dedykowany vCPU na procesorze z 2022 roku lub nowszym kosztował medianę $8.20 miesięcznie u hostów przyjmujących płatność kryptowalutą bez weryfikacji tożsamości, więc każde równoległe zadanie CI na dwóch vCPU kosztuje około dwa razy tyle.

Każdy host i cena stojące za tą medianą są w ile kosztuje dedykowany vCPU VPS za rdzeń w listopadzie 2026.

Dlaczego dedykowane rdzenie mają znaczenie dla CI i kompilacji?

Build trzyma CPU pod pełnym obciążeniem przez wiele minut, czyli dokładnie ten wzorzec, który współdzielone plany VPS są zaprojektowane ograniczać. Dwa hosty z tej samej ankiety zapisały to w swoich regulaminach: warunki Spartan Host zabraniają używania ponad 50% przydzielonych rdzeni przez dłużej niż godzinę, a polityka fair use Advin Servers ogranicza użycie CPU do 75%.

Na współdzielonym vCPU koszt pojawia się też jako steal time. Pipeline, który jest szybki w spokojną noc, wydłuża się w godzinach szczytu, a limity czasu zadań wyzwalają się z powodów niezwiązanych z kodem; czym jest steal time CPU i jak sprawdzić go na VPS pokazuje, jak go odczytać.

W Cobaltfell: Pełne obciążenie jest dozwolone tak długo, jak wymaga tego Twoja praca: bez kredytów CPU, bez okna burst i bez throttlingu po kilku minutach przy 100%. vCPU to jeden wątek sprzętowy procesora hosta. Twoje są przypięte jeden do jednego do Twojego VPS i nigdy nie są pożyczane innemu klientowi, a dwa wątki jednego fizycznego rdzenia trzymają się razem, więc każde 2 vCPU tworzą jeden pełny rdzeń, którego nie dzieli żaden sąsiad. Bez sąsiada na wątkach pipeline z ciepłym cache trwa mniej więcej tyle samo przy każdym uruchomieniu, więc wolne zadanie wskazuje na kod. Jak działa reguła vCPU do rdzenia, wyjaśniono w czy dedykowany vCPU to rdzeń czy wątek.

Jak powstrzymać równoległe buildy przed walką o ten sam vCPU?

Daj każdemu zadaniu stały udział w VPS i przekaż tę samą liczbę do narzędzia budującego. Narzędzia budujące różnią się domyślnymi ustawieniami. GNU make wykonuje jedną recepturę naraz, o ile nie poda się -j. Cargo uruchamia tyle zadań, ile jest logicznych CPU. Ninja działa równolegle na podstawie liczby CPU, bez pytania. Cztery takie buildy na Fell 8 uruchomiłyby po osiem kompilatorów: 32 procesy na 8 wątków i 16 GB RAM.

Z executorem Docker każde zadanie działa we własnym kontenerze, a [runners.docker] przyjmuje limit cpus i memory dla tego kontenera. Ustaw oba, a następnie dopasuj równoległość wewnątrz zadania:

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

Czego potrzebuje kompilacja Rust lub C++ na VPS?

Kompilacje potrzebują wątków i pamięci w parze: każdy równoległy proces kompilatora i każdy krok linkowania bierze własny udział w RAM. Duże jednostki translacji C++ i crates Rust z ciężkimi generykami to typowe szczyty zużycia pamięci, a końcowe linkowanie dużego binarium może wymagać więcej niż jakakolwiek pojedyncza kompilacja.

Build zabity z powodu braku pamięci potrzebuje niższego -j lub CARGO_BUILD_JOBS, a nie więcej vCPU: mniej zadań się kończy, więcej się wysypuje. Trzymaj cache buildów na własnym dysku VPS (Pamięć NVMe w każdym planie) i usuwaj stare obrazy za pomocą docker image prune, bo zajęty runner zapełnia dysk szybciej, niż sugerują to jego pipeline'y.

Monorepo potrzebujące dziesiątek gigabajtów RAM na build to teren bare-metal, którego Cobaltfell nie sprzedaje. Zestawy testów oparte na bazie danych mają własne zasady doboru rozmiaru, opisane w ile CPU i RAM potrzebuje PostgreSQL na VPS.

Którego executora powinien używać runner na VPS?

Executor Docker jest właściwym domyślnym wyborem: przewodnik GitLaba po executorach mówi, że daje każdemu buildowi czyste, izolowane środowisko, podczas gdy executor Shell nie oferuje ani czystego środowiska na build, ani ochrony systemu plików runnera. Executory Shell, SSH i VirtualBox są w trybie konserwacji.

To, kto może uruchomić zadanie, ma równie duże znaczenie: merge request z forka uruchamia własny kod na VPS. Przewodnik bezpieczeństwa GitHuba mówi, że self-hosted runnerów prawie nigdy nie należy używać do publicznych repozytoriów, i to samo rozumowanie dotyczy każdego systemu CI, który uruchamia niezaufane pull requesty.

Agenci Forgejo, Woodpecker, Jenkins i GitHub Actions dobiera się tak samo: policz nakładające się zadania, daj każdemu stałe wątki i pamięć. Ceny planów dla każdego rozmiaru są wymienione pod ile kosztuje VPS z dedykowanymi rdzeniami.