Skip to main content
Verifique o Status do Replit e depois identifique onde a falha ocorre: na construção, na inicialização ou ao atender requisições. Guarde os logs da implantação com falha antes de tentar novamente. Veja Solução de problemas de publicação para detalhes de configuração.

​
A publicação falha durante o build

  1. Abra Publicação e os logs da implantação com falha.
  2. Encontre o primeiro erro acionável, não apenas a mensagem final “build failed”.
  3. Verifique o comando de build, a instalação de dependências e os caminhos de arquivo referenciados.
  4. Verifique se as variáveis de ambiente necessárias estão configuradas para a publicação. Um Preview funcionando não verifica a configuração de produção.
  5. Corrija o problema identificado, publique novamente e compare os novos logs.
Se o comando de execução estiver ausente, verifique a configuração de publicação e salve o comando pretendido antes de tentar novamente. Não republique repetidamente um build sem alterações.

​
O build é concluído, mas a inicialização ou as verificações de integridade falham

Confirme que o comando de execução inicia um servidor de longa duração, e não um processo de build que termina. Para um servidor web, verifique o endereço de bind e a configuração de porta. Ele deve aceitar conexões externas, e não escutar apenas em localhost. Leia Configuração de portas antes de alterar mapeamentos explícitos de portas. Verifique nos logs de inicialização se há secrets de produção ausentes, falhas de banco de dados ou exceções antes de o servidor começar a aceitar requisições. Não remova indiscriminadamente verificações de autenticação ou do aplicativo para fazer uma implantação passar. Diagnostique a rota com falha ou a dependência de inicialização.

​
O aplicativo publicado retorna 500 ou 502

  1. Reproduza uma requisição e registre sua hora e a URL afetada.
  2. Inspecione os logs de runtime próximos a esse horário em busca de exceções, falhas ou reinicializações.
  3. Verifique se um banco de dados ou uma API externa necessária está acessível.
  4. Compare as falhas com o uso de CPU e memória em Monitoramento.
Um 500 ou 502 é um sintoma, não prova de uma causa específica. Veja Erros de rede e de aplicativos. Se a URL replit.app funcionar, mas o domínio personalizado falhar, use o guia de domínios. Se apenas o login falhar, use o guia de autenticação.

​
O Preview funciona, mas a versão publicada não

Compare a versão publicada, os comandos de build e de execução, os secrets de produção, a seleção de banco de dados e a configuração de autenticação. Atualizar um secret do workspace não significa que o aplicativo publicado usa o mesmo valor. Depois de uma alteração direcionada na configuração de produção, publique-a e teste novamente. Antes de reimplantar uma versão mais antiga, verifique se ela é compatível com o esquema atual do banco de dados. Reimplantar código não é restaurar o banco de dados.

​
A publicação é bloqueada por uma política do workspace

Para “Public deployments are not allowed for this workspace”, peça ao administrador do seu workspace que revise a política de publicação. Não contorne a política movendo código ou dados para um workspace pessoal.

​
Ainda com falha?

Envie ao Suporte a URL do projeto, o tipo de implantação, a fase que falhou, os logs de build ou de runtime sem dados sensíveis e o horário de uma requisição com falha. Informe se o Preview e a URL publicada se comportam de forma diferente. Siga a lista de verificação para o suporte.