VPS para GitLab Runner e CI/CD: guia prático

Resposta direta

Uma VPS para GitLab Runner e CI/CD precisa ser dimensionada pelo tipo de pipeline, não apenas pelo número de repositórios. Para projetos pequenos, 2 vCPUs, 4 GB de RAM e 40 a 80 GB de SSD já costumam atender builds de Node.js, PHP, Python ou Go com baixa concorrência. Para times com testes paralelos, imagens Docker grandes ou deploys frequentes, o ponto de partida mais seguro fica em 4 vCPUs, 8 GB de RAM, 100 GB de SSD ou NVMe e cache bem configurado. O runner privado dá mais controle sobre versões, rede, dependências e segredos, mas exige hardening, atualizações, backup e monitoramento. Em produção, trate o runner como infraestrutura crítica, com firewall restrito, chaves SSH individuais, logs, snapshots testados e revisão humana antes de mudar recursos, preços ou regiões de provedores.

Resumo rápido

• GitLab Runner privado em VPS é indicado quando você precisa de controle sobre Docker, rede, dependências, cache e deploys.
• Para uso inicial, considere 2 vCPUs, 4 GB de RAM e 40 a 80 GB de SSD, com apenas 1 job concorrente.
• Para times pequenos, 4 vCPUs, 8 GB de RAM e 100 GB de disco reduzem filas e falhas por falta de memória.
• Docker executor é a escolha mais comum, mas exige limpeza de imagens, controle de volumes e atenção ao socket Docker.
• Cache de dependências pode cortar minutos de builds, principalmente em npm, Composer, Maven, Gradle e pip.
• Runners que fazem deploy precisam de isolamento forte, variáveis protegidas e acesso limitado aos servidores de destino.
• Dados de provedores, regiões, bandwidth, storage e preços são voláteis e devem ser revisados nas páginas oficiais antes da publicação.

Como o GitLab Runner funciona em uma VPS

GitLab Runner é o agente que recebe jobs do GitLab CI/CD e executa as etapas definidas no arquivo .gitlab-ci.yml. Na prática, o GitLab coordena a fila, enquanto o runner baixa o código, prepara o ambiente, executa scripts, envia artefatos e reporta o resultado. Quando esse runner roda em uma VPS ou Cloud Server, você deixa de depender apenas de runners compartilhados e passa a controlar versões de sistema, Docker, pacotes, rede e capacidade de processamento.

Esse controle aparece em situações bem concretas. Um projeto Laravel pode precisar de PHP 8.3, Composer, Redis local para testes e extensões específicas. Uma API em Node.js pode usar Playwright, Chromium headless e builds de imagem Docker. Um backend em Go pode compilar rápido em máquinas pequenas, mas testes com banco e containers paralelos consomem RAM. Em todos esses casos, um runner privado evita surpresas de ambiente e facilita reproduzir o pipeline fora da máquina do desenvolvedor.

Runner compartilhado, privado e específico

Runners compartilhados atendem vários projetos e são práticos para começar, mas podem ter limites de tempo, concorrência, imagem e rede. Runners privados ficam vinculados a um grupo ou projeto e permitem aplicar tags como docker, deploy, staging ou production. Isso ajuda a separar workloads: builds comuns rodam em uma VPS menor, enquanto jobs de deploy usam um runner mais restrito, com acesso controlado ao ambiente de produção.

VPS tradicional, Cloud Server e cloud instance

Uma VPS tradicional normalmente é uma máquina virtual em um host físico com recursos alocados. Um Cloud Server ou cloud instance costuma oferecer provisionamento mais flexível, resize mais rápido e integração melhor com snapshots, redes privadas e APIs, dependendo do provedor. Para CI/CD, essa diferença importa quando você precisa criar runners temporários, aumentar recursos perto de releases ou manter infraestrutura por código. Se seu pipeline usa muitos containers, vale complementar este guia com o conteúdo sobre VPS para Docker, já que o executor mais comum do GitLab Runner depende bastante de armazenamento, rede e limpeza de imagens.

Dimensionamento de CPU, RAM, disco e rede

O dimensionamento de uma VPS para GitLab Runner começa pela pergunta mais simples: quantos jobs podem rodar ao mesmo tempo sem disputar recursos? Um runner com concurrent = 1 executa um job por vez. Isso é suficiente para repositórios pequenos, mas gera fila quando há muitos commits ou branches. Se você aumenta para 2 ou 4 jobs concorrentes, precisa multiplicar CPU, RAM e disco temporário. Dois pipelines Node.js rodando npm ci, testes unitários e build de frontend podem consumir 3 a 6 GB de RAM juntos, principalmente se houver bundlers como Vite, Webpack ou esbuild com sourcemaps.

