Cloud Server para GitHub Actions sem fila na CI

Resposta direta

Um Cloud Server para GitHub Actions self-hosted runner faz sentido quando a equipe precisa reduzir filas de CI/CD, controlar dependências, acessar redes privadas ou executar builds com mais previsibilidade do que em runners compartilhados. Para pipelines leves, como testes unitários em Node.js, PHP ou Python, um servidor com 2 vCPUs, 4 GB de RAM e 60 GB de SSD já costuma ser um ponto de partida realista. Para builds com Docker, imagens grandes, testes paralelos ou monorepos, pense em 4 a 8 vCPUs, 8 a 16 GB de RAM e disco NVMe ou SSD com pelo menos 100 GB. A escolha não deve ser feita só por preço. CPU sustentada, I/O de disco, limite de rede, backup, snapshots e isolamento de segredos pesam bastante em produção.

Resumo rápido

• Self-hosted runner é indicado para equipes que precisam de CI/CD com mais controle, acesso a recursos privados e menor dependência de runners compartilhados.
• Um ponto de partida seguro para pipelines leves é 2 vCPUs, 4 GB de RAM e 60 GB de SSD, com swap pequena e monitoramento ativo.
• Pipelines com Docker exigem mais disco e I/O. Use 4 vCPUs, 8 GB de RAM e 100 GB ou mais quando houver build de imagens frequente.
• Nunca rode jobs sensíveis como root. Crie usuário dedicado, restrinja SSH, aplique firewall e revise permissões do runner.
• Cache melhora tempo de build, mas pode consumir disco rapidamente. Defina limpeza automática para imagens, volumes e dependências antigas.
• Cloud Server é mais flexível que VPS tradicional quando você precisa escalar CPU, RAM ou recriar runners com automação.
• Para comparar abordagens, veja também runners de GitLab em /vps-para-gitlab-runner-e-ci-cd/ e pipelines Jenkins em /vps-para-jenkins-e-pipelines-ci-cd/.

Quando faz sentido usar self-hosted runner

GitHub Actions já oferece runners hospedados pela própria plataforma, e eles resolvem bem muitos cenários. O self-hosted runner entra quando o pipeline precisa de algo que o ambiente padrão não entrega com conforto: acesso a uma VPC privada, dependências pesadas pré-instaladas, compilação mais longa, builds com Docker frequentes ou previsibilidade de fila. Em equipes pequenas, a motivação costuma ser simples. O workflow demora 20 minutos em horário de pico, baixa as mesmas dependências toda vez e ainda precisa acessar um banco de staging protegido por IP. Um runner privado bem configurado corta parte desse atrito.

O que muda em relação ao runner hospedado

A principal mudança é que a responsabilidade operacional passa para você. No runner hospedado, o GitHub provisiona e descarta a máquina. No self-hosted runner, o Cloud Server fica sob sua administração. Isso traz controle, mas também traz manutenção. Você escolhe versão do Ubuntu, Docker Engine, Node.js, PHP, Java, Go, cache local e ferramentas de deploy. Ao mesmo tempo, precisa atualizar pacotes, proteger chaves, limpar disco e monitorar processos travados.

Um exemplo comum é uma agência que mantém 30 sites em WordPress e executa testes, lint e deploy por GitHub Actions. Usando runner compartilhado, cada job baixa dependências do Composer e npm do zero. Em um runner privado com cache persistente e disco rápido, parte desse tempo cai, desde que o cache seja bem controlado. O mesmo raciocínio vale para SaaS em Laravel, APIs em NestJS e aplicações Go compiladas a cada pull request.

Sinais de que a equipe precisa de controle próprio

O self-hosted runner começa a valer a conversa quando a equipe tem mais de 20 ou 30 execuções por dia, workflows com Docker, jobs que precisam de credenciais de rede interna ou builds que sofrem com variação grande de tempo. Outro sinal claro é a necessidade de runner com arquitetura específica, como ARM64, GPU ou bibliotecas nativas difíceis de instalar em cada execução.

Se o seu problema é apenas organizar melhor os workflows, talvez ainda não seja hora de manter servidor próprio. Mas se CI/CD virou gargalo de entrega, um Cloud Server dedicado ao GitHub Actions pode ser uma peça simples e eficiente. Quem já avaliou alternativas como GitLab Runner em /vps-para-gitlab-runner-e-ci-cd/ vai reconhecer a lógica: o runner privado reduz dependência externa, mas exige disciplina de operação.

