Blog

Nossas últimas novidades

Tempo de Leitura

min

Runner dedicado: como escolher a máquina ideal (Mac mini, Windows ou Linux)

Guia prático para dimensionar um runner dedicado para CI/CD: CPU, RAM, SSD, rede, Docker e escolhas entre Mac mini, Windows e Linux.

23 de fevereiro de 2026

Por que um runner dedicado muda o jogo

Quando seu pipeline começa a “fila” (jobs esperando runner) ou fica instável por depender de máquinas de dev, um runner dedicado resolve dois problemas de uma vez:

Previsibilidade: você controla CPU/RAM, disco e rede.
Velocidade: cache e dependências “esquentam” no mesmo host e param de disputar recursos com outras tarefas.

O pulo do gato é dimensionar pensando no seu tipo de build (front-end, back-end, mobile) e na sua concorrência (quantos jobs rodam ao mesmo tempo). No GitLab Runner, isso é governado por configurações como concurrent e limit no config.toml (quanto maior, mais recursos você precisa).

O que realmente importa no hardware (e o que é “nice to have”)

1) CPU: mais núcleos ajuda mais que “turbo” (na maioria dos times)

Para pipelines modernos (Node/Vite/Next, testes, lint, typecheck), multi-core quase sempre ganha, porque:

você roda mais de um job ao mesmo tempo, e
várias ferramentas já paralelizam por padrão (bundlers, minificadores, testes).

Regra prática:

Single-core forte ajuda em etapas específicas (ex.: bundling pesado),
Mais cores ajuda no tempo total do pipeline (mais jobs simultâneos).

2) Memória (RAM): é onde os pipelines morrem quando falta

O principal sintoma de RAM curta é job que “morre do nada”, swap e build que oscila. Se você usa Docker, some:

RAM do host
RAM das imagens/containers
RAM do navegador (se rodar E2E tipo Playwright/Cypress)

Regra prática (para front-end):

16 GB: serve para 1 job por vez com folga moderada
32 GB: “ponto doce” para 2–4 jobs dependendo do seu stack
64 GB: para rodar múltiplos jobs + E2E sem susto

3) SSD e I/O: o segredo para npm/pnpm/yarn + Docker

CI é basicamente “baixar + descompactar + cachear”. Então:

prefira SSD/NVMe
garanta espaço (imagens Docker crescem rápido)
use cache de dependências (GitLab cache/artifacts) para reduzir download

4) Rede: 1 Gbps já ajuda, mas estabilidade é rei

Pipeline lento muitas vezes é:

registry (pull/push) lento
dependências baixando toda hora

Se for uma máquina dedicada, coloque cabo e trate rede como requisito.

5) GPU e “AI core” (Neural Engine): quase nunca entram nessa conta

Para CI de front-end/back-end, GPU/AI core não acelera build, lint ou testes unitários. Só faz sentido se você:

roda pipeline de ML/IA, render/3D, ou workloads com CUDA/Metal
compila shaders ou roda inferência no CI (caso bem específico)

Linux, macOS ou Windows: qual escolher?

Linux (recomendação padrão para Docker)

Se seu pipeline é “container-first”, Linux costuma ser o caminho mais simples:

Docker “nativo” (sem camada extra de VM)
menor custo por performance
fácil escalar (mais runners)

Para a maioria dos times, um runner Linux em Docker executor é o melhor custo-benefício.

macOS (quando você PRECISA de macOS)

Mac como runner faz sentido se você:

compila iOS/macOS (Xcode),
precisa de signing/notarization,
ou precisa validar algo específico do ecossistema Apple.

Na prática, macOS é ótimo para builds Apple, mas para pipelines “100% Docker”, você vai operar via Docker Desktop/VM, o que pode adicionar complexidade.

Windows (use quando o alvo é Windows)

Windows runner faz sentido se seu build/teste exige:

.NET/Windows-only tooling,
MSBuild, installers, testes com dependências do Windows,
ou Windows containers.

Se você só quer rodar Linux containers, normalmente Linux/WSL2 é mais simples — e você evita fricção com imagens de Windows containers.

Mac mini: M4 base atende? Ou precisa M4 Pro?

A pergunta certa é: quantos jobs simultâneos e qual tipo de job?

Mac mini M4 (base) — bom “primeiro runner” para pipelines leves/médios

Pontos fortes:

excelente eficiência energética
ótimo desempenho para workloads gerais
base moderna (em modelos recentes, é comum encontrar configuração inicial com 16 GB)

Use quando:

1–2 jobs simultâneos
sem E2E pesado
foco em build/lint/test unitário

Recomendação prática: se o seu pipeline tem E2E (Playwright/Cypress) ou builds grandes, prefira configurar o Mac mini com 32 GB.

Mac mini M4 Pro — quando você quer concorrência + folga

Vale a pena quando:

você quer 2–6 jobs simultâneos com estabilidade
roda E2E frequentemente
faz build de projetos maiores (monorepo, muitos pacotes)
precisa de mais memória (até 64 GB em muitos cenários)

Resumo: M4 Pro não é “obrigatório”, mas vira uma compra muito defensável quando o seu CI já é gargalo e você quer “parar de pensar” nisso.

Windows: Arm ou x64? Rodar “puro” ou em Docker?

Arm (Windows on Arm)

Hoje dá para usar Docker Desktop com WSL2 e há suporte (inclusive em evolução) para cenários em Arm, mas o ecossistema ainda pode ter arestas:

algumas imagens/ dependências ainda assumem x64
toolchains e binários podem exigir emulação

Se o objetivo é CI “sem surpresas”, x64 ainda é a opção mais previsível.

Docker vs “puro” (Shell executor)

Docker executor: melhor isolamento, ambientes reproduzíveis e menos “funciona só na minha máquina”.
Shell executor: rápido e simples, mas jobs rodam no host (mais risco e mais drift).

Se você vai compartilhar runner entre projetos ou aceitar pipelines de terceiros, priorize isolamento.

Configurações recomendadas (ponto de partida)

Perfil A — “Front-end padrão” (build + lint + unit)

CPU: 6–10 cores
RAM: 16–32 GB
SSD: 512 GB+
Concurrency: 1–2 jobs

Perfil B — “Front-end com E2E frequente”

CPU: 10–14 cores
RAM: 32–64 GB
SSD: 1 TB
Concurrency: 2–4 jobs

Perfil C — “iOS/macOS CI”

Mac mini / Mac Studio (depende do volume)
RAM: 32–64 GB
SSD: 1 TB
Concurrency: 1–3 (Xcode paraleliza muito e consome RAM)

Checklist de segurança (o que não dá para pular)

Runner dedicado deve rodar com usuário/permiteções limitadas (não “admin” por padrão).
Evite privileged containers sem necessidade (pode abrir muita superfície de ataque).
Use cache/artifacts com política de retenção.
Separe runners por “nível de confiança” (projetos internos vs externos).
Pin de versões (Node, pnpm, imagens base) para reproducibilidade.