VPS para runners de CI/CD

Um servidor próprio para builds e testes se paga assim que os minutos gratuitos do GitHub Actions ou do GitLab CI deixam de bastar. Um runner próprio não tem limite de tempo, e nele ficam os caches de dependências e de imagens Docker — ou seja, os builds seguintes rodam várias vezes mais rápido. O mesmo VPS também serve como ambiente de trabalho remoto ou ambiente de testes.

Núcleos e memória: o build precisa de muito, por pouco tempo

Compilação, build do frontend e execução de testes se paralelizam entre os núcleos, por isso, para um runner, o número de núcleos importa mais do que para um servidor web. Referências:

• 2 núcleos e 4 GB — projetos pequenos em Node.js, Python ou PHP, linters e testes unitários;
• 4 núcleos e 8 GB — build de imagens Docker, frontend com Webpack ou Vite, testes de integração com banco de dados;
• 8 núcleos e 16 GB — compilação de Go, Rust, Java ou C++, builds de Android, tarefas em paralelo.

Se você faz poucos builds por dia, o servidor passa a maior parte do tempo parado. Aí ajuda a cobrança por hora: um servidor potente sobe durante o trabalho e é excluído depois, e você paga só pelas horas. Muitos provedores permitem fazer isso via API, então o runner pode ser ligado automaticamente.

Disco: os caches ocupam mais do que parece

Imagens Docker, cache de npm, pip, Maven ou Gradle e artefatos de build ocupam dezenas de gigabytes rapidinho. Escolha NVMe a partir de 50–80 GB e configure a limpeza: docker system prune agendado e prazo de retenção para os artefatos. A velocidade do disco influencia diretamente o tempo de instalação das dependências — em um disco lento, isso pode levar mais tempo que o próprio build.

Como conectar o runner

• GitHub Actions — o self-hosted runner é instalado com um único comando a partir das configurações do repositório ou da organização e roda como serviço.
• GitLab CI — gitlab-runner com executor Docker: cada job roda em um contêiner limpo, e as imagens ficam em cache no servidor.
• Gitea, Forgejo, Woodpecker, Drone — alternativas leves, se você também hospeda o próprio repositório no seu servidor; veja também VPS para GitLab.

Virtualização e segurança

Builds com Docker exigem KVM: em virtualização por contêineres, o Docker muitas vezes nem inicia ou funciona com restrições (mais na página VPS para Docker). Não conecte um self-hosted runner a repositórios públicos: um pull request de qualquer pessoa poderá executar qualquer código no seu servidor. Passe os segredos por variáveis do CI em vez de guardá-los no disco, e atualize o runner junto com o sistema.

Onde hospedar

Um servidor mais perto do seu Git hosting e do registro de imagens baixa as dependências mais rápido. Para GitHub e Docker Hub, servidores na Europa e nos EUA são práticos. Configure com antecedência um espelho ou um proxy de cache do registro: os builds ficam mais rápidos e não dependem da disponibilidade do registro externo.