Como dimensionar CPU, RAM, disco e rede

Dimensionar Cloud Server para GitHub Actions começa pelo tipo de pipeline, não pelo número de repositórios. Um repositório pequeno com testes unitários em JavaScript pode consumir menos que um único projeto com Docker Compose, banco PostgreSQL, Redis e testes end-to-end em navegador headless. Antes de escolher plano, observe três números por workflow: duração média, pico de memória e volume de leitura e escrita em disco. Se ainda não há métricas, rode alguns jobs em uma máquina de teste e acompanhe com htop, docker stats, iotop e df -h.

Perfis de pipeline e consumo típico

Para pipelines leves, como lint, testes unitários e build estático, 2 vCPUs e 4 GB de RAM costumam dar conta de uma execução por vez. O disco precisa acomodar sistema, runner, dependências, cache e artefatos temporários. Por isso, 40 GB é apertado. Prefira 60 GB ou mais. Em Node.js, uma pasta node_modules pode passar de 500 MB com facilidade. Em Java ou Android, caches de Gradle crescem ainda mais.

Pipelines médios, com Docker build, testes integrados e banco local, pedem 4 vCPUs e 8 GB de RAM. O Docker cria camadas, volumes e imagens intermediárias. Um projeto com duas imagens de 1,5 GB, mais cache de dependências, pode ocupar 20 GB sem muito esforço. Quando há builds paralelos, multiplique o consumo. Dois jobs simultâneos que usam 3 GB cada deixam um servidor de 8 GB perto do limite, especialmente com Docker, sistema e agentes auxiliares rodando.

Pipelines pesados, como monorepos, compilação Java grande, testes com Playwright, Cypress ou múltiplos containers, merecem 8 vCPUs, 16 GB de RAM e 150 GB ou mais de SSD ou NVMe. Disco rápido não resolve código lento, mas reduz espera em etapas de extração, cache, build de imagem e instalação de dependências.

Tabela de dimensionamento por cenário

Perfil de uso	Configuração inicial	Concorrência recomendada	Disco e cache	Observações práticas
Pipeline leve	2 vCPUs, 4 GB RAM	1 job simultâneo	60 GB SSD	Bom para lint, testes unitários e build estático
Pipeline com Docker	4 vCPUs, 8 GB RAM	1 a 2 jobs	100 GB SSD ou NVMe	Exige limpeza de imagens e volumes antigos
Monorepo ou testes E2E	8 vCPUs, 16 GB RAM	2 a 4 jobs	150 GB ou mais	Recomendado separar cache, artefatos e logs
Pool de runners	2 a 4 servidores menores	Escala por fila	60 a 100 GB por nó	Melhor isolamento e menor impacto de job travado

Rede também entra na conta. Builds que baixam imagens Docker grandes, SDKs ou dependências de registries externos dependem de boa saída de internet. Para público e equipe no Brasil, datacenter local pode reduzir latência no acesso SSH, em deploys para infraestrutura nacional e em comunicação com serviços privados. Ainda assim, latência não substitui CPU, RAM e disco adequados.

Arquitetura recomendada para runners privados

A arquitetura mais simples é instalar um runner em um único Cloud Server e executar um job por vez. Funciona para dev solo, projetos internos e times pequenos. O risco é concentrar tudo em uma máquina persistente. Se um job deixa container parado, ocupa todo o disco ou altera uma ferramenta global, o próximo workflow pode falhar sem relação aparente com o código. Por isso, mesmo no cenário simples, trate o runner como infraestrutura descartável sempre que possível.

Runner único, pool de runners e ambientes efêmeros

Runner único é barato de operar e fácil de entender. Um servidor Ubuntu 22.04 ou 24.04 LTS, usuário github-runner, Docker instalado e serviço systemd já resolvem muitos casos. A recomendação é limitar labels e escopo. Em vez de cadastrar o runner para toda a organização sem critério, comece por um repositório ou por um grupo pequeno. Use labels como linux, docker, staging ou build-heavy para evitar que qualquer workflow caia na máquina errada.

Em times com vários repositórios, pool de runners costuma ser mais saudável. Dois servidores de 4 vCPUs e 8 GB podem ser melhores que um único servidor de 8 vCPUs e 16 GB, porque um job problemático não derruba toda a fila. Também fica mais fácil separar workloads. Um runner executa testes rápidos, outro faz Docker build e outro cuida de deploy para staging. Essa separação reduz conflito por cache, CPU e permissões.

