VPS para Jenkins e pipelines CI/CD

Resposta direta

Uma VPS para Jenkins deve ser dimensionada pelo número de builds simultâneos, pelo tipo de compilação e pelo uso de Docker. Para um ambiente pequeno, comece com 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Para times com pipelines paralelos, agentes Docker e builds de aplicações Java, Node.js ou containers, o ponto mais seguro costuma ser 4 vCPUs, 8 GB de RAM e 120 GB de SSD ou NVMe. Em produção, separe o controlador Jenkins dos agentes de build sempre que possível, limite o acesso externo com firewall, use HTTPS, proteja credenciais e mantenha backup frequente do diretório JENKINS_HOME. A VPS funciona bem para CI/CD quando há disciplina operacional: atualizações planejadas, limpeza de artefatos, monitoramento de disco e revisão periódica de plugins.

Resumo rápido

• O Jenkins em VPS é indicado quando a equipe quer controle sobre plugins, versões de Java, Docker, runners, credenciais e integrações com Git, registry e ambientes internos.
• Para testes pequenos, 2 vCPUs e 4 GB de RAM já permitem pipelines simples, mas builds paralelos ficam limitados rapidamente, principalmente com Maven, Gradle, npm ou Docker BuildKit.
• Times com 3 a 8 desenvolvedores devem considerar 4 vCPUs, 8 GB de RAM e disco de 120 GB, com retenção curta de artefatos e limpeza automática de workspaces.
• Docker facilita padronizar builds, mas consome disco com camadas, imagens antigas, volumes temporários e cache de dependências. Uma política semanal de limpeza evita panes por falta de espaço.
• O controlador Jenkins não deveria executar todos os builds pesados. Agentes dedicados reduzem risco, isolam workloads e permitem escalar sem reconstruir a instalação principal.
• Segurança não é opcional: firewall, SSH com chave, HTTPS, plugins atualizados, usuários sem privilégios excessivos e backup testado reduzem a chance de incidente operacional.
• Se sua equipe também avalia runners GitLab, o guia de VPS para GitLab Runner e CI/CD ajuda a comparar modelos de execução antes de padronizar a esteira.

Como Jenkins funciona em uma VPS

Jenkins roda com uma arquitetura relativamente simples, mas a forma como ela é implantada muda bastante o consumo da VPS. O componente principal é o controlador, antigo master, responsável pela interface web, configuração dos jobs, fila de execução, plugins, credenciais e histórico. Os builds podem rodar nesse mesmo servidor ou em agentes separados. Para laboratório, colocar tudo na mesma VPS é aceitável. Para produção, essa escolha precisa ser tratada como exceção, não como padrão eterno.

O diretório mais sensível é o JENKINS_HOME, normalmente em /var/lib/jenkins quando instalado via pacote no Linux. Ali ficam jobs, credenciais criptografadas, histórico de builds, configurações de plugins, workspaces e parte dos artefatos. Se esse diretório crescer sem controle, uma VPS de 80 GB pode encher em poucos dias. Um pipeline que gera imagens Docker de 1,2 GB, mantém 20 execuções por branch e possui 8 branches ativas pode consumir dezenas de gigabytes apenas com histórico e cache.

Controlador, agentes e executores

O número de executores define quantos builds rodam ao mesmo tempo em um nó. Em uma VPS com 2 vCPUs, configurar 4 executores parece tentador, mas costuma piorar o tempo total quando as tarefas são pesadas. Dois builds Java rodando testes unitários com Maven podem saturar CPU e memória. Em Node.js, npm ci e bundlers como Vite ou Webpack também pressionam disco e CPU, especialmente quando há cache frio.

Quando separar builds do servidor principal

A separação fica mais atraente quando a equipe usa Docker, compila imagens, roda testes de integração ou executa pipelines com browsers headless. O controlador pode ficar em uma VPS menor, por exemplo 2 vCPUs e 4 GB, enquanto agentes de build usam máquinas de 4 vCPUs e 8 GB ou mais. Essa arquitetura reduz o impacto de um build travado, facilita manutenção e permite trocar agentes sem mexer nas credenciais e na configuração central. Se Docker for parte central da esteira, vale ler também o guia de VPS para Docker, porque os gargalos de rede, disco e isolamento aparecem nos dois cenários.

Dimensionamento de CPU e RAM para builds paralelos