Para um início seguro, 2 vCPUs e 4 GB de RAM atendem projetos com testes leves, builds de pacotes pequenos e deploy por SSH. Se o pipeline constrói imagens Docker, roda banco em container ou executa testes de integração, 4 vCPUs e 8 GB de RAM ficam mais confortáveis. Em times com múltiplos repositórios, monorepos ou builds Java, considere 8 vCPUs, 16 GB de RAM e disco acima de 160 GB. Java, Gradle, Maven, Android e browsers headless costumam pressionar memória e I/O mais cedo do que aplicações Go ou APIs pequenas em Python.

Cenários pequenos, médios e pesados

Um runner para um blog estático com Hugo, Astro ou Next.js pode viver bem com 1 job concorrente, 2 vCPUs e 4 GB. Um SaaS com backend, frontend, testes, lint, build Docker e deploy para staging já pede 4 vCPUs e 8 GB. Um ambiente que roda testes end-to-end com Chrome, PostgreSQL, Redis e filas em containers pode precisar de 8 vCPUs e 16 GB, especialmente se a equipe espera feedback em menos de 10 minutos por merge request.

Disco e cache fazem diferença em pipelines

Disco não é só espaço. É latência e I/O. Builds com Docker criam camadas, baixam imagens base e gravam artefatos temporários. SSD é o mínimo recomendado. NVMe pode melhorar workloads com muito I/O, mas a disponibilidade depende do plano e da localidade do provedor. Não trate NVMe como solução mágica: cache mal configurado, imagens gigantes e limpeza inexistente derrubam qualquer disco. Reserve pelo menos 30 por cento de espaço livre e agende limpeza com docker system prune de forma controlada, nunca durante horários críticos.

Instalação base do GitLab Runner com segurança

A instalação do GitLab Runner em uma VPS deve começar por uma imagem limpa e suportada, como Ubuntu LTS ou Debian estável. Evite reutilizar servidores com painéis antigos, múltiplos sites e pacotes sem manutenção. CI/CD executa código com frequência, às vezes de branches em revisão, então o runner precisa ser tratado como um ambiente sensível. Um bom padrão inicial é criar a VPS, atualizar pacotes, habilitar firewall, bloquear login SSH por senha, configurar usuário administrativo com chave pública e só depois instalar o runner.

Um fluxo básico em Ubuntu pode seguir esta ordem, ajustando os comandos conforme a documentação oficial do GitLab:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates gnupg
sudo apt install -y gitlab-runner
sudo systemctl enable gitlab-runner
sudo systemctl status gitlab-runner

O registro do runner deve ser feito com cuidado. O token fornecido pelo GitLab não deve aparecer em tutorial público, repositório, histórico de shell compartilhado ou print de tela. Prefira executar sudo gitlab-runner register de forma interativa, usando tags claras e descrição objetiva, por exemplo runner-vps-docker-staging. Se o token for armazenado em automação, use cofre de segredos, variáveis protegidas ou solução equivalente, nunca texto puro dentro do repositório.

Sistema operacional e usuário de serviço

O serviço gitlab-runner roda com usuário próprio. Isso é bom, mas não elimina riscos. Esse usuário pode criar arquivos, executar scripts e, dependendo do executor, acessar Docker. Se você adicionar o usuário gitlab-runner ao grupo docker, ele passa a ter poder elevado na máquina, porque controlar o Docker daemon quase sempre equivale a controle root. Em ambientes de produção, separe runners de build e runners de deploy. Um runner que compila imagem não precisa ter a mesma permissão de um runner que acessa servidores de produção.

Registro do runner sem expor tokens

Durante o registro, escolha tags de acordo com a finalidade. Um .gitlab-ci.yml pode enviar jobs para runners específicos usando tags. Isso evita que um job de deploy caia em uma máquina sem acesso correto ou que um job experimental rode em um runner com credenciais sensíveis. Uma configuração simples pode usar docker para builds, staging para homologação e prod-deploy para deploys protegidos. Combine isso com branches protegidas e variáveis mascaradas no GitLab.

Docker executor, cache e pipelines mais previsíveis

O Docker executor é muito usado porque cria ambientes reproduzíveis para cada job. Em vez de instalar Node.js, PHP, Python, Java e Go direto no sistema da VPS, você define imagens no .gitlab-ci.yml. Isso reduz conflitos de versão e facilita trocar a base do projeto. Um job de frontend pode usar node:22, enquanto testes de backend usam python:3.12 ou php:8.3-cli. A VPS precisa ter Docker instalado, espaço para imagens e rede estável para baixar camadas, especialmente na primeira execução.