Runners efêmeros são a opção mais limpa do ponto de vista de isolamento. A cada job, a máquina ou container é criado, executa o workflow e é destruído. O custo operacional sobe, porque você precisa automatizar provisionamento, registro e remoção. Em troca, reduz risco de vazamento entre builds. Para empresas com requisitos de compliance, essa abordagem costuma ser mais adequada.

Separação entre CI, staging e produção

Evite misturar runner de CI com servidor de produção. O runner executa código vindo do repositório, inclusive em pull requests se o workflow permitir. Isso aumenta a superfície de ataque. O ideal é que o Cloud Server do runner tenha acesso mínimo ao que precisa: registry, cache, ambiente de staging e, quando necessário, endpoint de deploy. Se o projeto usa Docker em produção, o guia /vps-para-docker/ ajuda a pensar em separação de containers, volumes e rede antes de colocar automações mais sensíveis no mesmo ambiente.

Implantação prática no Cloud Server

A implantação de um self-hosted runner não é complexa, mas pequenos atalhos cobram preço depois. Comece com um sistema operacional LTS, atualize pacotes e crie um usuário sem privilégios administrativos permanentes. Em Ubuntu, o fluxo básico envolve apt update, criação de usuário, instalação de dependências, Docker quando necessário e registro do runner pelo painel do GitHub. O token de registro é temporário e deve ser tratado como segredo. Não salve esse token em repositório, wiki pública ou histórico compartilhado.

Sistema operacional, Docker e usuário dedicado

Um ponto de partida prático é usar Ubuntu 24.04 LTS, usuário github-runner e diretório em /opt/actions-runner ou /home/github-runner/actions-runner. O usuário pode fazer parte do grupo docker quando os workflows precisam construir imagens. Isso facilita o uso, mas aumenta risco, porque acesso ao Docker pode equivaler a acesso root em muitos cenários. Se o runner executa código de contribuidores externos, repense essa permissão.

Exemplo de preparação inicial, sem expor tokens:

sudo apt update && sudo apt upgrade -y
sudo adduser github-runner
sudo usermod -aG docker github-runner
sudo mkdir -p /opt/actions-runner
sudo chown github-runner:github-runner /opt/actions-runner

Para Docker, instale a partir do repositório oficial e fixe uma rotina de atualização. Em pipelines com build de imagens, configure também limpeza periódica. Um comando como docker system prune precisa ser usado com cuidado, porque pode remover caches úteis. Em muitos casos, uma limpeza semanal de imagens não usadas há mais de 72 horas já evita disco cheio sem destruir toda a vantagem do cache.

Registro do runner e execução como serviço

O registro é feito no GitHub em Settings, Actions, Runners. Você escolhe sistema operacional, arquitetura e copia os comandos oficiais. O runner pode operar em modo interativo, mas produção pede serviço systemd. Isso garante reinício após reboot e facilita inspeção de logs com journalctl.

Depois do registro, teste com um workflow mínimo:

name: runner-check
on: workflow_dispatch
jobs:
  check:
    runs-on: [self-hosted, linux]
    steps:
      - run: hostname
      - run: free -h
      - run: df -h

Esse teste simples confirma que o job caiu no runner correto, mostra memória disponível e revela o espaço em disco antes de rodar builds pesados. Para times que vêm de Jenkins, a lógica de agentes e labels lembra bastante a separação de nós de execução. O artigo /vps-para-jenkins-e-pipelines-ci-cd/ aprofunda essa comparação para quem mantém pipelines híbridos.

Segurança, isolamento e segredos

Self-hosted runner exige uma mudança de mentalidade: o servidor passa a executar código automatizado com acesso a rede, arquivos temporários, cache e, em muitos casos, segredos de deploy. Isso não significa que a abordagem seja insegura por natureza. Significa que o desenho precisa limitar danos. Um workflow mal configurado pode imprimir variável sensível no log, executar comando destrutivo ou usar o Docker socket para escapar do isolamento esperado.

Riscos de pipelines com acesso ao servidor

O risco cresce quando o runner aceita jobs de pull requests externos. Em projetos open source, isso pode permitir que código não confiável rode dentro da sua infraestrutura. Para repositórios privados de equipes fechadas, o risco é menor, mas ainda existe. Um commit com script malicioso, uma action de terceiro comprometida ou uma dependência alterada podem expor segredos. Por isso, revise permissões do GITHUB_TOKEN, use environments com aprovação manual para produção e limite secrets por ambiente.