O dimensionamento do Jenkins começa pela pergunta que muita gente deixa para depois: quantos builds precisam rodar ao mesmo tempo sem transformar a fila em um gargalo? Uma VPS pequena pode hospedar Jenkins, Git webhook, alguns jobs e testes leves. O problema aparece quando a equipe passa de um repositório para cinco, adiciona pull requests, cria pipelines por branch e começa a publicar imagens a cada merge. Nesse ponto, a conta deixa de ser apenas memória do Jenkins e vira capacidade de execução paralela.

Como regra prática, reserve 1 vCPU por build leve e 2 vCPUs por build pesado. Um build leve pode ser lint, testes rápidos de API ou empacotamento simples. Um build pesado envolve compilação Java, testes de integração, build de imagem Docker, execução de Cypress ou Playwright, ou análise estática com ferramentas que varrem muitos arquivos. A memória segue lógica parecida: 1 GB por build leve pode funcionar, mas builds Java e containers costumam pedir 2 GB a 4 GB por execução quando o pipeline roda com conforto.

Regra prática por tipo de pipeline

Para um Jenkins com 2 executores e pipelines simples, 2 vCPUs e 4 GB de RAM são o mínimo realista. Abaixo disso, o sistema operacional, o Java do Jenkins e os processos de build competem por recursos o tempo todo. Em uma VPS com 1 GB de RAM, até a interface pode responder, mas o primeiro mvn test ou docker build já cria pressão de memória. Swap ajuda a evitar queda imediata, mas torna o pipeline lento e imprevisível.

Para 3 a 5 builds simultâneos, 4 vCPUs e 8 GB de RAM formam um ponto equilibrado. Um time pequeno consegue rodar jobs de pull request, deploy em staging e builds agendados sem fila constante. Para 6 a 10 builds simultâneos, pense em 8 vCPUs e 16 GB de RAM, de preferência com agentes separados. Se todos os builds rodam no mesmo host, qualquer pico derruba a experiência de todo o time.

Exemplos de tamanhos para produção

Um time com aplicação Node.js, API em Go e deploy via Docker pode começar com controlador de 2 vCPUs e 4 GB, mais um agente de 4 vCPUs e 8 GB. Já um time com monorepo Java, testes de integração e publicação de imagens tende a precisar de 8 vCPUs e 16 GB para o agente principal. Se há builds noturnos pesados, mantenha executores separados para jobs agendados. Assim, um teste longo de madrugada não bloqueia hotfixes pela manhã.

Docker, agentes e isolamento dos pipelines

Docker combina muito bem com Jenkins, mas não deve ser tratado como mágica. Ele resolve padronização de ambiente, não elimina consumo de CPU, RAM e disco. Em uma VPS, o padrão mais comum é instalar Jenkins no host e permitir que pipelines chamem o Docker daemon local. Isso simplifica a configuração, permite usar docker build, docker compose e testes com serviços temporários, mas aumenta a responsabilidade sobre permissões. Um usuário com acesso ao socket Docker geralmente consegue escalar privilégios no host.

Uma alternativa é executar agentes Jenkins em containers. Nesse modelo, o controlador agenda jobs em agentes efêmeros ou semi-permanentes, cada um com ferramentas específicas. Um agente pode ter Java 21 e Maven, outro Node.js 22, outro Docker CLI e BuildKit. Essa separação reduz conflitos de versão e evita que a instalação principal acumule SDKs, pacotes e bibliotecas. Na prática, uma VPS que roda três stacks diferentes fica mais previsível quando cada pipeline usa uma imagem controlada.

Builds com Docker no mesmo host

Se o Docker roda no mesmo host, configure limites e rotina de limpeza. Use imagens base enxutas, evite copiar diretórios desnecessários para o contexto de build e mantenha .dockerignore bem escrito. Um repositório que envia node_modules, logs e diretórios de cobertura para o build context pode transformar um build de 2 minutos em 12 minutos. Também é comum ver VPS com 200 GB de disco lotando porque imagens antigas nunca foram removidas.

Um comando operacional simples, como docker system df, ajuda a enxergar uso de imagens, volumes e cache. Para limpeza controlada, docker builder prune e docker image prune podem entrar em uma janela semanal, nunca sem entender o impacto. Em ambientes com builds frequentes, prefira registry interno ou cache remoto quando possível, principalmente para imagens grandes.

