Jawaban singkat
VPS apa yang saya butuhkan untuk GitLab Runner atau pipeline CI/CD?
VPS GitLab Runner membutuhkan sekitar 2 vCPU khusus untuk setiap job CI yang berjalan bersamaan: di Cobaltfell, Fell 2 menangani satu job, Fell 4 dua job, dan Fell 8 empat job. Runner Linux hosted bawaan GitLab memiliki 2 vCPU dan 8 GB RAM (diperiksa 2 November 2026), jadi paket Cobaltfell dengan jumlah vCPU yang sama memiliki setengah memori tersebut, dan build yang haus memori perlu ukuran satu tingkat di atasnya.
Berapa banyak job CI yang dapat dijalankan satu VPS secara bersamaan?
Satu job CI membutuhkan dua vCPU khusus dan RAM yang menyertainya; pengaturan concurrent pada runner menentukan berapa banyak job tersebut yang berbagi VPS. Di config.toml, concurrent membatasi jumlah job di semua runner yang terdaftar, dan limit membatasinya untuk satu runner terdaftar (0, nilai default, berarti tanpa batas). Halaman persyaratan GitLab menyebut tiga masukan untuk menentukan ukuran: beban CPU job, penggunaan memori job, dan berapa banyak yang berjalan bersamaan.
| Paket | vCPU | RAM | bersamaan | Muat |
|---|---|---|---|---|
| Fell 2 | 2 | 4 GB | 1 | Satu pipeline sekaligus: proyek pribadi atau tim yang push beberapa kali dalam satu jam |
| Fell 4 | 4 | 8 GB | 2 | Dua job pendek sekaligus, atau satu build panjang dengan empat thread |
| Fell 8 | 8 | 16 GB | 4 | Empat job dua vCPU, atau dua job empat vCPU |
| Fell 16 | 16 | 32 GB | 4 hingga 8 | Tim yang merge request-nya memulai beberapa pipeline sekaligus |
Bagaimana ukuran runner hosted GitLab dibandingkan dengan VPS?
Runner Linux hosted GitLab memberikan 4 GB RAM per vCPU; paket Cobaltfell memberikan 2 GB per vCPU. Jumlah vCPU-nya sejajar satu banding satu, sehingga tabel ini menjadi cara langsung untuk memilih ukuran bagi pipeline yang sudah berjalan di GitLab.com. Job yang memakai sebagian besar memori mesinnya saat ini memerlukan paket Cobaltfell satu tingkat di atasnya, atau lebih sedikit job sekaligus.
Menurut survei Cobaltfell pada 2 November 2026, satu vCPU khusus pada prosesor tahun 2022 atau lebih baru berbiaya median $8.20 per bulan di host yang menerima kripto tanpa pemeriksaan identitas, jadi setiap job CI paralel dua vCPU berbiaya sekitar dua kali lipatnya.
Setiap host dan harga di balik median tersebut ada di berapa biaya VPS CPU khusus per core pada November 2026.
| Tipe mesin hosted GitLab | vCPU | RAM | Disk | Paket VPS dengan vCPU yang sama | RAM dan NVMe-nya |
|---|---|---|---|---|---|
| saas-linux-small-amd64 (default) | 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 dan Ultimate) | 8 | 32 GB | 100 GB | Fell 8 | 16 GB, 320 GB NVMe |
| saas-linux-xlarge-amd64 (Premium dan Ultimate) | 16 | 64 GB | 200 GB | Fell 16 | 32 GB, 640 GB NVMe |
Harga diperiksa pada
Mengapa core khusus penting untuk job CI dan kompilasi?
Build menahan CPU pada beban penuh selama beberapa menit sekaligus, pola persis yang hendak dibatasi oleh paket VPS berbagi. Dua host dalam survei yang sama mencantumkannya dalam aturan mereka: ketentuan Spartan Host melarang penggunaan lebih dari 50% core yang dialokasikan selama lebih dari satu jam, dan kebijakan fair-use Advin Servers membatasi penggunaan CPU pada 75%.
Pada vCPU berbagi, biayanya juga muncul sebagai steal time. Pipeline yang cepat pada malam yang sepi melar pada jam sibuk, dan timeout job terpicu karena alasan yang tidak terkait kode; apa itu CPU steal time dan cara memeriksanya di VPS menunjukkan cara membacanya.
Di Cobaltfell: Beban penuh diperbolehkan selama pekerjaan Anda membutuhkannya: tanpa CPU credit, tanpa jendela burst, dan tanpa throttling setelah beberapa menit pada 100%. Satu vCPU adalah satu thread perangkat keras dari prosesor host. Thread milik Anda dipatok satu per satu ke VPS Anda dan tidak pernah dipinjamkan ke pelanggan lain, dan dua thread dari satu core fisik tetap bersama, jadi setiap 2 vCPU membentuk satu core utuh yang tidak dipakai bersama oleh tetangga. Tanpa tetangga di thread yang sama, pipeline dengan cache hangat memakan waktu kurang lebih sama pada setiap eksekusi, sehingga job yang lambat menunjuk ke kode. Cara kerja aturan vCPU-ke-core dijelaskan di apakah vCPU khusus itu core atau thread.
Bagaimana cara menghentikan build paralel agar tidak berebut vCPU yang sama?
Beri setiap job bagian tetap dari VPS dan berikan angka yang sama ke alat build. Alat build berbeda pendapat soal default. GNU make menjalankan satu resep sekaligus kecuali diberi -j. Cargo menjalankan sebanyak job sesuai jumlah CPU logis. Ninja berjalan paralel berdasarkan jumlah CPU tanpa diminta. Empat build semacam itu di Fell 8 masing-masing akan memulai delapan compiler: 32 proses untuk 8 thread dan 16 GB RAM.
Dengan executor Docker, setiap job berjalan di container-nya sendiri, dan [runners.docker] menerima batas cpus dan memory untuk container tersebut. Setel keduanya, lalu samakan paralelisme di dalam 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 Dockervariables:
MAKEFLAGS: "-j2" # GNU make
CARGO_BUILD_JOBS: "2" # cargo (build.jobs)
build:
script:
- make
- cargo build --release
- ninja -C build -j 2Apa yang dibutuhkan kompilasi Rust atau C++ di VPS?
Kompilasi membutuhkan thread dan memori yang sejalan: setiap proses compiler paralel dan setiap langkah link mengambil bagian RAM-nya sendiri. Unit translasi C++ yang besar dan crate Rust dengan generic yang berat adalah puncak memori yang biasa terjadi, dan link akhir biner besar bisa membutuhkan lebih banyak daripada kompilasi tunggal mana pun.
Build yang dimatikan karena kehabisan memori membutuhkan -j atau CARGO_BUILD_JOBS yang lebih rendah, bukan vCPU lebih banyak: job yang lebih sedikit selesai, job yang lebih banyak crash. Simpan cache build di disk VPS itu sendiri (Penyimpanan NVMe di setiap paket) dan bersihkan image lama dengan docker image prune, karena runner yang sibuk memenuhi disk lebih cepat daripada yang disiratkan pipeline-nya.
Monorepo yang membutuhkan puluhan gigabyte RAM per build adalah wilayah bare-metal, yang tidak dijual Cobaltfell. Rangkaian pengujian berbasis database memiliki aturan ukuran tersendiri, dibahas di berapa CPU dan RAM yang dibutuhkan PostgreSQL di VPS.
Executor mana yang sebaiknya digunakan runner di VPS?
Executor Docker adalah default yang tepat: panduan executor GitLab menyatakan bahwa executor ini memberi setiap build lingkungan yang bersih dan terisolasi, sedangkan executor Shell tidak memberikan lingkungan bersih per build maupun perlindungan terhadap sistem file runner. Executor Shell, SSH, dan VirtualBox berada dalam mode maintenance.
Siapa yang dapat memulai job sama pentingnya: merge request dari fork menjalankan kodenya sendiri di VPS. Panduan keamanan GitHub menyatakan runner self-hosted hampir tidak boleh digunakan untuk repositori publik, dan alasan yang sama berlaku untuk sistem CI apa pun yang menjalankan pull request dari sumber tak tepercaya.
Forgejo, Woodpecker, Jenkins, dan agen GitHub Actions menentukan ukuran dengan cara yang sama: hitung job yang tumpang tindih, beri masing-masing thread dan memori tetap. Harga paket untuk setiap ukuran tercantum di berapa biaya VPS core khusus.
Pertanyaan lain apa yang orang ajukan tentang runner CI di VPS?
Bisakah VPS Cobaltfell menjalankan runner self-hosted GitHub Actions?
Ya. Agen runner Linux apa pun berfungsi: Hanya image Linux: Debian, Ubuntu, AlmaLinux, dan Rocky Linux. Windows tidak disediakan. Tentukan ukurannya seperti GitLab Runner, sekitar dua vCPU per job yang tumpang tindih, dan jauhkan dari repositori publik tempat orang asing dapat membuka pull request.
Apakah build dengan CPU 100% selama satu jam akan di-throttle?
Tidak di Cobaltfell. Beban penuh diperbolehkan selama pekerjaan Anda membutuhkannya: tanpa CPU credit, tanpa jendela burst, dan tanpa throttling setelah beberapa menit pada 100%. Satu-satunya penggunaan berat CPU yang dilarang: Menambang cryptocurrency apa pun tidak diizinkan, pada paket apa pun dan dengan software apa pun. Pekerjaan CPU berat Anda sendiri, seperti build, encoding, inference, atau database, boleh berjalan pada beban penuh, dan node yang hanya memvalidasi blockchain bukanlah penambangan.
Apakah GitLab Runner membutuhkan Docker?
Tidak, executor Shell menjalankan job langsung di VPS. GitLab mencatat bahwa executor ini tidak memberikan lingkungan bersih per build dan berada dalam mode maintenance, jadi Docker adalah default yang lebih baik untuk apa pun yang tidak akan Anda jalankan sendiri sebagai root.
Haruskah GitLab sendiri dijalankan di VPS yang sama dengan runner?
Tidak. GitLab dan runner-nya lalu bersaing untuk thread dan memori yang sama, dan pipeline yang berat memperlambat antarmuka web yang dipakai untuk memantaunya. Runner sebaiknya diletakkan di VPS-nya sendiri.
Seberapa cepat sebuah pipeline di setiap paket?
Belum ada data waktu yang dipublikasikan. Hasil YABS dan Geekbench 6 kami sendiri, bersama steal time yang kami ukur, akan diterbitkan beserta tanggalnya setelah mesin uji pertama kami tiba. Sampai saat itu kami tidak mencantumkan angka performa apa pun dari kami sendiri. Jalankan pipeline yang sama dua kali pada paket yang dipilih dan catat waktu kedua yang cache-nya sudah hangat sebagai baseline.
Sumber (10)
- Konfigurasi lanjutan GitLab Runner (concurrent, limit, [runners.docker]) — GitLab (checked 2026-11-02)
- Persyaratan sistem GitLab Runner — GitLab (checked 2026-11-02)
- Runner yang dihosting GitLab di Linux: tipe mesin — GitLab (checked 2026-11-02)
- Executor GitLab Runner — GitLab (checked 2026-11-02)
- Manual GNU make: eksekusi paralel — GNU Project (checked 2026-11-02)
- cargo build: opsi --jobs — The Rust Project (checked 2026-11-02)
- Manual sistem build Ninja — Ninja (checked 2026-11-02)
- Referensi penggunaan aman: runner yang dihosting sendiri — GitHub (checked 2026-11-02)
- Ketentuan layanan Spartan Host spartanhost.org/tos — Spartan Host (checked 2026-11-02)
- Kebijakan penggunaan wajar Advin Servers docs.advinservers.com/policies/fair-use — Advin Servers (checked 2026-11-02)