Evite usar runner de organização para tudo. Um runner amplo demais pode receber workflows que não deveriam ter acesso ao mesmo contexto. Prefira runners por repositório ou por grupo de projetos com risco semelhante. Também vale separar labels: um runner com acesso a deploy de produção não deve executar testes genéricos de qualquer branch.

Hardening mínimo antes de rodar builds

No Cloud Server, aplique o básico com rigor. Use SSH por chave, desative login por senha, bloqueie root remoto, habilite firewall e mantenha portas mínimas abertas. Em muitos runners, apenas SSH administrativo é necessário. Se o servidor não precisa receber tráfego HTTP, não abra 80 e 443. Use fail2ban quando fizer sentido e monitore tentativas de login.

No sistema, mantenha atualizações automáticas de segurança ou uma janela semanal de patching. O runner deve rodar com usuário dedicado. Segredos precisam ficar no GitHub Secrets ou em um gerenciador externo, não em arquivos soltos no servidor. Se o pipeline usa chaves SSH para deploy, restrinja a chave no destino, por exemplo permitindo apenas comandos específicos ou acesso a um usuário sem privilégios amplos.

Backups também merecem nuance. Não faz sentido restaurar cache velho como se fosse dado crítico, mas faz sentido ter snapshot da configuração base do runner. Para Cloud Server, confirme no provedor quais recursos existem por plano e localidade, como snapshots, backup automático, armazenamento SSD ou NVMe e limites de tráfego. No caso da LetsCloud, por exemplo, a disponibilidade de NVMe, regiões como São Paulo, Fortaleza ou Miami e recursos de backup devem ser verificados no site oficial antes de qualquer decisão operacional.

Custos, performance e comparação com outras ferramentas

O argumento de custo do self-hosted runner é atraente, mas precisa ser calculado com cuidado. O servidor ligado 24 horas gera custo fixo. Em troca, você ganha capacidade previsível, cache persistente e controle de ambiente. A conta começa a fazer sentido quando há volume recorrente de pipelines, jobs longos ou necessidade de máquina específica. Se a equipe roda poucos workflows por semana, talvez o runner hospedado continue mais simples e econômico.

Como estimar capacidade sem benchmark exagerado

Não prometa economia sem medir. Pegue uma semana representativa e levante quantidade de execuções, tempo médio, tempo de fila, duração dos jobs mais caros e etapas que mais consomem recursos. Um exemplo: 40 execuções por dia, cada uma com 12 minutos, equivalem a 480 minutos diários de CI. Se metade desse tempo é instalação repetida de dependências, cache local e imagens pré-aquecidas podem reduzir bastante a duração. Mas se o gargalo é teste lento ou banco mal configurado, trocar o runner não resolve sozinho.

Performance também depende do tipo de CPU do provedor, política de compartilhamento, disco, rede e concorrência. Dois servidores com 4 vCPUs podem se comportar de forma diferente sob compilação sustentada. Sem benchmark com metodologia clara, trate qualquer afirmação de superioridade como hipótese. Para decisões editoriais e compras, valide com teste real do seu pipeline.

GitHub Actions, GitLab Runner e Jenkins

GitHub Actions self-hosted runner brilha quando o código e os fluxos já estão no GitHub. A integração com pull requests, environments, secrets e marketplace reduz atrito. GitLab Runner é natural para quem usa GitLab como plataforma principal, especialmente em ambientes que já concentram registry, issues e deploy por lá. Jenkins continua forte em empresas com pipelines legados, plugins específicos e necessidade de customização profunda.

A escolha não precisa ser religiosa. Uma empresa pode usar GitHub Actions para testes e Jenkins para deploy legado, ou GitLab Runner para projetos internos específicos. O ponto técnico é manter runners isolados por ferramenta e finalidade. Misturar credenciais de várias plataformas no mesmo Cloud Server cria confusão e aumenta impacto de incidente.

Ferramenta	Melhor encaixe	Operação do runner	Atenção principal
GitHub Actions self-hosted	Repositórios no GitHub, PRs, CI/CD integrado	Registro simples, labels e serviço local	Controle de secrets e workflows de terceiros
GitLab Runner	Projetos no GitLab, registry integrado, pipelines YAML	Executor shell, Docker ou Kubernetes	Escolha correta do executor e isolamento
Jenkins agents	Ambientes legados, plugins e pipelines customizados	Mais flexível, porém mais manutenção	Atualizações, plugins e credenciais antigas

Operação contínua, cache e troubleshooting