Agentes dedicados para workloads pesados

Agentes dedicados são úteis quando os builds exigem privilégios, ferramentas específicas ou consumo imprevisível. Um agente para builds Docker pode ter 4 vCPUs, 8 GB de RAM e 100 GB de disco, enquanto o controlador fica protegido em uma VPS menor. Outro agente pode ser dedicado a testes com navegador, que costumam consumir memória e arquivos temporários. O ganho não é apenas desempenho. É governança. Se um pipeline mal escrito travar, você reinicia o agente sem derrubar a interface, credenciais, webhooks e histórico de outros projetos.

Armazenamento, cache e rede para Jenkins

Disco é um dos gargalos mais subestimados em Jenkins. Muita equipe escolhe a VPS olhando CPU e RAM, depois descobre que o problema real está em workspaces, artefatos, logs, dependências e imagens Docker. O Jenkins grava muito arquivo pequeno, lê dependências repetidamente e mantém histórico por job. Em pipelines com Maven, npm, Gradle, Composer ou Docker, o volume de cache cresce rápido. Por isso, SSD é o mínimo aceitável para produção, e NVMe pode ajudar em cargas com muito I/O, desde que esteja disponível no plano e na localidade escolhidos.

O tamanho inicial depende da retenção. Para laboratório, 40 GB a 60 GB bastam se os builds forem simples. Para time pequeno, 120 GB é mais realista. Para builds com imagens Docker, artefatos grandes ou múltiplos repositórios, 200 GB pode deixar de ser exagero e virar margem operacional. O erro comum é guardar tudo para sempre. Jenkins permite definir descarte de builds antigos por quantidade ou por dias, por exemplo manter as últimas 20 execuções ou apenas 14 dias de histórico para branches temporárias.

O que consome disco no Jenkins

O JENKINS_HOME concentra configurações e histórico, mas o consumo pesado costuma aparecer em três lugares: workspaces, artefatos e cache de ferramentas. Um job Maven pode baixar centenas de megabytes para o repositório local. Um job Node.js recria dependências em node_modules, gera cache de pacote e ainda produz bundle. Um build Docker mantém camadas intermediárias e imagens antigas. Some isso a logs de pipeline e relatórios de teste, e uma VPS sem alerta de disco vira risco.

Uma boa prática é separar o volume do Jenkins do volume de Docker quando o provedor permite anexar discos ou volumes extras. Mesmo em uma VPS simples, monitore /var/lib/jenkins, /var/lib/docker e /tmp. Configure alerta quando o uso passar de 75 por cento, porque a partir de 90 por cento alguns serviços começam a falhar de forma estranha.

Latência, transferência e pulls de imagens

Rede também pesa. Jenkins baixa dependências, clona repositórios, puxa imagens de registry e envia artefatos. Para times no Brasil, datacenter nacional pode reduzir latência da interface e dos webhooks, mas o ganho depende de onde estão Git, registry e usuários. Se o Git está no GitHub e o registry em nuvem internacional, parte do tráfego continuará saindo do país. Provedores como DigitalOcean, Vultr, AWS Lightsail, Linode/Akamai, Hetzner e LetsCloud podem atender cenários de Jenkins, mas regiões, tráfego, storage e preço mudam com frequência e precisam ser conferidos nas páginas oficiais antes de uma recomendação comercial.

Segurança, hardening e acesso ao Jenkins

Jenkins concentra credenciais de deploy, tokens de registry, chaves SSH, webhooks e permissões para publicar software. Isso transforma uma VPS de CI/CD em alvo sensível. O primeiro passo é reduzir exposição. A interface web não deveria ficar aberta para a internet inteira sem camada de proteção. Use firewall permitindo apenas portas necessárias, normalmente 22 para SSH restrito, 80 e 443 para HTTP e HTTPS quando houver proxy reverso, e 8080 apenas internamente ou bloqueada por padrão. Se possível, coloque Jenkins atrás de Nginx ou Caddy com TLS válido.

SSH deve usar chave, não senha. Desabilite login direto como root, crie usuário administrativo com sudo e mantenha atualizações de segurança ativas. Fail2ban pode ajudar contra tentativas repetidas, mas não substitui firewall bem configurado. Para uma visão mais ampla de boas práticas, o guia de VPS com firewall e hardening de segurança cobre regras de acesso, SSH, atualizações e superfície de ataque em servidores Linux.

