Tempo de Leitura
3
min
GitLab CI: tags de runner e roteamento de jobs (sem dor)
Blog
Nossas últimas novidadesRunner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno
Entenda quando um runner dedicado vale a pena, como planejar tags/labels, segurança e capacidade, e como usar runners compartilhados como fallback sem travar o time.
23 de fevereiro de 2026
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:
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:
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).