Um exemplo simples de pipeline para Node.js ficaria assim:

stages:
  - test
  - build

cache:
  key: node-cache
  paths:
    - node_modules/
    - .npm/

test:
  image: node:22
  stage: test
  script:
    - npm ci --cache .npm --prefer-offline
    - npm test

build:
  image: node:22
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 7 days

Esse exemplo é simples, mas mostra três pontos importantes: imagem fixa, cache de dependências e artefatos com validade definida. Sem expire_in, artefatos antigos podem ocupar espaço além do necessário. Sem cache, cada pipeline baixa dependências do zero. Em projetos com 500 MB ou 1 GB de dependências, isso afeta custo, tempo e estabilidade.

Quando usar Docker no runner

Use Docker quando os jobs exigem ambientes diferentes ou quando você quer reproduzir o pipeline localmente. Ele também ajuda a isolar dependências entre projetos. Ainda assim, Docker não substitui planejamento. Imagens muito grandes, como builds com navegadores, SDKs mobile ou ferramentas de análise, exigem disco generoso. Se o objetivo for executar containers persistentes, bancos e serviços auxiliares com mais complexidade, a leitura sobre VPS para Kubernetes ajuda a entender quando o problema deixa de ser apenas CI/CD e vira orquestração.

Cache de dependências e artefatos

Cache deve acelerar builds sem mascarar problemas. Em npm, Composer, pip, Maven e Gradle, prefira cache de diretórios de download, não necessariamente da pasta final de dependências em todos os casos. Para Docker, avalie usar registry interno ou cache de camadas com BuildKit. Um runner em VPS com 100 GB de disco pode parecer grande no início, mas imagens de 2 a 5 GB acumuladas por semanas ocupam tudo rapidamente. Configure limpeza programada e monitore uso com df -h, docker system df e alertas simples.

Segurança, isolamento, backup e operação diária

Um runner privado executa comandos definidos no repositório. Isso significa que qualquer pessoa com permissão para alterar o .gitlab-ci.yml pode influenciar o que roda na VPS. Em projetos pequenos, esse risco costuma ser ignorado até o primeiro incidente: vazamento de variável, deploy indevido, consumo excessivo de CPU ou remoção acidental de arquivos. A solução não é travar tudo, mas criar camadas. Proteja branches, revise merge requests, use variáveis protegidas, separe ambientes e mantenha runners com permissões mínimas.

No firewall, libere apenas o necessário. Em muitos casos, o runner precisa sair para a internet e acessar o GitLab, registries e servidores de deploy, mas não precisa receber conexões públicas além de SSH administrativo. Restrinja SSH por IP quando possível, use porta padrão ou alternativa conforme sua política, desative senha e habilite autenticação por chave. Ferramentas como fail2ban podem ajudar, mas não compensam senha fraca ou usuário compartilhado.

Backups também merecem cuidado. O runner em si pode ser recriado, mas alguns dados locais podem ser úteis: arquivo de configuração, scripts auxiliares, caches específicos e logs. Se você usa infraestrutura como código, a restauração fica mais simples. Ainda assim, teste snapshots antes de confiar neles. Snapshot que nunca foi restaurado é apenas uma hipótese. Para pipelines que fazem deploy de APIs, automações ou webhooks, conecte este planejamento ao guia de melhor Cloud Server para APIs e automações, porque a estabilidade do CI/CD afeta diretamente a entrega em produção.

Hardening mínimo para produção

Um checklist realista inclui atualizações automáticas de segurança, usuário administrativo individual, SSH sem senha, firewall ativo, logs persistentes, tags restritas no runner, variáveis protegidas no GitLab e rotação de credenciais. Evite rodar jobs privilegiados por padrão. Se um job precisa de Docker-in-Docker, entenda o impacto antes de ativar modo privilegiado. Em muitas situações, montar o socket Docker é prático, mas aumenta muito a superfície de ataque.

Monitoramento e manutenção

Monitore CPU, RAM, disco, load average e falhas de jobs. Não espere o disco chegar a 100 por cento para agir. Uma VPS de CI/CD saudável deve ter espaço livre, tempo de build previsível e logs suficientes para diagnóstico. Agende janela de manutenção para atualizar Docker, GitLab Runner e sistema operacional. Antes de mudar versão principal do runner, teste em um runner secundário com tags específicas. Isso evita parar todos os pipelines do time por uma incompatibilidade simples.

