Coolify com problemas? Veja os erros mais comuns e como resolver
Coolify fora do ar, erro 502 ou deploy falhando? Veja causas comuns, um checklist seguro e quando solicitar suporte Coolify especializado para empresas.
Coolify facilita o deploy, mas a infraestrutura continua existindo
O Coolify simplifica a publicação de sites, APIs, workers, bancos de dados e outros serviços em servidores próprios. Ele automatiza boa parte do build, da criação de containers, do roteamento e da emissão de certificados. Ainda assim, a aplicação continua dependendo de Linux, Docker, rede, DNS, armazenamento e recursos reais da VPS.
Por isso, um Coolify fora do ar nem sempre significa defeito no painel. A causa pode estar na VPS indisponível, em um container encerrado, no Traefik sem backend saudável, em uma variável de ambiente, no banco de dados, no DNS, no SSL ou em um disco sem espaço.
O diagnóstico correto começa pela camada mais ampla e avança até a aplicação. Essa ordem reduz tentativas aleatórias e ajuda a preservar logs importantes para descobrir o que realmente aconteceu.
O que verificar quando o Coolify está fora do ar
Primeiro, identifique o alcance: somente uma aplicação falhou, todos os domínios estão indisponíveis ou nem o painel abre? Se todas as aplicações e o painel pararam ao mesmo tempo, a investigação deve começar pela VPS, pelo Docker e pelo proxy. Se apenas um projeto falhou, concentre-se no deploy, no container e nas dependências desse recurso.
1. Disponibilidade da VPS e recursos do servidor
Verifique no provedor se a instância está ligada e se existem incidentes de rede ou armazenamento. Tente acessar por SSH e confira CPU, memória, swap, espaço em disco e inodes. Uma VPS pode continuar respondendo ao ping e, mesmo assim, não ter memória ou espaço suficiente para iniciar containers.
Comandos de leitura como free -h, df -h e docker stats --no-stream ajudam a formar uma fotografia inicial sem modificar o ambiente.
2. Status dos containers e sequência de logs
Consulte os recursos no painel e compare com docker ps -a. Observe containers em estado Exited, Restarting ou unhealthy. Depois leia, nesta ordem, os logs do deploy, da aplicação, do proxy do Coolify e do serviço Docker. O primeiro erro costuma ser mais útil do que dezenas de mensagens geradas em consequência dele.
Procure por falhas de conexão, encerramento por sinal, erro de permissão, porta já utilizada, dependência ausente, falha no healthcheck e mensagens de falta de espaço. Os logs devem orientar a próxima verificação; não são apenas uma etapa para confirmar uma hipótese pronta.
3. Firewall, portas, DNS e proxy reverso
Para aplicações públicas e emissão automática de SSL, as portas 80 e 443 precisam estar acessíveis. O acesso administrativo também depende da porta SSH configurada. Verifique o firewall do provedor e o firewall do sistema, considerando que as regras de rede do Docker podem interagir com ferramentas como UFW.
Confirme se os registros A e AAAA resolvem para o servidor correto. Se a aplicação responde pelo IP e pela porta, mas falha pelo domínio, o foco passa para o DNS, para a porta interna informada ao Coolify e para a rota criada no Traefik do Coolify.
Aplicação reiniciando continuamente no Coolify
Quando existe um container reiniciando no Coolify, a política de reinício geralmente está apenas tentando recuperar um processo que encerra logo após iniciar. Aumentar o número de tentativas ou reiniciar manualmente pode esconder o padrão por alguns minutos, mas não corrige a origem.
| Causa provável | O que costuma aparecer | O que validar |
|---|---|---|
| Variável de ambiente incorreta | Configuração ausente, segredo inválido ou valor disponível no build, mas não no runtime. | Nome, valor, escopo e diferença entre variável de build e execução. |
| Banco de dados inacessível | Timeout, autenticação recusada, host não encontrado ou migração interrompida. | Host interno, porta, credenciais, rede Docker e estado do banco. |
| Limite de memória | Processo encerrado abruptamente, código 137 ou indicação de OOM. | Memória do host, limite do container, pico durante inicialização e swap. |
| Healthcheck falhando | Container marcado como unhealthy ou aplicação removida da rota. | Caminho, porta, tempo de inicialização e ferramenta usada pelo teste. |
| Dependência indisponível | Falha ao acessar Redis, fila, API externa, storage ou outro serviço interno. | Ordem de inicialização, DNS interno, rede e política de retentativa da aplicação. |
| Erro interno da aplicação | Exceção não tratada, arquivo ausente, migração incompatível ou processo principal encerrado. | Primeiras linhas do log após cada inicialização e mudanças do último deploy. |
Um healthcheck falho merece uma distinção: ele pode deixar o container marcado como não saudável e impedir o Traefik de enviar tráfego, mesmo que o processo ainda esteja ativo. Em atualizações graduais, também pode impedir que a nova versão assuma o tráfego. O teste deve consultar uma rota que represente a saúde real da aplicação e usar a porta correta.
Erros 502, 503 e 504 no Coolify
Esses códigos normalmente são exibidos por uma camada intermediária, como Traefik ou Cloudflare. Eles indicam em qual trecho da comunicação houve falha, mas não identificam sozinhos a causa final.
Coolify erro 502: resposta inválida do backend
O Coolify erro 502 aparece quando o proxy tenta falar com a aplicação e não recebe uma resposta válida. As causas mais frequentes são container encerrado durante a requisição, porta interna incorreta, processo escutando apenas em 127.0.0.1 em vez de 0.0.0.0, protocolo incompatível ou falha imediata da aplicação.
Coolify erro 503: nenhum serviço disponível
O Coolify erro 503, incluindo a mensagem “No available server”, indica que o Traefik não encontrou um backend apto a receber a requisição. O container pode estar parado, unhealthy, fora da rede esperada, ainda em deploy ou associado a uma rota e porta incorretas.
Coolify erro 504: o backend demorou para responder
O Coolify erro 504 significa que o proxy aguardou uma resposta além do tempo permitido. Investigue consultas lentas, APIs externas, filas, deadlocks, saturação de CPU ou disco, falta de conexões no banco e rotas que executam trabalho excessivo antes de responder. Aumentar o timeout sem medir a causa pode apenas prolongar a espera do usuário.
Compare o horário do erro com os logs do Traefik e da aplicação. Se houver Cloudflare na frente do servidor, observe também quem gerou a página de erro e os cabeçalhos da resposta; um 502 ou 504 na borda pode ter uma origem diferente de um erro emitido diretamente pelo proxy do Coolify.
Problemas com domínio e SSL no Coolify
Ao cadastrar uma URL com https://, o Coolify configura o proxy e solicita o certificado. Quando existe um problema com SSL no Coolify ou um problema com domínio no Coolify, verifique toda a cadeia:
- DNS incorreto: registros A ou AAAA apontam para outro servidor, mantêm IP antigo ou ainda não estão resolvendo de forma consistente.
- Proxy da Cloudflare: o modo com proxy pode interferir na validação HTTP ou TLS. Para diagnosticar, compare com o registro temporariamente em modo somente DNS ou use um desafio DNS corretamente configurado.
- Portas bloqueadas: a validação HTTP padrão exige que a porta 80 esteja publicamente acessível; HTTPS depende da porta 443 para atender os usuários.
- Certificado não emitido: os logs do proxy podem revelar falha de validação, bloqueio por WAF, limite do emissor ou problema no resolvedor configurado.
- Domínio duplicado: o mesmo hostname associado a recursos diferentes pode criar conflito de roteamento e levar o tráfego ao serviço errado.
- Traefik configurado incorretamente: labels personalizadas, porta de destino errada, middleware ou regra de host podem impedir que a rota encontre a aplicação.
Evite apagar arquivos de certificados ou reconfigurar o Traefik como primeira tentativa. Antes, confirme DNS, portas e mensagens do proxy. Alterações diretas no proxy podem afetar todas as aplicações hospedadas no servidor.
Deploy travado ou falhando no Coolify
Um erro no deploy Coolify pode ocorrer antes da imagem existir, durante a criação do container ou na validação da nova versão. Identifique em qual fase o processo parou antes de alterar o projeto.
Erro durante o build
Leia a primeira falha real do log. Erros posteriores podem ser apenas consequência de um comando anterior que não terminou.
Dockerfile incorreto
Confira caminho, contexto, nomes sensíveis a maiúsculas, estágio final, comando de inicialização, porta e arquivos copiados para a imagem.
Dependências ausentes
Valide o arquivo de lock, a versão do runtime e pacotes nativos necessários. Um build local com cache pode esconder uma dependência não declarada.
Falta de espaço
Camadas de imagem, caches de build e logs consomem disco. Confirme uso e inodes antes de qualquer limpeza; volumes e imagens em uso não devem ser removidos às cegas.
Problema com GitHub
Revise acesso do GitHub App ou deploy key, repositório e branch selecionados, webhook, token e alcance das permissões.
Permissões
Erros ao copiar, executar ou gravar podem vir do usuário definido na imagem, de bind mounts ou de arquivos com proprietário incompatível.
Timeout
Builds longos podem esgotar o tempo disponível, mas também podem indicar download instável, etapa bloqueada ou servidor saturado.
Arquitetura incompatível
Uma imagem criada apenas para amd64 não executa em uma VPS arm64, e o inverso também vale. Confirme a plataforma oferecida pela imagem.
Banco de dados e volumes: onde o risco é maior
Containers são substituíveis; dados de produção não. Arquivos importantes gravados apenas dentro da camada do container podem desaparecer quando uma nova versão o substitui. No Coolify, configure volume Docker ou bind mount com o caminho de destino correto para tudo que precisa sobreviver aos deploys.
| Risco | Consequência possível | Controle recomendado |
|---|---|---|
| Volume não persistente | Uploads, arquivos ou dados somem após recriação do container. | Mapear cada diretório de dados para volume ou bind mount documentado. |
| Permissão incorreta | Aplicação ou banco não inicia, não grava ou cria arquivos com proprietário inesperado. | Conferir usuário do container, UID/GID e permissões no ponto de montagem. |
| Disco cheio | Falhas de escrita, banco interrompido, deploy travado e possível corrupção. | Monitorar espaço, inodes, crescimento de logs, volumes e backups locais. |
| Banco inacessível | Aplicação reinicia, retorna erro ou acumula requisições. | Validar serviço, rede Docker, hostname interno, porta, credenciais e limite de conexões. |
| Backup inexistente | Uma exclusão, falha de disco ou alteração equivocada pode se tornar irreversível. | Manter cópia fora da VPS, política de retenção e teste periódico de restauração. |
Um backup presente no mesmo disco não protege contra perda da VPS. O Coolify oferece recursos de backup programado para cenários compatíveis e integração com armazenamento S3, mas a configuração só é confiável quando o arquivo é verificado e a restauração é testada.
Checklist de diagnóstico rápido do Coolify
Antes de solicitar suporte Coolify, reúna estas informações:
- 1Defina se a falha afeta o painel, todas as aplicações ou apenas um recurso.
- 2Confirme no provedor se a VPS está ligada e acessível pela rede e por SSH.
- 3Registre CPU, memória, swap, espaço em disco e inodes no horário da falha.
- 4Liste containers parados, reiniciando ou unhealthy e anote a contagem de reinícios.
- 5Salve os logs do deploy, da aplicação, do banco, do Docker e do proxy no mesmo intervalo de tempo.
- 6Compare variáveis de ambiente e configurações com a última versão que funcionou, sem expor segredos.
- 7Confirme a porta em que a aplicação escuta e a porta informada ao Coolify.
- 8Valide registros A e AAAA, IP de destino, Cloudflare, portas 80 e 443 e domínio cadastrado.
- 9Verifique o healthcheck: caminho, porta, dependências e tempo necessário para a aplicação iniciar.
- 10Confirme volume persistente, permissões, estado do banco e existência de backup restaurável.
- 11Registre a mudança mais recente: deploy, atualização, DNS, certificado, firewall ou aumento de tráfego.
- 12Evite limpeza do Docker, exclusão de volumes ou recriação do banco até entender o impacto.
Quando é melhor contratar suporte especializado
Vale buscar consultoria Coolify quando a aplicação está em produção, a indisponibilidade afeta clientes, não existe backup validado, há risco para banco de dados ou o problema envolve várias camadas ao mesmo tempo. Também é recomendável escalar quando o erro volta após cada deploy ou quando ninguém responsável pelo ambiente domina Linux, Docker e Traefik.
Mudanças incorretas podem aumentar o tempo de parada, trocar uma indisponibilidade parcial por uma falha geral ou causar perda de dados. Um diagnóstico especializado relaciona métricas, estado dos containers, logs, rede, proxy e mudanças recentes antes de propor uma correção.
A Jupiter TI oferece diagnóstico de servidores, suporte ao Coolify, correção de deploys, análise de containers, configuração de Docker e Traefik, correção de DNS e SSL, monitoramento, backup, otimização de VPS e suporte Linux. O atendimento é remoto para empresas em todo o Brasil.
Para ambientes que precisam de uma análise mais ampla, conheça também os serviços de servidores web, cloud computing e consultoria de TI da Jupiter TI.
Fontes técnicas para aprofundar o diagnóstico
Este guia foi revisado em 31 de julho de 2026 com base na documentação oficial. A interface e o comportamento podem variar conforme a versão do Coolify, o proxy escolhido e a arquitetura do ambiente.
Perguntas frequentes
O que verificar primeiro quando o Coolify está fora do ar?
Confirme se a VPS responde, verifique CPU, memória e disco, consulte o estado dos containers e compare os logs do Coolify, da aplicação, do Docker e do proxy. Depois valide firewall, portas 80 e 443, DNS e a rota configurada no Traefik.
Por que uma aplicação fica reiniciando no Coolify?
As causas frequentes incluem variável de ambiente inválida, falha ao conectar ao banco, encerramento por falta de memória, dependência indisponível ou erro interno que finaliza o processo principal. O motivo deve ser confirmado nos logs e no estado do container antes de mudar a política de reinício.
Qual é a diferença entre os erros 502, 503 e 504 no Coolify?
O 502 geralmente indica que o proxy não recebeu uma resposta válida da aplicação; o 503 costuma aparecer quando não existe backend disponível ou saudável; e o 504 indica que o backend demorou além do limite para responder. A origem exata depende dos logs do Traefik, do container e da aplicação.
Por que o SSL do Coolify não é emitido?
Verifique se o domínio aponta para o IP correto, se as portas 80 e 443 estão acessíveis, se um proxy como o da Cloudflare interfere na validação e se o mesmo domínio não está associado a outro recurso. Os logs do proxy mostram a resposta do emissor do certificado.
Os dados continuam salvos depois de um novo deploy?
Somente dados gravados em armazenamento persistente corretamente configurado, como volume Docker ou bind mount. Arquivos mantidos apenas na camada gravável do container podem desaparecer quando ele é substituído. Banco de dados também precisa de backup externo e restauração testada.
A Jupiter TI oferece suporte remoto para Coolify?
Sim. A Jupiter TI atende empresas em todo o Brasil com diagnóstico de servidores, suporte ao Coolify e Docker, correção de deploys, análise de Traefik, DNS e SSL, além de backup, monitoramento e otimização de VPS.
Jupiter TI
Precisa de suporte Coolify para encontrar a causa do problema?
Seu Coolify está fora do ar, apresentando erros ou reiniciando aplicações? A Jupiter TI pode analisar o ambiente, identificar a causa e corrigir o problema com segurança. Solicite um diagnóstico técnico.