Firewall e exposição mínima

Uma regra simples funciona bem: exponha só o que alguém realmente precisa acessar. Se a equipe usa VPN, libere Jenkins apenas para a rede privada. Se precisa acesso externo, use HTTPS, autenticação forte e, se possível, uma camada adicional como SSO ou proxy autenticado. Webhooks de Git podem chegar por endpoints específicos, mas isso não significa liberar administração sem controle. Também revise cabeçalhos, certificados e redirecionamento de HTTP para HTTPS.

Jenkins possui permissões internas, mas muita instalação começa com usuários administrativos para todo mundo. Evite isso. Crie papéis por equipe, separe quem administra plugins de quem apenas executa jobs e reduza acesso a credenciais. Um token de deploy em produção não precisa estar disponível para um job experimental de branch.

Credenciais, plugins e permissões

Plugins aumentam poder do Jenkins, mas também ampliam risco. Instale apenas o necessário, remova plugins abandonados e acompanhe avisos de segurança. Antes de atualizar tudo em produção, teste em uma cópia ou janela planejada. Um plugin quebrado pode impedir jobs críticos, e uma atualização apressada pode mudar comportamento de pipelines.

Credenciais devem ficar no gerenciador do Jenkins, nunca em arquivos de repositório ou variáveis escritas em logs. Pipelines precisam mascarar segredos e evitar comandos que imprimam ambiente completo. Também é prudente separar credenciais por ambiente: staging não deve usar o mesmo token de produção. Essa divisão reduz dano quando um job ou plugin se comporta mal.

Backup, atualização e operação contínua

Rodar Jenkins em VPS exige rotina. A instalação pode começar como um servidor pequeno para automatizar deploys, mas logo vira peça central do fluxo de desenvolvimento. Se ela para, merges atrasam, releases esperam e hotfixes ficam mais lentos. Por isso, backup e manutenção devem ser pensados no dia da implantação, não depois do primeiro incidente.

O backup mais importante é do JENKINS_HOME. Ele deve incluir configurações de jobs, pipelines quando armazenados no Jenkins, credenciais, chaves usadas pelo serviço, configurações globais e histórico que a empresa decidiu preservar. Se os Jenkinsfiles ficam no Git, melhor. Isso reduz dependência do servidor e facilita reconstrução. Mesmo assim, credenciais, plugins e configurações do controlador continuam no host. Um snapshot da VPS ajuda em restauração rápida, mas não substitui backup versionado e testado.

O que precisa entrar no backup

Inclua /var/lib/jenkins, arquivos de configuração do proxy reverso, scripts de automação, lista de plugins e documentação de portas, DNS e certificados. Se Docker estiver no mesmo host, decida se imagens e volumes precisam de backup. Na maioria dos pipelines, imagens podem ser reconstruídas, mas volumes com cache ou dados temporários não merecem backup longo. O segredo é separar o que é reconstituível do que é crítico.

Teste restauração em uma VPS isolada ao menos uma vez por trimestre. Um backup que nunca foi restaurado é uma aposta. Em testes, valide login, credenciais, jobs principais, conexão com Git e execução de um pipeline simples. Se o tempo de recuperação aceitável é 2 horas, o procedimento precisa ser documentado e treinado para caber nesse prazo.

Monitoramento e manutenção preventiva

Monitore CPU, RAM, swap, disco, quantidade de executores ocupados, fila de builds e tempo médio de pipeline. Um aumento gradual no tempo de npm ci ou docker build pode indicar cache ruim, disco lento ou rede saturada. Logs também merecem rotação. Jenkins, Nginx, sistema operacional e Docker podem produzir arquivos grandes em poucos dias.

Atualizações devem seguir janela definida. Atualize Jenkins LTS, Java, plugins e sistema operacional com plano de rollback. Em ambientes pequenos, uma janela quinzenal ou mensal já reduz risco. Em produção mais crítica, mantenha um controlador secundário de teste para validar atualizações. O objetivo não é transformar a VPS em uma plataforma complexa demais, mas evitar que uma ferramenta de automação dependa de improviso.

Tabela de dimensionamento para Jenkins em VPS

