Resposta curta: a documentação do n8n não publica um requisito mínimo fixo de RAM ou CPU. Ela explica do que o consumo depende e mostra benchmarks. Este artigo resume o que existe de oficial (consultado em 13/10/2026).
Do que o consumo de memória depende
Segundo a página Fix memory issues:
- quantidade de dados JSON;
- tamanho de dados binários (arquivos);
- número de nós no workflow;
- nós pesados: o nó Code e o antigo Function aumentam bastante o consumo;
- execuções manuais, porque o n8n copia os dados para a interface;
- outros workflows rodando ao mesmo tempo.
Sinais de falta de memória: mensagens como “n8n may have run out of memory while executing it”, Connection Lost, 503 Service Temporarily Unavailable ou JavaScript heap out of memory no log. Na imagem Docker, o n8n reinicia sozinho nesses casos.
Como reduzir: processar em lotes menores (a documentação dá o exemplo de 200 linhas por execução em vez de 10.000), evitar o nó Code quando possível, evitar execuções manuais com muito dado e dividir em sub-workflows que devolvem pouco dado. Também é possível aumentar a memória do V8 com NODE_OPTIONS=--max-old-space-size=....
Benchmarks oficiais
Da página Measure performance:
- O n8n afirma suportar até 220 execuções de workflow por segundo numa única instância, e mais com múltiplas instâncias.
- Teste de instância única: AWS c5a.large com 4 GB de RAM, n8n em modo main com PostgreSQL, workflow simples de Webhook + Edit Fields.
- Teste multi-instância: sete máquinas c5a.4xlarge (8 GB cada), com 2 instâncias de webhook, 4 workers, banco MySQL e Redis, em queue mode.
São workflows mínimos, então workflows reais com IA, arquivos ou nó Code consomem mais.
Banco de dados e queue mode
- O padrão é SQLite. O PostgreSQL é suportado nas versões 16, 17 e 18 (docs).
- Queue mode (main + Redis + workers) é o modo de maior escalabilidade. A documentação não recomenda queue mode com SQLite e diz que queue mode não suporta dados binários no sistema de arquivos; para isso, use S3 (docs).
Então qual VPS?
Como não há número oficial, criamos uma calculadora com regras práticas explicitamente marcadas como estimativa e a referência do benchmark acima (4 GB). Depois de subir, acompanhe o uso real (por exemplo, com docker stats) e ajuste.