Quando separar o Coolify, o servidor de build e as aplicações em VPS diferentes?

Fala aí, beleza? Se você já roda o Coolify numa VPS só e percebe que o painel trava e as aplicações ficam lentas justamente na hora do deploy, esse post é pra você 🙂

Aqui o foco é decidir QUANDO dividir painel, build e execução e COMO planejar cada máquina

Não vou repetir requisitos mínimos nem instalação, isso já está no guia de instalar o Coolify em VPS, e também não vou prometer alta disponibilidade, porque separar servidores é outra coisa (já explico o porquê)

Os três papéis de servidor no Coolify: painel, deploy e build

O Coolify trabalha com três papéis de servidor, e entender isso é metade da decisão

Ele gerencia todos eles via SSH, segundo a documentação de servidores do Coolify

• localhost: é o servidor que roda a instância self-hosted do Coolify (o painel). Ele pode rodar recursos implantados, mas esses recursos dividem CPU, memória e armazenamento com o painel. Esse servidor não pode ser removido
• deployment server: servidor Linux remoto que roda apps, bancos e serviços
• build server: servidor dedicado que só gera imagens e não pode rodar recursos implantados

E o padrão?

Por padrão, build e deploy acontecem no mesmo servidor, a menos que você configure um build server separado (isso é opcional, não obrigatório)

Ou seja: se tu instalou o Coolify e fez deploy em localhost, painel, build e aplicação estão todos brigando pela mesma máquina 😛

A própria documentação de início com self-hosted avisa: se você roda builds e Coolify no mesmo servidor, precisa monitorar o uso de recursos, porque uso alto pode deixar o servidor sem resposta

Sinais de que o build está disputando CPU e RAM com suas aplicações

O sinal clássico é o seguinte: tudo vai bem até começar um deploy, e aí aplicação e painel ficam lentos ou instáveis

Por que isso acontece?

Porque o build roda no mesmo servidor que serve sua aplicação no ar

Se esse servidor for o localhost, entra o painel do Coolify na conta também

E tem mais um detalhe que pouca gente olha: o valor padrão de builds simultâneos por servidor é 2, então dois deploys ao mesmo tempo somam carga em cima de carga

O que fazer primeiro (sem gastar nada):

Antes de pensar em outra VPS, ajuste a opção Concurrent builds do servidor

Ela fica em Servers > [servidor] > Advanced e controla quantos processos de build e deploy rodam ao mesmo tempo nessa máquina

A própria documentação de gerenciamento de servidor do Coolify diz que dá pra reduzir esse número pra proteger servidor pequeno de esgotar recursos durante builds: só não esquece de clicar em Save changes depois de alterar

Isso é configuração, não compra 😀

E se continuar travando?

Aí sim vale separar:

• se o gargalo é o build, mova o build pra um build server
• se o problema é app disputando recursos com o painel, mova as aplicações pra um deployment server

Esse é exatamente o critério oficial da documentação de build servers: adicionar um build server quando os builds consomem CPU, memória ou disco demais no servidor de deploy

Como prevenir na hora de planejar:

Os limites de builds simultâneos e de fila valem para cada servidor de forma independente

Então um build server dedicado tem os próprios limites, e cada máquina precisa ser pensada com os dela

Não existe um número mágico de % de CPU ou RAM documentado que diga "agora separa", tá? Quem decide é o comportamento que tu observa nos seus deploys

Como planejar a divisão: qual separação faz sentido para cada situação

A resposta curta: separe o papel que está pesando, não todos de uma vez

Se liga nos cenários:

1. Um único servidor com o painel em localhost

É o cenário de quem está começando

O onboarding do template Coolify da Hostinger, por exemplo, pergunta se o deploy vai ser em localhost ou em servidor remoto, e localhost é indicado quando é o único servidor Coolify

Funciona bem enquanto os deploys não derrubam o resto

2. Painel separado das aplicações

Faz sentido quando os recursos implantados começam a disputar com o próprio Coolify

Os motivos oficiais pra usar deployment server separado são manter as cargas longe do painel, implantar em outra localização ou dividir cargas entre várias máquinas (a documentação também cita o uso com Coolify Cloud)

3. Build server dedicado

Quando o problema é o build em si, e não o tráfego da aplicação

O build server compila fora do servidor que hospeda a aplicação no ar: ele separa a carga de build da carga de execução, segundo a documentação do Coolify

4. Vários destinos

Aqui tem um ganho legal: o Coolify faz o build uma vez (no servidor principal ou no build server), envia a imagem pro registry e cada destino adicional só baixa a imagem publicada, sem reconstruir localmente

Isso está documentado na página Multi-server deployments do Coolify

Tome cuidado: separar não é alta disponibilidade!

Dividir papéis organiza a carga

Mas se o servidor de deploy cair, a aplicação cai junto, não tem failover mágico nessa história

E também não é proteção contra ataque, pra isso o assunto é outro, tipo prevenção de DDoS em VPS

O que um build server dedicado exige no Coolify

Esses são os requisitos oficiais:

• servidor remoto novo, sem aplicações, bancos ou serviços
• Docker Engine instalado no build server (ou permissão pro Coolify instalar)
• um registry de contêineres pra receber a imagem
• o repositório da aplicação nesse registry (ex.: ghcr.io/example/my-app)
• acesso ao repositório de código da aplicação
• mesma arquitetura de CPU do servidor de deploy (a documentação diz que o build server "should use" a mesma arquitetura)

