Estamos enfrentando um problema de workflow do n8n desaparecendo em 15/7/2026 às 3h30 (horário IST)
Descreva o problema/erro/pergunta
Estamos enfrentando um problema de workflow do n8n desaparecendo em 15/7/2026 às 3h30 (horário IST)
precisamos encontrar a causa raiz do problema. Por que o workflow do n8n está desaparecendo. Após a restauração do banco de dados, tudo parece estar bem
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
Compartilhe a saída retornada pelo último nó
Informações sobre sua configuração do n8n
- Versão do n8n:
- Banco de dados (padrão: SQLite):
- Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main):
- Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop):
- Sistema operacional:
Oi @Raghavendra908 Bem-vindo!
Em n8n auto-hospedado, esse tipo de desaparecimento em massa quase nunca é o n8n deletando workflows, é o banco de dados voltando para um estado anterior. Assumindo o SQLite padrão, o gatilho usual é um reinício de container, recriação ou migração de host/VPS naquele período onde o arquivo WAL do SQLite (database.sqlite-wal) não foi checkpointed ou não foi mantido junto com o banco principal, então tudo escrito desde o último checkpoint desaparece. Isso se encaixa com seu timestamp 15/7 3:30 PM IST e o restore do BD trazendo tudo de volta.
Para confirmar a causa raiz, verifique os logs do container n8n e do host por volta de 15/7 3:30 PM IST procurando por reinicialização, OOM kill ou erros de SQLite, e verifique que database.sqlite, database.sqlite-wal e database.sqlite-shm estão todos no mesmo volume persistente. A lacuna na coluna updatedAt da tabela workflow_entity vai se alinhar com o último checkpoint bem-sucedido.
Para produção, saia do SQLite para Postgres e execute backups reais em nível de servidor (pg_dump em um cron), já que SQLite é propenso exatamente a isso em reinicializações e migrações.
O diagnóstico de Anshul está perfeito, e vale a pena destacar para qualquer um que caia nesta thread mais tarde: este modo de falha (SQLite revertendo silenciosamente para um checkpoint anterior após reinicialização/OOM/migração de host) é estrutural ao executar n8n em seu BD padrão, não algo que você configurou errado. O arquivo WAL e o arquivo .sqlite principal têm que sobreviver juntos no exato mesmo volume com um checkpoint limpo, e uma reinicialização/redeploy de container é exatamente o momento que tem mais probabilidade de dar errado.
Mudar para Postgres é a solução correta. Uma pegadinha que vale a pena conhecer antes de fazer isso, já que causa confusão em quase tanta gente quanto a própria migração de BD: N8N_ENCRYPTION_KEY tem que ser fixado e nunca regenerado entre deploys. Se mudar (fácil de fazer por acidente se você não estiver explicitamente persistindo), toda credencial armazenada silenciosamente fica ilegível - então você corrige o problema de perda de dados e imediatamente bate em um problema de “por que n8n não consegue mais descriptografar minhas credenciais” em vez disso.
Divulgação completa já que estou mencionando uma forma específica de fazer isso: mantenho um template Railway de um clique que já faz isso (n8n em Postgres 17 em seu próprio volume, chave de criptografia fixada por um segredo gerado para que nunca rotacione embaixo de você, dados binários escritos em Postgres em vez de disco local do container) - kickback se aplica se você fizer deploy por meio dele: Deploy & Host n8n with Postgres | Railway . Se você estiver montando seu próprio docker-compose em vez disso, o ponto de fixação de chave de criptografia acima é a única coisa que vale a pena acertar independentemente de onde você hospeda.