VPS para n8n self-hosted: como dimensionar CPU, RAM e disco (Brasil)

Como dimensionar VPS para rodar n8n self-hosted no Brasil sem travar

Resposta rápida: Para dimensionar uma VPS para n8n self-hosted, pense em três coisas: quantas execuções simultâneas você terá, o “peso” de cada fluxo (APIs leves vs. IA/arquivos) e quanto histórico/log você guarda. Em geral, começa-se pequeno para workloads leves e cresce RAM/CPU quando há concorrência, filas e processamento de dados. Disco e banco (Postgres) costumam ser o gargalo escondido.

· espaço publicitário ·

Em resumo

O que mais derruba n8n em VPS pequena é concorrência + fluxo pesado (IA, PDFs, planilhas grandes) rodando junto
RAM vira limite antes de CPU quando há muitos nodes, merges, loops e payloads grandes
Disco/IO e Postgres ficam críticos quando você mantém muito histórico de execução e logs
Evite “chutar”: monitore tempo de execução, uso de memória e filas por 7 dias antes de ampliar

1) Classifique seus fluxos: leve, médio ou pesado
Leve: webhooks, CRUD em CRM, planilhas pequenas, notificações. Médio: múltiplas integrações em sequência, transformações de JSON, alguns loops. Pesado: IA (LLM), RAG, PDFs/anexos, scraping, grandes volumes (muitos itens por execução) e qualquer coisa que “explode” payload.
2) Estime concorrência real (não só execuções/mês)
Concorrência é quantos workflows podem rodar ao mesmo tempo. Exemplos típicos: pico de leads chegando em horário comercial, importações em lote, rotinas agendadas que batem no mesmo horário. Se você tem 10 fluxos agendados para 09:00, você tem concorrência — mesmo com poucas execuções/mês.
3) Defina o perfil de VPS pelo seu cenário
Use a tabela de referência abaixo como ponto de partida e ajuste conforme sua realidade. Se tiver IA/arquivos, priorize RAM e CPU. Se você guarda muito histórico, priorize disco rápido e Postgres bem configurado.
4) Planeje o banco de dados e retenção de execuções
Em produção, o Postgres é o coração. O tamanho do banco cresce com: histórico de execuções, logs e payloads armazenados. Decida uma política de retenção (ex.: manter somente X dias) e exporte o que precisa para observabilidade/BI fora do n8n, quando fizer sentido.
5) Monitore sinais de gargalo por uma semana
Sinais comuns: workflows atrasando, timeouts em APIs, consumo de memória encostando no limite, swap ativando (péssimo), CPU em 100% durante longos períodos, Postgres lento. Meça antes de aumentar plano — e aumente uma coisa por vez (RAM ou CPU) para entender o efeito.
6) Ajuste: escale verticalmente e depois pense em separar componentes
Primeiro, aumentar RAM/CPU costuma ser o caminho mais simples. Quando o uso ficar estável alto, considere separar banco (Postgres) do app do n8n, e só então pensar em arquiteturas mais avançadas (fila, workers dedicados), se você realmente precisa.

Regra prática: dimensione por concorrência e “peso” do fluxo

Muita gente escolhe VPS olhando “execuções por mês”. Ajuda, mas não é o principal. O que derruba instância pequena é o pico: vários workflows ao mesmo tempo, cada um segurando memória e CPU, enquanto o Postgres grava histórico.

Se o seu n8n recebe webhooks (WhatsApp, formulários, checkout), o pico é mais importante que a média. Se ele roda só agendamentos espaçados, a média pesa mais.

Pouca concorrência + fluxos leves: priorize estabilidade e disco razoável.
Concorrência moderada + fluxos médios: RAM começa a mandar.
Concorrência alta ou fluxos pesados (IA/arquivos): RAM e CPU sobem juntas; disco/IO vira risco.

Tabela de referência (ponto de partida) para VPS do n8n

Os números abaixo são referência de partida, não verdade universal. Dependem de como você configura concorrência, de quanto payload trafega e do quanto você guarda de histórico. Se você usa IA (LLM) com respostas longas, processa anexos ou faz loops grandes, suba um degrau.

