# Quantas vCPU dedicadas uma VPS para GitLab Runner precisa?

> Qual VPS para GitLab Runner? 2 vCPU dedicadas por job de CI paralelo, de 2 a 16 vCPU. Dimensionamento e config.toml | Cobaltfell.

- URL: https://cobaltfell.com/pt/vps-for-ci-builds/
- Última atualização: 2026-11-02
- Editor: Cobaltfell (https://cobaltfell.com)

Qual VPS eu preciso para um GitLab Runner ou um pipeline de CI/CD? Quantos jobs por vez uma VPS com vCPU dedicada roda, como os tamanhos dos runners hospedados do GitLab se comparam e como evitar que builds paralelos disputem threads.

**Resposta rápida — Qual VPS eu preciso para um GitLab Runner ou um pipeline de CI/CD?**

Um VPS para GitLab Runner precisa de cerca de 2 vCPU dedicadas para cada job de CI que roda ao mesmo tempo: na **Cobaltfell**, o Fell 2 comporta um job, o Fell 4 dois e o Fell 8 quatro. O runner Linux hospedado padrão do GitLab tem 2 vCPU e 8 GB de RAM (verificado em 2 de novembro de 2026), então um plano da Cobaltfell com a mesma contagem de vCPU tem metade dessa memória, e builds que exigem muita memória precisam do tamanho seguinte.

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

*Pontos de partida tirados dos padrões das ferramentas, não de medições de tempo. Os nossos próprios resultados do YABS e do Geekbench 6, junto com o steal time que medimos, serão publicados com a data assim que a nossa primeira máquina de teste for entregue. Até lá, não divulgamos nenhum número de desempenho nosso.*

| Plano | vCPU | RAM | simultâneos | Cabe |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 | Uma pipeline por vez: um projeto pessoal ou uma equipe que faz push algumas vezes por hora |
| Fell 4 | 4 | 8 GB | 2 | Dois jobs curtos ao mesmo tempo, ou um build longo em quatro threads |
| Fell 8 | 8 | 16 GB | 4 | Quatro jobs de duas vCPU, ou dois de quatro |
| Fell 16 | 16 | 32 GB | 4 a 8 | Uma equipe cujos merge requests disparam várias pipelines ao mesmo tempo |

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

*Tipos de máquina do GitLab conforme listados na documentação dos runners hospedados do GitLab em 2 de novembro de 2026. Um runner hospedado atende um job por máquina; um runner auto-hospedado em um VPS compartilha suas vCPU entre vários jobs.*

| Tipo de máquina hospedada pelo GitLab | vCPU | RAM | Disco | Plano de VPS com a mesma vCPU | Sua RAM e NVMe |
| --- | --- | --- | --- | --- | --- |
| saas-linux-small-amd64 (padrão) | 2 | 8 GB | 30 GB | Fell 2 | 4 GB, 80 GB de NVMe |
| saas-linux-medium-amd64 | 4 | 16 GB | 50 GB | Fell 4 | 8 GB, 160 GB NVMe |
| saas-linux-large-amd64 (Premium e Ultimate) | 8 | 32 GB | 100 GB | Fell 8 | 16 GB, 320 GB NVMe |
| saas-linux-xlarge-amd64 (Premium e Ultimate) | 16 | 64 GB | 200 GB | Fell 16 | 32 GB, 640 GB NVMe |

*Preços verificados em 2 de 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](https://cobaltfell.com/pt/cpu-steal-time/ "O que é CPU steal time e como verificá-lo na minha 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](https://cobaltfell.com/pt/vcpu-vs-core/ "Um vCPU dedicado é um núcleo ou uma thread em um VPS?").

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

*config.toml para quatro jobs de duas vCPU cada no 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
```

*Paralelismo correspondente dentro do .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
```

## 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](https://cobaltfell.com/pt/vps-for-postgresql/ "Quanta CPU e RAM o PostgreSQL precisa em um VPS com vCPU dedicado?").

## 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](https://cobaltfell.com/pt/pricing/ "Quanto custa um VPS com vCPU dedicada?").

## Que outras perguntas as pessoas fazem sobre runners de CI em um VPS?

### Um VPS da Cobaltfell consegue rodar runners auto-hospedados do GitHub Actions?

Sim. Qualquer agente de runner Linux funciona: Somente imagens Linux: Debian, Ubuntu, AlmaLinux e Rocky Linux. Windows não é oferecido. Dimensione como um GitLab Runner, cerca de duas vCPU por job simultâneo, e mantenha-o longe de repositórios públicos onde estranhos possam abrir pull requests.

### Um build a 100% de CPU por uma hora é limitado?

Na Cobaltfell, não. 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%. O único uso intensivo de CPU proibido: Mineração de qualquer criptomoeda não é permitida, em nenhum plano e com nenhum software. O seu próprio trabalho pesado de CPU, como builds, encoding, inferência ou bancos de dados, pode rodar em carga total, e um nó que apenas valida uma blockchain não é mineração.

### O GitLab Runner precisa de Docker?

Não, o executor Shell roda os jobs diretamente no VPS. O GitLab observa que ele não dá um ambiente limpo por build e que está em modo de manutenção, então o Docker é o padrão melhor para qualquer coisa que você não rodaria na mão como root.

### O próprio GitLab deve rodar no mesmo VPS que o runner?

Não. O GitLab e o runner dele passam então a disputar as mesmas threads e memória, e um pipeline pesado deixa mais lenta a interface web usada para acompanhá-lo. Um runner pertence ao próprio VPS dele.

### Quão rápido é um pipeline em cada plano?

Ainda não há tempos publicados. Os nossos próprios resultados do YABS e do Geekbench 6, junto com o steal time que medimos, serão publicados com a data assim que a nossa primeira máquina de teste for entregue. Até lá, não divulgamos nenhum número de desempenho nosso. Rode o mesmo pipeline duas vezes no plano escolhido e use o segundo tempo, com cache já aquecido, como referência.

## Fontes

1. [Configuração avançada do GitLab Runner (concurrent, limit, [runners.docker])](https://docs.gitlab.com/runner/configuration/advanced-configuration/) — GitLab (checked 2026-11-02)
2. [Requisitos de sistema do GitLab Runner](https://docs.gitlab.com/runner/install/requirements/) — GitLab (checked 2026-11-02)
3. [Runners hospedados no GitLab em Linux: tipos de máquina](https://docs.gitlab.com/ci/runners/hosted_runners/linux/) — GitLab (checked 2026-11-02)
4. [Executores do GitLab Runner](https://docs.gitlab.com/runner/executors/) — GitLab (checked 2026-11-02)
5. [Manual do GNU make: execução paralela](https://www.gnu.org/software/make/manual/html_node/Parallel.html) — GNU Project (checked 2026-11-02)
6. [cargo build: a opção --jobs](https://doc.rust-lang.org/cargo/commands/cargo-build.html) — The Rust Project (checked 2026-11-02)
7. [Manual do sistema de build Ninja](https://ninja-build.org/manual.html) — Ninja (checked 2026-11-02)
8. [Referência de uso seguro: runners autogerenciados](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub (checked 2026-11-02)
9. [Termos de serviço da Spartan Host](https://spartanhost.org/tos) — Spartan Host (checked 2026-11-02)
10. [Política de uso justo da Advin Servers](https://docs.advinservers.com/policies/fair-use) — Advin Servers (checked 2026-11-02)

---

Cobaltfell: A Cobaltfell é uma provedora de VPS com núcleos vCPU dedicados, paga em cripto, sem envio de documento de identidade e operada pela DomaineGoat LLC, empresa registrada no Panamá. Cada vCPU é fixado exclusivamente no seu servidor, em processadores AMD EPYC 9004/9005 (Zen 4 / Zen 5) com armazenamento NVMe, em Amsterdã (Países Baixos), Zurique (Suíça) e Bucareste (Romênia). No período de 12 meses, cada plano tem preço pelo menos 25% abaixo de um plano comparável de CPU dedicada nomeado, escolhido entre 6 provedores de VPS com cripto e sem KYC e consultado em 2 de novembro de 2026.