Tutoriais de VPS
Montar o Coolify como plataforma de deploy auto-hospedada em uma VPS (2026): Docker, deploy automático com Git, HTTPS com Traefik e guia para evitar problemas de backup
Este tutorial explica como auto-hospedar o Coolify em uma VPS e transformar um servidor comum em uma plataforma de deploy semelhante a Vercel, Heroku ou Railway. O conteúdo cobre a escolha da configuração da VPS, o script oficial de instalação, portas e domínios, HTTPS automático com Traefik, deploy a partir de repositórios Git, variáveis de ambiente, serviços de banco de dados, backup e atualização, reforço de segurança e problemas comuns de 502, SSL e falhas de build.
Hoje em dia não gosto muito de jogar todos os projetos pequenos em um monte de plataformas diferentes.
Um projeto Next.js na Vercel, um backend no Railway, um banco de dados no Supabase, mais um Redis e uma tarefa agendada. No começo até facilita, mas quando os projetos se multiplicam, cobranças, variáveis de ambiente, domínios, logs e backups começam a se espalhar.
O Coolify resolve esse problema: você mesmo compra uma VPS e monta nela um painel de deploy semelhante a Vercel / Heroku / Railway.
Ele não é Kubernetes, nem um painel tradicional tipo BaoTa. Mais precisamente, é um PaaS auto-hospedado: conecte um repositório Git, preencha as variáveis de ambiente, vincule um domínio, clique em deploy, e o Coolify cuida do build Docker, da execução dos contêineres, do proxy reverso e do HTTPS para você.
Este artigo explica do jeito que eu explicaria para um amigo: qual VPS é adequada para rodar o Coolify, como instalar, como colocar a primeira aplicação no ar e quais armadilhas evitar desde o início.
Se você só vai fazer deploy de um site estático, Vercel e Netlify continuam sendo menos trabalhosos. O Coolify é realmente indicado para estes perfis:
| Cenário | Indicado para Coolify | Motivo |
|---|---|---|
| Vários projetos pequenos rodando a longo prazo | Indicado | Uma VPS gerencia várias aplicações, custo fixo |
| Querer auto-hospedar n8n, Umami, Postgres, Redis | Indicado | O Coolify tem templates de serviços, fácil de gerenciar |
| Ferramentas internas da empresa, painéis administrativos | Indicado | Dados e fluxo de deploy ficam no seu próprio servidor |
| Rodar apenas um site estático | Não necessariamente | Pode dar mais trabalho do que a Vercel |
| Negócio grande de alta concorrência | Com cautela | Uma VPS única não é uma plataforma de escala automática |
Meu próprio critério é simples:
- Se você tem 3 ou mais projetos para rodar, o Coolify começa a valer a pena
- Se você só quer fazer deploy de um blog, Docker Compose + Caddy puro pode ser mais leve
- Se você não quer lidar de jeito nenhum com segurança do servidor e backup, então não auto-hospede
O que o Coolify economiza é o tempo de "escrever à mão Docker Compose, proxy reverso, certificados e variáveis de ambiente para cada projeto", não a manutenção do servidor.
O Coolify em si não consome tantos recursos; o que realmente consome é o processo de build.
Por exemplo, quando você faz deploy de um projeto Next.js, CPU e memória sobem de repente durante o build; ao fazer deploy de um serviço com banco de dados, também é preciso deixar espaço para Postgres, Redis e os contêineres da aplicação.
Sugiro escolher assim:
| Uso | Configuração mínima | Configuração mais estável |
|---|---|---|
| Testes, experimentação | 2 núcleos / 2GB / 30GB SSD | 2 núcleos / 4GB / 40GB SSD |
| Rodar 2-5 aplicações pequenas | 2 núcleos / 4GB / 60GB SSD | 4 núcleos / 8GB / 80GB SSD |
| Vários projetos de produção | 4 núcleos / 8GB para começar | CPU dedicada é mais confortável |
Há um ponto fácil de passar despercebido: uma VPS barata com CPU compartilhada consegue rodar, mas o build fica lento.
Se o seu projeto faz com frequência npm install, pnpm build, a oscilação da CPU compartilhada fica bem visível. A aplicação em execução pode ir bem, mas esperar tanto a cada deploy incomoda.
Quanto ao sistema, priorize:
- Ubuntu 22.04 / 24.04 LTS
- Debian 12
- Um sistema limpo, sem instalar um monte de painéis antigos
Se essa VPS já roda Nginx, Caddy, BaoTa ou 1Panel, pense bem antes de instalar o Coolify. Porque o Coolify já vem com seu próprio proxy reverso, e o gerenciamento de portas e certificados pode facilmente conflitar com os serviços existentes.
A instalação oficial é simples, mas não se apresse a copiar o comando.
Primeiro faça login na VPS via SSH:
ssh root@your_server_ip
Atualize o sistema:
apt update && apt upgrade -y
Verifique o espaço em disco:
df -h
Verifique se as portas estão ocupadas:
ss -tlnp | grep -E ':80|:443|:8000|:6001|:6002'
O auto-hospedagem do Coolify costuma usar estas portas:
| Porta | Uso |
|---|---|
| 22 | Login SSH no servidor |
| 80 | HTTP / validação de certificado Let's Encrypt |
| 443 | Acesso HTTPS às aplicações |
| 8000 | Acesso inicial ao painel do Coolify |
| 6001 | Comunicação em tempo real |
| 6002 | Web Terminal, necessário em algumas versões |
Se você já tem o Nginx ocupando 80/443, o Traefik do Coolify não conseguirá assumir corretamente o tráfego público.
O método de instalação recomendado oficialmente é o script. Como usuário root você pode executar:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
Se você não é o usuário root, use sudo:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
O script de instalação faz várias coisas:
- Instala Docker e Docker Compose
- Cria os diretórios relacionados a
/data/coolify/ - Baixa a imagem do contêiner do Coolify
- Inicia o painel do Coolify
- Inicia o proxy reverso padrão
- Configura o banco de dados interno e os serviços necessários
Após a instalação, primeiro verifique se os contêineres subiram:
docker ps --filter "name=coolify"
Se você vir os contêineres relacionados ao Coolify no estado Up, significa que iniciou com sucesso.
Acesse no navegador:
http://your_server_ip:8000
Depois de entrar, crie uma conta de administrador. Não use uma senha fraca aqui: assim que alguém entra no painel do Coolify, basicamente consegue controlar as aplicações do seu servidor.
Na fase de testes, usar IP + 8000 serve, mas para uso a longo prazo é obrigatório vincular um domínio.
Por exemplo, você planeja:
coolify.example.com
Adicione um registro A no DNS:
coolify.example.com -> your_server_ip
No começo, sugiro deixar o Cloudflare em DNS only, ou seja, a nuvem cinza. Quando os certificados forem emitidos normalmente e tanto o painel quanto as aplicações estiverem acessíveis, então considere ativar o proxy de nuvem laranja.
Depois, nas configurações do Coolify, altere o Instance Domain para:
https://coolify.example.com
O Coolify usa o Traefik como proxy reverso por padrão e gerencia o HTTPS automaticamente. Em condições normais, você não precisa instalar o Certbot por conta própria nem escrever configurações de Nginx à mão.
Se você já tem uma camada externa de Cloudflare, atenção a duas coisas:
- Na primeira emissão do certificado, as portas 80/443 precisam estar acessíveis
- Após ativar o proxy do Cloudflare, teste o stream de logs do painel e o status de deploy para evitar problemas com WebSocket
O uso mais comum do Coolify é fazer deploy a partir de um repositório Git.
O fluxo aproximado é:
- Adicionar uma conexão GitHub / GitLab no Coolify
- Selecionar o repositório e a branch
- Selecionar o método de build, por exemplo Nixpacks, Dockerfile ou Docker Compose
- Preencher as variáveis de ambiente
- Vincular um domínio
- Clicar em Deploy
Se for um projeto Node.js comum, o Coolify geralmente consegue detectar automaticamente.
Mas para projetos de produção prefiro preparar meu próprio Dockerfile, pelo menos é mais controlável. Por exemplo, uma aplicação Node simples:
FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci
FROM node:22-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app .
EXPOSE 3000
CMD ["npm", "start"]
Depois, no Coolify, defina a porta da aplicação como 3000 e preencha o domínio:
app.example.com
Após um deploy bem-sucedido, o Coolify encaminha as requisições do domínio público para a porta interna do contêiner.
O Coolify é prático, mas as variáveis de ambiente você ainda precisa gerenciar bem.
As variáveis comuns incluem:
DATABASE_URL=postgresql://user:password@host:5432/db
REDIS_URL=redis://redis:6379
APP_URL=https://app.example.com
NODE_ENV=production
Algumas sugestões:
- Não faça commit de
.envno repositório Git - Use strings longas aleatórias para senhas de produção
- Não use a mesma senha do banco de dados e do painel
- Após alterar variáveis críticas, faça o redeploy e confira os logs
Se a aplicação não iniciar, olhe primeiro os logs de deploy; não reinstale às cegas.
O Coolify pode fazer deploy de aplicações e também de serviços, como PostgreSQL, Redis, MySQL, MongoDB, n8n, Umami e afins.
Mas não entenda isso como "um clique e nunca mais se preocupe". O mais importante em um banco de dados são os backups.
Se você fizer deploy de PostgreSQL com o Coolify, no mínimo confirme:
- Que o diretório de dados está em um Volume persistente
- Que há backups periódicos
- Que os arquivos de backup não ficam só na mesma VPS
- Que você consegue restaurar antes de atualizar
Normalmente coloco os backups em armazenamento de objetos, por exemplo Cloudflare R2, Backblaze B2, armazenamento compatível com S3.
Uma ideia simples para backup do banco de dados é:
pg_dump "$DATABASE_URL" | gzip > app-db-$(date +%F).sql.gz
Depois sincronize para o remoto com rclone:
rclone copy app-db-$(date +%F).sql.gz r2:backup-bucket/coolify/app/
Não é necessariamente a forma mais elegante, mas pelo menos é mais confiável do que "backup e banco de dados no mesmo disco da VPS".
Se logo após instalar você fechar todas as portas, é fácil se trancar para fora.
Primeiro confirme a porta SSH:
ss -tlnp | grep ssh
Depois configure o UFW:
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 8000/tcp
ufw allow 6001/tcp
ufw allow 6002/tcp
ufw enable
ufw status
Quando você já acessa o painel normalmente via https://coolify.example.com, normalmente 8000 não precisa mais ficar exposto à internet.
Você pode restringir:
ufw delete allow 8000/tcp
Se você não usa o Web Terminal, também pode restringir a 6002 conforme o caso. Mas não copie mecanicamente: primeiro confirme se a versão e os recursos atuais precisam disso.
Primeiro execute os mais importantes da abordagem de diagnóstico oficial:
docker --version
docker compose version
systemctl status docker --no-pager -l
docker ps -a --filter "name=coolify"
df -h /
ls -lt /data/coolify/source/*.log 2>/dev/null | head -5
Muitas falhas não são o Coolify em si quebrado, mas:
- O sistema é muito antigo
- O Docker não está instalado corretamente
- O disco está cheio
- A porta 8000 está ocupada
- O script não tem permissão para escrever no diretório
Primeiro veja os contêineres:
docker ps -a --filter "name=coolify"
Depois veja as portas:
ss -tlnp | grep 8000
Se o contêiner está rodando mas você não consegue acessar, verifique o security group do provedor de nuvem e o UFW. Muita gente só abre o firewall do sistema e esquece que no console do provedor de nuvem há outra camada de security group.
A causa mais comum de 502 é a porta da aplicação não bater.
Por exemplo, sua aplicação Node na verdade escuta na 3000, mas no Coolify você colocou 8080, então o Traefik encaminha para o lugar errado.
Entre no contêiner para ver a porta de escuta:
docker ps
docker logs container_name --tail=100
Na aplicação também é preciso confirmar que o endereço de escuta não está vinculado apenas a 127.0.0.1. Em um contêiner normalmente é preciso escutar em:
0.0.0.0
Verifique na ordem:
- Se o registro A do DNS aponta para esta VPS
- Se 80 e 443 estão abertas
- Se o Cloudflare está temporariamente em DNS only
- Se o domínio tem um registro AAAA apontando para um IPv6 errado
- Se o mesmo domínio está ocupado por um Nginx / Caddy antigo
Não saia apagando contêineres de imediato. Problemas de certificado quase sempre são problemas de DNS e portas.
Esse tipo de problema é muito comum em VPS com 2GB de memória.
Primeiro veja a memória:
free -h
Depois veja o OOM:
journalctl -k | grep -i "out of memory"
Como mitigação temporária você pode adicionar swap:
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
Mas a longo prazo, se você faz build com frequência de projetos frontend grandes, atualizar para 4GB ou 8GB é mais prático.
O Coolify suporta atualizações, mas em produção não clique no botão só porque viu.
Meu hábito é:
- Primeiro verificar se o negócio atual está funcionando normalmente
- Fazer backup dos dados relacionados ao Coolify e dos bancos de dados das aplicações
- Evitar horários de pico do negócio
- Após atualizar, testar o painel, o deploy, o stream de logs e o HTTPS
Se você o usa para hospedar vários projetos, atualizar o Coolify não é só atualizar um painel, mas afetar toda a plataforma de deploy.
Essas ferramentas costumam ser comparadas juntas, mas os usos são diferentes.
| Ferramenta | Para que é mais adequada |
|---|---|
| Coolify | Deploy de aplicações baseado em Git, PaaS, publicação de projetos auto-hospedados |
| 1Panel | Loja de aplicações Docker, gerenciamento de sites, painel de servidor |
| Portainer | Gerenciamento de contêineres Docker, Stack, Volume |
| BaoTa / aaPanel | Sites PHP tradicionais, LNMP, criação visual de sites |
Se sua necessidade principal é "fazer deploy assim que o código é enviado com push", o Coolify é mais prático.
Se você só quer gerenciar contêineres Docker, o Portainer é mais leve.
Se você é iniciante e vai montar um WordPress, 1Panel ou BaoTa podem ser mais diretos.
O cenário em que o Coolify mais vale a pena não é economizar alguns dólares de taxa de plataforma, mas recuperar o controle do fluxo de deploy.
Você pode rodar em uma VPS de 4 núcleos e 8GB:
- Uma aplicação frontend
- Uma API backend
- Um PostgreSQL
- Um Redis
- Um n8n
- Um Umami
- Um painel administrativo interno
Tudo isso é gerenciado no mesmo painel, com domínios, certificados, logs e registros de deploy centralizados; é realmente confortável.
Mas o preço também é claro: segurança do servidor, backup, atualização e monitoramento passam a ser sua responsabilidade.
Então eu escolheria assim:
- Só para brincar: uma VPS de 2 núcleos e 4GB pode servir
- Para uso a longo prazo: 4 núcleos e 8GB + backup automático + monitoramento
- Negócio central da empresa: não dependa só de uma máquina única; no mínimo tenha backup fora do site e um plano de migração
O Coolify é uma boa ferramenta, mas não é mágica. Ele consegue transformar uma VPS em uma plataforma de deploy, desde que você esteja disposto a manter essa VPS como um ambiente de produção de verdade.