Depois que o runner está funcionando, o trabalho vira operação. O primeiro mês costuma revelar o dimensionamento real. Observe CPU steal, uso de memória, swap, espaço em disco, tempo de fila e falhas intermitentes. Um servidor que parece folgado em média pode travar em horários de pico quando dois builds Docker rodam juntos. Da mesma forma, disco com 70% de uso pode chegar a 100% em minutos durante build de imagem grande.

Métricas que você precisa acompanhar

Acompanhe uso de CPU por job, carga média, memória livre, swap usada, I/O wait e crescimento de /var/lib/docker. Para um runner com Docker, o diretório do Docker é um dos principais vilões de espaço. Configure alertas simples: disco acima de 80%, memória com swap constante, runner offline e falha repetida de serviço. Prometheus Node Exporter, Netdata ou um agente de monitoramento do provedor já ajudam bastante.

Cache deve ser tratado como acelerador, não como depósito infinito. Em Node.js, cache de npm, pnpm ou yarn pode crescer bastante. Em PHP, Composer também acumula pacotes. Em Java, Gradle e Maven consomem muitos gigabytes ao longo do tempo. Defina uma política de retenção. Por exemplo, limpar caches não acessados há 14 dias e imagens Docker não usadas há 72 horas. Teste essa política em horário seguro para não apagar artefatos necessários durante um deploy.

Problemas comuns em runners persistentes

O erro mais comum é runner offline após reboot. Resolva com serviço systemd habilitado e logs revisados. Outro problema frequente é permissão quebrada em diretórios de trabalho, geralmente causada por comandos com sudo dentro do job. Se um workflow cria arquivos como root, o próximo job pode falhar ao limpar workspace. A regra é simples: evite sudo no pipeline, exceto em runners descartáveis ou muito controlados.

Também aparecem falhas por versões divergentes. Um job instala Node 20 globalmente, outro espera Node 18. Para evitar disputa, use actions oficiais de setup, containers por job ou ferramentas como asdf. Em builds Docker, prefira Dockerfile reproduzível e tags fixas. A disciplina de ambiente reduz o clássico problema de funcionar no runner, mas falhar em produção.

Se a fila cresce, não aumente concorrência sem olhar recursos. Configurar dois jobs simultâneos em uma máquina de 2 vCPUs pode piorar tudo. Primeiro meça. Depois escolha entre upgrade vertical, mais vCPUs e RAM, ou pool horizontal, mais runners menores. Para equipes com deploy em containers, o conteúdo em /vps-para-docker/ ajuda a planejar armazenamento, rede e volumes antes de escalar CI/CD com build de imagens.

Recomendações por perfil

Dev solo

Para um desenvolvedor solo ou microprojeto, comece simples. Um Cloud Server com 2 vCPUs, 4 GB de RAM e 60 GB de SSD é suficiente para lint, testes unitários, build de frontend e deploy leve. Rode apenas um job por vez, habilite o runner como serviço e mantenha Docker somente se o pipeline realmente precisar. O foco aqui é previsibilidade, não complexidade. Use labels específicas, como self-hosted, linux e solo, para evitar confusão. Faça snapshot depois da configuração inicial, se o provedor oferecer esse recurso no plano escolhido, e documente os comandos de reinstalação.

Time pequeno

Times com 3 a 10 pessoas e vários repositórios devem pensar em 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe como base. Essa configuração permite um ou dois jobs simultâneos, desde que os workflows não sejam todos pesados. Separe runners por finalidade: um para testes rápidos, outro para Docker build ou deploy de staging. Não coloque credenciais de produção no runner genérico. Use environments do GitHub com aprovação para etapas sensíveis e monitore disco desde a primeira semana. Se o volume crescer, adicionar outro runner costuma ser mais seguro que apenas aumentar concorrência.

Produção com múltiplos repositórios

Em produção com múltiplos repositórios, monorepos ou compliance, desenhe um pool. Use servidores de 4 a 8 vCPUs, 8 a 16 GB de RAM e 100 a 200 GB de disco por nó, ajustando pela carga real. Prefira runners separados para pull requests, builds Docker, staging e produção. Quando possível, adote runners efêmeros para jobs de maior risco. Integre monitoramento, alertas e rotina de atualização. Para provedores, compare regiões, tipo de armazenamento, snapshots, backup, limites de rede e API de automação. Dados de preço, localização e recursos variáveis precisam de revisão humana na página oficial antes da compra ou publicação de ranking.