Скільки виділених vCPU потрібно для VPS під GitLab Runner?

Скільки CI-завдань може один VPS виконувати одночасно?

Одне CI-завдання потребує двох виділених vCPU і пам'яті, що йде з ними; налаштування раннера concurrent визначає, скільки таких завдань ділять VPS. У config.toml параметр concurrent обмежує завдання для всіх зареєстрованих раннерів, а limit обмежує їх для одного зареєстрованого раннера (0, значення за замовчуванням, означає без обмежень). Сторінка вимог GitLab називає три вхідні параметри для вибору розміру: навантаження на CPU від завдань, їхнє використання пам'яті та скільки з них виконується одночасно.

Як розміри хостингових раннерів GitLab порівнюються з VPS?

Хостингові Linux-раннери GitLab дають 4 GB RAM на vCPU; плани Cobaltfell дають 2 GB на vCPU. Кількість vCPU збігається один до одного, що робить таблицю прямим способом вибрати розмір для pipeline, які вже працюють на GitLab.com. Завдання, що використовують більшу частину пам'яті своєї поточної машини, потребують плану Cobaltfell на розмір більшого або меншої кількості завдань одночасно.

Згідно з оглядом Cobaltfell від 2 листопада 2026, одне виділене vCPU на процесорі 2022 року або новішому коштувало медіанно $8.20 на місяць у хостів, які приймають криптовалюту без перевірки ID, тож кожне паралельне CI-завдання на два vCPU коштує приблизно вдвічі більше.

Кожен хост і кожна ціна за цією медіаною є в скільки коштує VPS з виділеним CPU за ядро в листопаді 2026.

Чому виділені ядра важливі для CI та компіляції?

Збірка тримає CPU на повному навантаженні хвилинами поспіль — саме той патерн, який плани спільного VPS покликані обмежувати. Два хости з того ж огляду прописали це у своїх правилах: умови Spartan Host забороняють використовувати понад 50% виділених ядер довше ніж годину, а політика добросовісного використання Advin Servers обмежує використання CPU на 75%.

На спільному vCPU ціна також проявляється як steal time. Pipeline, що швидкий тихої ночі, розтягується в години пік, і таймаути завдань спрацьовують з причин, не пов'язаних із кодом; що таке steal time CPU і як його перевірити на VPS показує, як його читати.

У Cobaltfell: Повне навантаження дозволене стільки, скільки потрібно вашій роботі: без CPU-кредитів, без вікна бурсту і без тротлінгу після кількох хвилин на 100%. vCPU — це один апаратний потік процесора хоста. Ваші потоки закріплені один до одного за вашим VPS і ніколи не позичаються іншому клієнту, а два потоки одного фізичного ядра завжди лишаються разом, тож кожні 2 vCPU утворюють одне ціле ядро, якого не ділить із вами сусід. Без сусіда на потоках pipeline з теплим кешем займає приблизно однаковий час при кожному запуску, тож повільне завдання вказує на код. Як працює правило vCPU-до-ядра, пояснено в чи є виділений vCPU ядром чи потоком.

Як змусити паралельні збірки не битися за той самий vCPU?

Дай кожному завданню фіксовану частку VPS і передай те саме число інструменту збірки. Інструменти збірки розходяться в типових значеннях. GNU make виконує один рецепт за раз, якщо не задати -j. Cargo запускає стільки завдань, скільки є логічних CPU. Ninja виконується паралельно за кількістю CPU без запиту. Чотири такі збірки на Fell 8 запустили б кожна вісім компіляторів: 32 процеси на 8 потоків і 16 GB RAM.

З Docker-екзекутором кожне завдання виконується у власному контейнері, і [runners.docker] приймає ліміти cpus і memory для цього контейнера. Встанови обидва, а потім узгодь паралелізм усередині завдання:

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

Що потрібно для компіляції Rust чи C++ на VPS?

Компіляція потребує потоків і пам'яті в парі: кожен паралельний процес компілятора і кожен крок лінкування бере свою частку RAM. Великі одиниці трансляції C++ і крейти Rust із важкими generics — звичайні піки пам'яті, а фінальне лінкування великого бінарника може потребувати більше, ніж будь-яка окрема компіляція.

Збірка, убита через брак пам'яті, потребує нижчого -j або CARGO_BUILD_JOBS, а не більше vCPU: менше завдань завершується, більше падає. Тримай кеші збірки на власному диску VPS (NVMe-сховище на кожному плані) і чисти старі образи через docker image prune, бо зайнятий раннер заповнює диск швидше, ніж підказують його pipeline.

Монорепозиторій, що потребує десятків гігабайтів RAM на збірку, — це територія bare-metal, яку Cobaltfell не продає. Тестові набори з базами даних мають власні правила підбору розміру, розглянуті в скільки CPU і RAM потрібно PostgreSQL на VPS.

Який екзекутор має використовувати раннер на VPS?

Docker-екзекутор — правильне типове значення: посібник GitLab щодо екзекуторів каже, що він дає кожній збірці чисте ізольоване середовище, тоді як Shell-екзекутор не дає ні чистого середовища на кожну збірку, ні захисту файлової системи раннера. Екзекутори Shell, SSH і VirtualBox перебувають у режимі супроводу.

Хто може запустити завдання, важить не менше: merge request із форку виконує власний код на VPS. Посібник GitHub з безпеки каже, що самостійно розміщені раннери майже ніколи не слід використовувати для публічних репозиторіїв, і ті ж міркування стосуються будь-якої CI-системи, що виконує недовірені pull request.

Агенти Forgejo, Woodpecker, Jenkins і GitHub Actions підбираються так само: порахуй завдання, що перекриваються, дай кожному фіксовані потоки й пам'ять. Ціни планів для кожного розміру наведено в скільки коштує VPS з виділеними ядрами.