Limitações que pegam muita gente:

Um servidor marcado como build server não pode ser escolhido como destino de deploy

E não se deve ativar essa opção em servidor que já roda aplicações, bancos ou serviços. Também não dá pra mudar pra Builds only um servidor que já tenha recursos gerenciados

Traduzindo: nada de reaproveitar aquela VPS que já tem um app rodando, hein 😛

Quais builds funcionam?

Builds Nixpacks, Railpack (Beta), Static e Dockerfile podem rodar em build server dedicado e entregar a imagem via registry

Em todos eles é obrigatório definir o nome da imagem no registry. O toggle Use a Build Server? não está disponível pra aplicações em Docker Compose

Como ligar o build server ao registry e à aplicação

O resultado esperado: o build acontece no build server e o servidor de deploy só baixa a imagem pronta

Os passos abaixo seguem as documentações de build servers e de Docker registries do Coolify

1. Marque o servidor como Builds only. Em Servers > [build server] > General, no campo Server role, escolha Builds only (as opções são Deployments only, Builds only e Deployments and builds). Sem isso, o Coolify não trata essa máquina como build server dedicado

2. Autentique os dois servidores no registry. O build server precisa fazer push e o servidor de deploy precisa fazer pull, então os dois fazem login com usuário e token:

docker login <registry-domain>

Use o mesmo usuário SSH configurado na página General de cada servidor: é no ~/.docker/config.json desse usuário que o Coolify procura a autenticação no build server. Se o repositório for privado, o login também precisa acontecer no servidor de deploy. Dá pra fazer isso pela interface também, em Servers > [servidor] > Registries

3. Configure a imagem na aplicação. Vá em General > Docker Registry e preencha o campo Docker Image com registry e repositório, por exemplo ghcr.io/example/api. Em seguida, ative o toggle Use a Build Server? na página General da aplicação

Erro comum deste passo: deixar o nome da imagem vazio: o Coolify não consegue fazer deploy com build server enquanto o Docker Image não for definido

4. Entenda o fluxo que passa a valer. O build server gera a imagem, envia pro registry e o servidor de deploy faz pull e executa essa imagem

Erro comum deste passo: build server e servidor de deploy com arquiteturas de CPU diferentes: a documentação recomenda usar a mesma arquitetura nos dois

Como validar:

No log do deploy, procure a mensagem "Found a suitable build server (<nome-do-servidor>)"

Depois confirme que a imagem apareceu no registry, que a aplicação está rodando no servidor de deploy (não no build server) e que ela abre pelo domínio configurado. Um servidor Deployments only nunca faz build, então se aparecer compilação ali, algo ficou mal configurado

Que VPS usar para cada papel: por que a Hostinger é a recomendação da Hora de Codar

Pra montar esse esquema de painel, build e deploy, a recomendação principal da Hora de Codar é a VPS da Hostinger (aviso: este artigo contém links de afiliado da Hostinger)

O motivo é simples: os recursos casam com cada tarefa desse post

• acesso root completo: necessário pra instalar o Docker e fazer o docker login no usuário certo do build server
• SSD NVMe e processadores AMD EPYC: build mexe muito com disco e CPU
• backups semanais automáticos gratuitos: ajuda a voltar atrás rápido se algo sair do rumo enquanto você reorganiza servidores
• rede de 1 Gb/s: ajuda no vai e vem de imagens entre build server, registry e deploy
• template "Ubuntu 24.04 with Coolify": já vem com o Coolify pré-instalado, ótimo pra VPS do painel, e o onboarding já pergunta se o deploy vai ser em localhost ou em servidor remoto

Planos KVM como ponto de partida:

Essas são as especificações publicadas pela Hostinger:

Plano	vCPU	RAM	NVMe
KVM 1	1	4 GB	50 GB
KVM 2	2	8 GB	100 GB
KVM 4	4	16 GB	200 GB
KVM 8	8	32 GB	400 GB

Como pensar por papel:

• painel (localhost): se ele for só painel, sem apps, a carga é a do próprio Coolify
• build server: é o papel que mais sofre com CPU, RAM e disco durante o build, então é onde vale mais folga
• deployment server: depende do que suas aplicações e bancos consomem no dia a dia

Isso é ponto de partida, não promessa de desempenho, beleza? Confira também na página da Hostinger quais planos estão disponíveis com o template Coolify

E lembra da regra de ouro: build server e servidor de deploy precisam ter a mesma arquitetura de CPU, então confirme isso antes de contratar a segunda máquina

Próximo passo: medir antes de separar

Bora fazer o teste na prática?

Vai em Servers > [servidor] > Advanced, reduz o Concurrent builds e observa como aplicação e painel se comportam no próximo deploy

Se o gargalo continuar, cria uma VPS limpa só pro papel que mais pesa (build ou aplicações), seguindo a recomendação oficial de usar servidor novo pra evitar conflito com o que já existe

Quando chegar nessa hora, dá pra conferir a VPS para este projeto e escolher o plano pelo papel que essa máquina vai assumir

Até o próximo post! =)

Perguntas frequentes

Usar o Coolify Cloud muda esse critério de separar os servidores?

Os motivos oficiais para usar um deployment server separado incluem manter cargas longe do painel, implantar em outra localização, dividir cargas entre máquinas e também o uso com Coolify Cloud. Esse post, porém, foca na instalação self-hosted em VPS, então a parte de Coolify Cloud fica fora do passo a passo aqui.

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.