Quantas vCPU dedicadas uma VPS para GitLab Runner precisa?

Quantos jobs de CI um único VPS consegue rodar ao mesmo tempo?

Um job de CI precisa de duas vCPU dedicadas e da RAM que vem com elas; a configuração concurrent do runner decide quantos desses jobs compartilham o VPS. No config.toml, concurrent limita os jobs em todos os runners registrados, e limit limita os jobs de um único runner registrado (0, o padrão, significa sem limite). A página de requisitos do GitLab indica os três dados para dimensionar: a carga de CPU dos jobs, o uso de memória deles e quantos rodam simultaneamente.

Como os tamanhos dos runners hospedados do GitLab se comparam com um VPS?

Os runners Linux hospedados do GitLab oferecem 4 GB de RAM por vCPU; os planos da Cobaltfell oferecem 2 GB por vCPU. As contagens de vCPU batem uma a uma, o que faz da tabela um jeito direto de escolher um tamanho para pipelines que já rodam no GitLab.com. Jobs que usam a maior parte da memória da máquina atual precisam do plano da Cobaltfell um tamanho acima, ou de menos jobs ao mesmo tempo.

Segundo o levantamento da Cobaltfell de 2 de novembro de 2026, uma vCPU dedicada em um processador de 2022 ou mais recente custava uma mediana de $8.20 por mês em provedores que aceitam cripto sem verificação de identidade, então cada job de CI paralelo de duas vCPU custa cerca do dobro disso.

Todo provedor e preço por trás dessa mediana está em quanto custa uma vCPU dedicada de VPS por núcleo em novembro de 2026.

Por que núcleos dedicados importam para jobs de CI e de compilação?

Um build mantém a CPU em carga total por minutos seguidos, exatamente o padrão que os planos de VPS compartilhados são feitos para limitar. Dois provedores do mesmo levantamento colocam isso em suas regras: os termos da Spartan Host proíbem usar mais de 50% dos núcleos alocados por mais de uma hora, e a política de uso justo da Advin Servers limita o uso de CPU a 75%.

Em uma vCPU compartilhada, o custo também aparece como steal time. Uma pipeline que é rápida em uma madrugada tranquila se arrasta nos horários de pico, e timeouts de job disparam por motivos sem relação com o código; o que é CPU steal time e como verificá-lo em um VPS mostra como ler isso.

Na Cobaltfell: Carga total é permitida pelo tempo que o seu trabalho precisar: sem créditos de CPU, sem janela de burst e sem throttling depois de alguns minutos a 100%. Uma vCPU é um thread de hardware do processador do host. As suas são fixadas uma a uma ao seu VPS e nunca são emprestadas a outro cliente, e os dois threads de um núcleo físico ficam juntos, então cada 2 vCPU formam um núcleo inteiro que nenhum vizinho compartilha. Sem nenhum vizinho nas threads, uma pipeline com cache quente leva aproximadamente o mesmo tempo a cada execução, então um job lento aponta para o código. Como funciona a regra de vCPU para núcleo é explicado em uma vCPU dedicada é um núcleo ou uma thread.

Como evito que builds paralelos disputem a mesma vCPU?

Dê a cada job uma fatia fixa do VPS e passe o mesmo número para a ferramenta de build. As ferramentas de build discordam sobre os padrões. O GNU make roda uma receita por vez, a menos que receba -j. O Cargo roda tantos jobs quanto há CPUs lógicas. O Ninja roda em paralelo com base na contagem de CPUs sem ser solicitado. Quatro desses builds no Fell 8 iniciariam cada um oito compiladores: 32 processos para 8 threads e 16 GB de RAM.

Com o executor Docker, cada job roda em seu próprio container, e [runners.docker] aceita um limite cpus e um limite memory para esse container. Defina os dois, depois ajuste o paralelismo dentro do 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 Docker

variables:
  MAKEFLAGS: "-j2"          # GNU make
  CARGO_BUILD_JOBS: "2"     # cargo (build.jobs)

build:
  script:
    - make
    - cargo build --release
    - ninja -C build -j 2

O que é preciso para compilar Rust ou C++ em um VPS?

Compilações precisam de threads e memória em sintonia: cada processo de compilador em paralelo e cada etapa de link usa sua própria fatia de RAM. Grandes unidades de tradução em C++ e crates Rust com muitos genéricos costumam ser os picos de memória, e o link final de um binário grande pode precisar de mais do que qualquer compilação isolada.

Um build morto por falta de memória precisa de um -j ou CARGO_BUILD_JOBS menor, não de mais vCPU: menos jobs terminam, mais jobs quebram. Mantenha os caches de build no disco do próprio VPS (Armazenamento NVMe em todos os planos) e limpe imagens antigas com docker image prune, porque um runner movimentado enche um disco mais rápido do que as pipelines sugerem.

Um monorepo que precisa de dezenas de gigabytes de RAM por build é território de bare-metal, que a Cobaltfell não vende. Suítes de teste com banco de dados têm suas próprias regras de dimensionamento, cobertas em quanta CPU e RAM o PostgreSQL precisa em um VPS.

Qual executor um runner em um VPS deve usar?

O executor Docker é o padrão certo: o guia de executores do GitLab diz que ele dá a cada build um ambiente limpo e isolado, enquanto o executor Shell não oferece nem um ambiente limpo por build nem proteção do sistema de arquivos do runner. Os executores Shell, SSH e VirtualBox estão em modo de manutenção.

Quem pode iniciar um job importa tanto quanto: um merge request vindo de um fork roda o próprio código no VPS. O guia de segurança do GitHub diz que runners auto-hospedados quase nunca deveriam ser usados em repositórios públicos, e o mesmo raciocínio vale para qualquer sistema de CI que rode pull requests não confiáveis.

Agentes do Forgejo, Woodpecker, Jenkins e GitHub Actions se dimensionam da mesma forma: conte os jobs simultâneos, dê a cada um threads e memória fixas. Os preços dos planos para cada tamanho estão em quanto custa um VPS com núcleos dedicados.