A tabela abaixo usa perfis práticos de uso, não preços de provedores. Valores comerciais, tráfego incluso, regiões, tipo de armazenamento e recursos como snapshots variam bastante entre fornecedores e precisam de revisão humana antes de publicação em comparativos. Para Jenkins, o melhor ponto de partida é mapear número de repositórios, builds simultâneos, tamanho dos artefatos e uso de Docker. Depois, escolha uma VPS ou Cloud Server com margem para picos, porque CI/CD costuma crescer junto com o time.

Perfil de uso	Recursos sugeridos	Execução recomendada	Armazenamento	Exemplo prático
Laboratório ou dev solo	2 vCPUs, 4 GB RAM	Controlador e builds no mesmo host, 1 a 2 executores	60 GB SSD	Projetos pessoais, deploy em staging, testes unitários leves e 1 imagem Docker por pipeline
Time pequeno	4 vCPUs, 8 GB RAM	Controlador com agentes locais ou 1 agente dedicado, 2 a 4 executores	120 GB SSD ou NVMe quando disponível	3 a 8 devs, múltiplos repositórios, builds Node.js, Go, PHP ou Java moderado
Produção com Docker pesado	8 vCPUs, 16 GB RAM	Controlador separado dos agentes, limpeza de Docker e cache monitorado	200 GB SSD ou NVMe quando disponível	Build de imagens, testes de integração, publicação em registry e pipelines por pull request
Produção com muitos times	Controlador 2 vCPUs e 4 GB, agentes 8 vCPUs e 16 GB ou mais	Agentes separados por stack, filas e permissões por equipe	200 GB ou volumes separados	Monorepos, jobs noturnos, testes com navegador, deploy em staging e produção

Na escolha entre VPS tradicional e Cloud Server, o ponto central é elasticidade. Uma VPS tradicional pode ser suficiente quando a carga é previsível e o upgrade não é frequente. Um Cloud Server facilita aumentar CPU, RAM ou disco, dependendo do provedor, e pode entregar melhor operação quando o time cresce rápido. LetsCloud pode ser considerada quando a localização, cobrança e disponibilidade de plano fizerem sentido para o público brasileiro, mas recursos como NVMe, snapshots, backup, suporte e regiões devem ser confirmados no site oficial antes de qualquer afirmação específica.

Também pense no modelo de falha. Se tudo roda em uma única VPS, um problema de disco, upgrade mal sucedido ou plugin incompatível para a esteira inteira. Com controlador separado e agentes descartáveis, a recuperação é mais simples. Não é necessário montar uma arquitetura enorme no primeiro dia. Mas é inteligente deixar espaço para evoluir sem reinstalar tudo.

Recomendações por perfil

Dev solo e laboratório

Para um desenvolvedor solo, uma VPS de 2 vCPUs, 4 GB de RAM e 60 GB de SSD é um bom começo. Instale Jenkins LTS, Java compatível, Git, Docker se necessário e um proxy reverso com HTTPS. Use no máximo 1 ou 2 executores para evitar que builds simultâneos deixem o painel lento. Esse perfil funciona bem para validar Jenkinsfiles, automatizar deploy em staging e testar integração com GitHub ou GitLab. Configure retenção curta, como 10 builds por job, e rode limpeza de Docker semanalmente. Não guarde segredos em arquivos do repositório.

Time pequeno com builds diários

Para um time de 3 a 8 pessoas, comece em 4 vCPUs, 8 GB de RAM e 120 GB de SSD. Esse tamanho permite 2 a 4 builds simultâneos, dependendo da stack. Se o time usa Docker em todos os pipelines, avalie um agente separado para builds de imagem e mantenha o controlador mais limpo. Configure permissões por usuário, backup diário do JENKINS_HOME e alerta de disco em 75 por cento. Esse perfil costuma atender aplicações web, APIs, jobs de lint, testes unitários, deploy em staging e publicação moderada em registry.

Produção com múltiplos repositórios

Em produção com vários repositórios, pipelines por pull request e builds Docker pesados, evite concentrar tudo em uma única VPS. Use um controlador pequeno e estável, por exemplo 2 vCPUs e 4 GB, e agentes de 8 vCPUs e 16 GB para execução. Separe agentes por linguagem ou criticidade: Java e testes de integração em um grupo, Node.js em outro, Docker build em outro. Mantenha backup testado, atualização planejada e política de plugins. Para equipes maiores, a pergunta deixa de ser se Jenkins roda em VPS e passa a ser como manter previsibilidade, isolamento e recuperação rápida sem perder controle operacional.