Perfil	Uso típico	CPU / RAM (ponto de partida)	Disco	Observações
Lab / teste	Aprender, 1-3 fluxos, sem picos	Baixo (1-2 vCPU, pouca RAM)	Pequeno	Bom para validar ideia; não é referência de produção
PME leve	Webhooks e integrações simples, poucos fluxos simultâneos	Moderado (ex.: 2 vCPU e RAM suficiente para não swapar)	SSD básico	Foque em backup e atualização segura
Operação de agência / múltiplos clientes	Vários fluxos e picos no mesmo horário	Mais CPU e principalmente mais RAM	SSD maior e rápido	Considere separar Postgres se o histórico crescer rápido
Fluxos pesados (IA, anexos, lotes)	PDFs, planilhas grandes, RAG, loops extensos	CPU e RAM altos	SSD rápido, mais espaço	Atenção a timeouts, filas e limitação de concorrência

O que costuma virar gargalo (e como reconhecer)

CPU alta constante não é a única dor. Em n8n, RAM e banco de dados aparecem como vilões com frequência, especialmente quando você tem muitos itens por execução.

Memória (RAM): uso sobe em degraus durante execuções e não volta; workflows começam a falhar aleatoriamente; sistema ativa swap.
CPU: picos longos quando há transformações pesadas, criptografia, parsing grande ou muitos itens em loop.
Disco/IO: banco demora para responder; UI fica lenta; salvar execuções vira gargalo.
Rede: menos comum, mas aparece em scraping, downloads/upload de anexos e integrações com muito tráfego.

Checklist de produção (o que vale mais que “mais CPU”)

Antes de aumentar VPS, garanta o básico. Muita instabilidade atribuída a “VPS fraca” é, na prática, falta de política de retenção, falta de backup, versão sem controle e workflows sem idempotência.

Postgres em vez de SQLite para produção (na prática, é o caminho mais estável).
Política de retenção de execuções e logs (quanto tempo faz sentido manter).
Backups testados (restauração validada, não só backup criado).
Controle de concorrência: evitar que tudo rode ao mesmo tempo.
Timeouts, retries e backoff bem definidos para APIs instáveis.
Idempotência em webhooks para não duplicar pedido/lead em reprocessamento.

Perguntas frequentes

Dá para rodar n8n self-hosted em VPS bem pequena?

Dá para estudar e rodar fluxos simples com baixa concorrência. O problema aparece quando chegam picos (muitos webhooks) ou quando você faz loops/IA/anexos. Para produção, o critério não é “rodar”, é “aguentar pico sem corromper processo e sem cair”.

O que devo aumentar primeiro: CPU ou RAM?

Na maioria dos cenários de automação com muitos nodes, dados e execuções simultâneas, RAM costuma ser o primeiro limitante (especialmente se o sistema começa a usar swap). CPU vira prioridade quando há processamento pesado (transformações grandes, parsing, criptografia, IA local, etc.) ou concorrência alta sustentada.

Guardar histórico de execuções deixa o n8n mais lento?

Pode deixar, porque aumenta o banco e o volume de escrita/leitura, especialmente se você guarda payloads completos por muito tempo. Uma política de retenção e rotinas de manutenção do banco (além de disco rápido) fazem diferença real.

Separar o Postgres do n8n é obrigatório?

Não. Para muitas PMEs, tudo na mesma VPS funciona bem. Separar faz sentido quando o banco cresce rápido, quando IO de disco vira gargalo, ou quando você quer mais segurança/isolamento operacional. É um passo de maturidade, não requisito inicial.

Como dimensionar uma VPS para rodar n8n self-hosted (sem travar e sem gastar à toa)

1) Classifique seus fluxos: leve, médio ou pesado

2) Estime concorrência real (não só execuções/mês)

3) Defina o perfil de VPS pelo seu cenário

4) Planeje o banco de dados e retenção de execuções

5) Monitore sinais de gargalo por uma semana

6) Ajuste: escale verticalmente e depois pense em separar componentes

Regra prática: dimensione por concorrência e “peso” do fluxo

Tabela de referência (ponto de partida) para VPS do n8n

O que costuma virar gargalo (e como reconhecer)

Checklist de produção (o que vale mais que “mais CPU”)

Perguntas frequentes

Leia também

Melhor VPS para hospedar n8n no Brasil em 2026: comparativo com preços reais

Como instalar n8n em VPS no Brasil (guia completo com custos reais)

Como fazer backup do n8n self-hosted e restaurar sem perder workflows

n8n self-hosted vs n8n cloud: qual vale mais a pena para o seu caso?