Diagnóstico honesto
n8n lento, Evolution API caindo, servidor estourando memória — a maioria desses problemas é uma mistura de configuração, versão desatualizada ou recurso insuficiente. Aqui vai o diagnóstico honesto de cada um, sem prometer mágica.
Workflows demoram para iniciar, a interface trava ao abrir, ou execuções que antes eram rápidas agora ficam na fila por minutos.
Na maioria dos casos é RAM insuficiente para as execuções concorrentes que o n8n está tentando rodar, ou workflows demais ativos sem modo fila (queue mode) organizando a carga. Sem queue mode, tudo compete pelo mesmo processo — um workflow pesado trava a interface pra todo mundo.
O container do n8n reinicia sozinho, aparece erro de "killed" nos logs, ou o servidor fica inacessível durante execuções pesadas.
Raiz é a mesma do item acima: RAM insuficiente para o volume de execuções simultâneas. O modo fila (queue mode, com Redis) ajuda porque distribui as execuções entre workers em vez de empilhar tudo num processo só — mas se a VPS não tem RAM de sobra, mesmo com queue mode o sistema operacional vai matar o processo quando faltar memória.
A sessão do WhatsApp cai sozinha, o QR Code expira antes de escanear, ou a instância volta pro estado "desconectado" sem motivo aparente.
Geralmente é uma combinação de três coisas: versão do Baileys (a biblioteca que fala com o WhatsApp Web) desatualizada em relação à versão que o WhatsApp está usando no momento; cache do Redis instável ou compartilhado incorretamente entre instâncias; ou RAM insuficiente para abrir a sessão quando você já tem várias outras instâncias ativas na mesma VPS.
O consumo de memória sobe conforme você conecta mais números, até o servidor ficar no limite ou travar.
Cada sessão WhatsApp ativa na Evolution API consome cerca de 150-300MB de RAM. Isso é esperado e escala de forma linear: 5 números ficam em torno de 3,5GB no total (já somando a base do n8n), 20 números em torno de 8,5GB, 50 números em torno de 16,5GB. Na prática, "consumindo muita RAM" quase sempre significa números demais para o plano atual, não um bug.
O n8n ou a Evolution API caem, e a primeira vez que você fica sabendo é quando um cliente reclama que a automação parou.
Isso não é um problema de código — é uma lacuna de monitoramento. Sem alguém (ou algo) verificando os serviços continuamente, o tempo entre a queda e a descoberta fica nas mãos do acaso. O uptime monitorado 24h/7d, incluso em todos os planos You Secure, existe exatamente pra fechar essa lacuna: os serviços são checados continuamente e o alerta chega antes do cliente perceber — não é uma promessa de "zero downtime", é visibilidade real do que está no ar.
Você atualizou o n8n, a Evolution API ou outro app, e algo que funcionava parou — workflow quebrado, integração fora do ar, erro novo nos logs.
Atualizar direto em produção é a causa mais comum. A prática mais segura é testar a atualização numa instância secundária/staging antes de aplicar na VPS de produção, e manter backups recentes para reverter rápido se algo quebrar — os planos You Secure incluem backup semanal, mas vale considerar um snapshot manual extra antes de qualquer atualização maior.
Manda seu cenário pra gente fazer um diagnóstico gratuito, ou chama direto no WhatsApp — a gente olha os detalhes reais do seu servidor antes de sugerir qualquer mudança de plano.
Planos VPS Brasil
Deploy Cloud, apps em 1 clique, SSL, backup e monitoramento — tudo incluso, em qualquer plano que você escolher.
VPS Brasil
Para quem está começando com automação.
Ideal para: n8n em testes ou produção leve · até 3 números Evolution API · sites e APIs simples
cobrado mensalmente
Escolher planoVPS Brasil
Para automação em produção de verdade.
Ideal para: n8n + Evolution API rodando juntos · 5 a 15 números WhatsApp · PostgreSQL + Redis
cobrado mensalmente
Escolher planoVPS Brasil
Para agências e operações de alto volume.
Ideal para: múltiplos clientes na mesma VPS · até 50 números Evolution API · automação + apps rodando juntos
cobrado mensalmente
Escolher plano