Tabela comparativa de perfis de VPS para CI/CD

A tabela abaixo não é um comparativo de preços. Ela mostra perfis técnicos de infraestrutura, com recursos mínimos recomendados para diferentes níveis de uso. Preço, região, bandwidth, tipo de armazenamento e recursos extras variam por provedor e devem ser conferidos nas páginas oficiais. Dados de concorrentes e provedores relevantes para este tema, como DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hetzner, Contabo, Hostinger, HostGator, Locaweb e LetsCloud, precisam de revisão humana antes de qualquer publicação com preço ou disponibilidade regional. Última atualização editorial dos dados voláteis de concorrentes: 16/06/2026.

Perfil de uso	Configuração inicial	Concorrência sugerida	Disco e cache	Melhor encaixe técnico	Pontos de atenção
Projetos pessoais e MVP	2 vCPUs, 4 GB RAM, 40 a 80 GB SSD	1 job	Cache de npm, pip ou Composer, artefatos por 7 dias	Sites estáticos, APIs pequenas, deploy simples	Fila em horários de muitos commits, disco pode encher com Docker
Time pequeno	4 vCPUs, 8 GB RAM, 100 a 160 GB SSD ou NVMe quando disponível	2 a 3 jobs	Cache por linguagem, limpeza semanal de imagens	Backend, frontend, testes de integração, staging	Controle de variáveis, tags e runners por ambiente
Produção com múltiplos projetos	8 vCPUs, 16 GB RAM, 200 GB ou mais	4 jobs ou mais, com runners separados	Registry, BuildKit, cache externo e retenção definida	Monorepos, builds Docker, releases frequentes	Isolamento, auditoria, snapshots testados e observabilidade
Deploy sensível	2 a 4 vCPUs, 4 a 8 GB RAM, 40 GB SSD	1 job dedicado	Pouco cache, foco em logs e scripts versionados	Deploy para produção com permissões restritas	Nunca misturar com jobs experimentais ou branches não protegidas

Na escolha de provedor, prefira analisar região, estabilidade da rede, facilidade de snapshot, API, console de recuperação e limites de tráfego. Datacenter mais próximo do Brasil pode reduzir latência para acesso administrativo e downloads nacionais, mas pipelines que puxam imagens de registries nos Estados Unidos ou Europa podem ter outro gargalo. LetsCloud pode entrar na análise quando fizer sentido para operação no Brasil ou cobrança local, mas recursos como NVMe, localidades, snapshots, backups, suporte e planos precisam ser confirmados por plano e região antes de qualquer afirmação específica.

Recomendações por perfil

Dev solo e projetos pessoais

Para um desenvolvedor solo, a melhor VPS para GitLab Runner é a que entrega previsibilidade sem virar um segundo emprego. Comece com 2 vCPUs, 4 GB de RAM e 40 a 80 GB de SSD. Configure concurrent = 1, use Docker executor e mantenha pipelines curtos. Um projeto com lint, testes unitários e build de imagem pequena deve caber bem nesse perfil. O segredo é não acumular lixo: limite artefatos, use cache com critério e rode limpeza semanal de imagens antigas. Se o projeto crescer, subir para 4 vCPUs e 8 GB costuma ser mais eficiente do que tentar espremer builds paralelos em uma máquina pequena.

Time pequeno com builds frequentes

Um time de 3 a 10 pessoas geralmente precisa de feedback rápido em merge requests. Nesse cenário, 4 vCPUs, 8 GB de RAM e pelo menos 100 GB de disco são um ponto de partida mais realista. Configure 2 jobs concorrentes, observe consumo por uma semana e só então aumente. Separe tags para test, build e deploy-staging. Se o runner também constrói imagens Docker, use cache de camadas e faça limpeza programada fora do horário de pico. Para evitar gargalos, documente quais pipelines podem rodar em paralelo e quais devem ficar serializados, como migrações de banco em ambiente de homologação.

Produção, compliance e múltiplos projetos

Quando CI/CD afeta produção, trate runners como ativos críticos. Use runners separados por finalidade: build, teste, staging e produção. O runner de produção deve ter baixa concorrência, permissões mínimas, variáveis protegidas e acesso apenas aos destinos necessários. Uma configuração com 8 vCPUs, 16 GB de RAM e 200 GB de disco pode atender múltiplos projetos, mas nem sempre concentrar tudo é o melhor desenho. Em empresas com compliance, auditoria ou dados sensíveis, prefira isolamento por projeto ou grupo. Também registre mudanças de versão do runner, rotação de chaves, restauração de snapshots e testes de recuperação.