Requisitos de servidor do n8n

Quanta máquina uma instância self-hosted do n8n realmente precisa, o que o banco de dados acrescenta e o ponto em que uma instância deixa de ser suficiente. A maioria dos guias de dimensionamento que você encontra online foi escrita para o modo fila, que a maioria das pessoas nunca precisa, então parece um requisito muito maior do que realmente é.

A resposta curta

Uma única instância do n8n rodando workflows normais não é um software exigente. Duas vCPU e 2 GB de RAM rodam com folga uma carga real de jobs agendados, webhooks e chamadas de API, porque o n8n passa a maior parte do tempo esperando serviços de terceiros em vez de calcular. O processo principal do n8n em si fica em torno de 300 MB em repouso.

O que realmente faz esse número subir não é quantos workflows você definiu. É quantos dados uma única execução mantém na memória ao mesmo tempo e quantas execuções rodam simultaneamente.

O que consome memória no n8n

O n8n passa dados entre os nós como itens mantidos na memória durante toda a vida da execução. Isso tem uma consequência importante para o dimensionamento: um workflow que busca dez mil linhas e as mapeia por cinco nós é um inquilino muito mais pesado do que cem workflows que movem, cada um, um payload de webhook.

• Tamanho do payload por execução. Respostas HTTP grandes, importações de planilhas e arquivos binários são a causa habitual de uma instância que estava bem e de repente deixa de estar.
• Concorrência. Dez execuções rodando ao mesmo tempo, cada uma com seu próprio conjunto de trabalho. Uma agenda que dispara vários workflows no mesmo minuto é um pico que você não planejou.
• Histórico de execuções. Os dados de execução salvos se acumulam no banco de dados. É uma questão de disco e de banco, e não de RAM, mas é o que cresce silenciosamente por meses e depois passa a importar.

A implicação prática: se você processa payloads grandes, divida-os. Dividir um grande conjunto de dados em blocos ajuda a estabilidade mais do que qualquer quantidade extra de RAM, porque muda o pico em vez de elevar o teto.

O banco de dados é um requisito, não uma otimização

O n8n usa SQLite por padrão, o que serve para um teste e é uma má ideia em produção. Ele lida mal com execuções concorrentes e é complicado de fazer backup e restaurar com confiança. O PostgreSQL é a resposta para produção, e não é gratuito em termos de recursos: reserve cerca de 500 MB a 1 GB para ele, valor que cresce com o seu histórico de execuções.

Esse número é o que a maioria dos guias de dimensionamento mistura discretamente na mesma caixa que o próprio n8n. Em uma VPS faça-você-mesmo, ele sai da mesma RAM dos seus workflows, junto com o runtime do contêiner, um reverse proxy e o sistema operacional. Nos nossos planos, o cluster PostgreSQL é um componente de alta disponibilidade separado, com memória própria, então a RAM no nome do plano é RAM para o n8n.

CPU: geralmente não é o fator limitante

O n8n é dominado pela espera. Uma execução passa o tempo em viagens de ida e volta de rede para APIs, e não em computação, então dois núcleos vão bem longe. As exceções são reais, mas específicas: transformação pesada de dados em nós de código, parsing de JSON grande e workflows de IA que fazem trabalho local relevante, em vez de apenas chamar uma API de modelo. Se seus workflows são em sua maioria integrações, adicione RAM antes de núcleos.

Quando você precisa do modo fila

Por padrão, o n8n executa tudo em um único processo. O modo fila separa isso: uma instância principal recebe os gatilhos e entrega as execuções a processos worker separados por meio do Redis, então o processo principal continua responsivo, não importa quanto tempo um job leve. É a resposta padrão para escalar o n8n, e também a razão pela qual a maioria dos guias de dimensionamento publicados parece tão pesada.

Você precisa dele quando uma destas condições é verdadeira, e não antes:

• Execuções longas estão bloqueando as curtas. Um workflow que leva cinco minutos fará um webhook de entrada esperar atrás dele no modo de processo único. No modo fila, a instância principal confirma imediatamente e um worker faz o trabalho.
• Você vê um backlog visível. O sinal mais claro são execuções presas em estado de espera por mais de alguns segundos na interface do n8n. Isso significa que uma fila está se formando, e nenhuma quantidade extra de RAM em um único processo a remove.
• Um único job pesado pode derrubar a instância inteira junto com ele. O isolamento costuma ser a motivação real, e não a vazão.

O modo fila acrescenta duas coisas aos seus requisitos. O Redis, que é pequeno, cerca de 128 MB, mas é mais um componente para rodar, e a RAM por worker: cada processo worker consome aproximadamente 200 a 500 MB, dependendo do que seus workflows carregam. Dois workers é o ponto de partida sensato, e você adiciona mais apenas quando o backlog indicar. Workers precisam de RAM muito mais do que de núcleos, por isso o caminho usual de escala adiciona memória duas ou três vezes antes de adicionar CPU.

Sendo direto: uma implantação em modo fila com vários workers precisa de um componente Redis e de mais memória do que os planos acima oferecem, então não é para isso que estes planos servem. Eles são instâncias únicas do n8n com um banco de dados de alta disponibilidade, que é o que a grande maioria das instâncias self-hosted realmente são. Se você mediu um backlog e realmente precisa de workers, já superou uma implantação com um clique e deveria dimensionar uma stack dedicada para isso.

Armazenamento e o que cresce

O próprio n8n precisa de muito pouco disco. O histórico de execuções é o que cresce, e cresce em proporção à frequência com que seus workflows rodam, e não à quantidade deles. Um workflow que consulta uma API a cada dez minutos gera cerca de 4,300 execuções por mês sozinho. Faça a limpeza dos dados de execução salvos com uma política de retenção, em vez de esperar o disco decidir por você, e mantenha as execuções com falha por mais tempo que as bem-sucedidas, porque essas são as únicas que você vai de fato ler.

Requisitos que não são hardware

Dois deles importam mais do que qualquer especificação. Webhooks precisam de uma URL pública HTTPS estável, o que significa um domínio real, um certificado válido e um reverse proxy na frente do n8n; uma instância self-hosted sem isso pode rodar agendamentos, mas não consegue receber nada. E uma plataforma de automação precisa estar no ar quando o gatilho dispara, o que descarta um notebook e torna a disponibilidade um requisito no mesmo sentido em que a RAM é.

Perguntas frequentes