Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno

Runner dedicado é uma das decisões com maior impacto na performance do CI/CD em times pequenos.

A razão é simples: o custo do tempo perdido (fila, builds inconsistentes) costuma ser maior do que o custo de uma máquina bem configurada.

Este post faz parte da série:

• Guia de CI/CD no Git para times pequenos: performance, cache e runners

Mapa da série CI/CD

• Guia de CI/CD no Git para times pequenos: performance, cache e runners
• GitLab CI: tags de runner e roteamento de jobs
• Cache no CI/CD: como desenhar keys e evitar cache inválido (GitHub e GitLab)
• Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to
• Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno
• Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas

1) Sinais de que você precisa de runner dedicado

Se você marcar “sim” para 2 ou mais itens, vale avaliar seriamente:

• Fila frequente: jobs aguardam runner com frequência.
• Execução instável: o mesmo job varia muito de tempo.
• Builds pesados: docker build, mobile, ou monorepo grande.
• macOS é necessário: custo alto por minuto de runner macOS.
• Você depende de máquina de dev (Wi‑Fi, uso local, desligamento).

2) O que runner dedicado resolve (e o que não resolve)

Resolve:

• reduz fila (mais capacidade disponível)
• aumenta previsibilidade (hardware e rede estáveis)
• facilita cache local (especialmente Docker layers)

Não resolve sozinho:

• Dockerfile ruim
• cache keys mal desenhadas
• dependências instáveis
• excesso de jobs serializados

3) Planejamento mínimo (para não virar “runner lixeira 2.0”)

Defina classes de job e tags/labels:

• lint-test (leve)
• build-heavy (pesado)
• docker (build de imagem)
• macos (Apple)
• linux-x64 / linux-arm64 (arquitetura)

A regra é: tags/labels precisam representar decisões operacionais.

Leitura complementar:

• GitLab CI: tags de runner e roteamento de jobs

4) Estratégia recomendada para time pequeno

Um arranjo típico e eficiente:

• Runner compartilhado (fallback): jobs leves, filas aceitáveis.
• Runner dedicado (principal): builds pesados e jobs que impactam entrega.
• Runner macOS (dedicado): apenas quando necessário (iOS/macOS).

5) Segurança: o ponto que ninguém quer discutir (mas precisa)

Runner self-hosted executa código do seu repositório.

Em termos práticos:

• você está rodando scripts no seu ambiente
• se o runner é compartilhado entre projetos, aumenta superfície de risco

Práticas de mitigação:

• restringir runner a grupos/projetos necessários
• separar runners por sensibilidade
• preferir executor isolado (container) quando possível
• manter sistema atualizado e com monitoramento básico

Checklist final

• Existe evidência de fila (queue time alto).
• Tags/labels foram desenhadas antes de ligar o runner.
• Runner dedicado não aceita “qualquer job”.
• Existe plano de fallback (runner compartilhado).
• Segurança foi considerada (escopo e isolamento).

Referências

• GitLab Docs: Configuring runners (tags, jobs tagged/untagged)
• GitHub Docs: Choose the runner for a job