*# Como limitar CPU e memória do n8n no Docker na VPS sem derrubar automações críticas
Meta descrição: Veja como limitar CPU e memória do n8n no Docker na VPS sem derrubar automações críticas. Dicas de –cpus, –memory e docker-compose.*
Rodar o n8n em uma VPS com Docker é uma forma prática de ter controle total do seu ambiente — mas esse poder vem com um risco clássico: um workflow mal otimizado (ou um pico de execuções) pode consumir CPU e RAM e afetar tudo no servidor. Aí acontecem os sintomas mais chatos: interface lenta, filas travadas, webhooks que não respondem e automações críticas falhando bem na hora que você mais precisa.
A boa notícia é que dá para limitar CPU e memória do n8n no Docker de um jeito seguro, criando uma espécie de cinto de segurança para o container. Você define um teto de recursos que o n8n pode usar e, ao mesmo tempo, ajusta o próprio n8n para não tentar processar mais do que a máquina aguenta.
Neste artigo, você vai aprender:
- Como funcionam limites de CPU e RAM no Docker (e o que muda ao usar docker run ou docker-compose);
- Como aplicar limites sem derrubar workflows importantes, evitando OOM (Out Of Memory) e reinícios em loop;
- Como ajustar concorrência e padrões de execução no n8n para trabalhar junto com esses limites;
- Como monitorar e manter estabilidade em produção.
A palavra-chave principal aqui é como limitar CPU e memória do n8n no Docker, com foco prático: terminar a leitura com uma configuração que mantém seu n8n previsível, estável e pronto para crescer.
Importante: limitar recursos não é punição. É garantir previsibilidade. Se você limita corretamente, evita que um fluxo pesado derrube o resto — essencial quando a VPS hospeda mais coisas (banco, proxy, Evolution API, etc.).
Por que limitar CPU e memória do n8n no Docker na VPS?
Quando você roda o n8n em uma VPS via Docker, o comportamento padrão é: se houver recursos disponíveis, o container pode tentar usar tudo. Em produção, isso é perigoso: picos de webhooks, loops, nodes que manipulam muitos itens ou integrações instáveis com retries podem fazer o consumo de recursos subir muito rápido.
Benefícios de limitar CPU e RAM:
1) Proteção do servidor: evita swap pesado e o OOM Killer derrubando processos importantes.
2) Previsibilidade e diagnóstico: com teto definido, você enxerga onde está o gargalo (CPU ou RAM) sem colapsar o host.
3) Menos quedas em cascata: evita reinícios em loop e perda de janelas críticas de execução.
Conforme o projeto cresce, você terá mais serviços no mesmo host (PostgreSQL, Redis, reverse proxy, monitoramento). Sem limites, o n8n concorre de forma agressiva. Com limites, você cria divisão justa.
Pense assim: o Docker impõe o teto e o n8n aprende a operar bem dentro desse teto. Essa dupla evita que automações críticas parem por falta de estabilidade.
🤖 Uma indicação que ajuda muito: Formação Agentes de IA (n8n)
Se você está chegando agora no n8n (ou se já usa e quer deixar seus fluxos mais profissionais), conheça a Formação Agentes de IA da Hora de Codar. Além de ensinar n8n do básico ao avançado, entra em pontos que impactam diretamente a estabilidade em produção: organização de projetos, automações robustas e práticas de monitoramento/otimização.
A formação reúne 8.100+ alunos, 11+ cursos, 221+ aulas, 20h+ de conteúdo e 21+ projetos, com foco mão na massa e acesso vitalício.
CTA: conhecer a Formação Agentes de IA (n8n) → https://app.horadecodar.com.br/lp/formacao-agentes-de-ia-n8n?utm_source=blog
Configurando limites de CPU e RAM no Docker e docker-compose
Para limitar RAM e CPU do n8n no Docker, você pode aplicar limites tanto em docker run quanto no docker-compose.
Limites usando docker run:
- –cpus: define quantos núcleos o container pode usar (pode ser fracionado, ex.: 0.5).
- –memory: define o máximo de RAM (ex.: 1g, 512m).
- –memory-swap: controla swap; igualar ao –memory evita usar swap além do limite.
Exemplo (uma linha):
docker run -d –name n8n –cpus=”1.0″ –memory=”1g” –memory-swap=”1g” -p 5678:5678 n8nio/n8n
Limites usando docker-compose (modo tradicional, não Swarm):
services:
n8n:
image: n8nio/n8n
ports:
– “5678:5678”
environment:
– N8NHOST=seu-dominio.com
– N8NPORT=5678
– N8NPROTOCOL=https
cpus: “1.0”
memlimit: “1g”
restart: unless-stopped
Em Swarm/Stack (deploy.resources.limits):
services:
n8n:
image: n8nio/n8n
deploy:
resources:
limits:
cpus: “1.0”
memory: 1G
Dica: limite de RAM do container não é o mesmo que limite de heap do Node.js. Em cenários sensíveis, defina também:
NODE_OPTIONS=–max-old-space-size=768
Assim o processo falha de forma mais diagnosticável antes de bater no teto do container.
Pontos de partida:
- VPS 4GB: comece com 1GB para o n8n.
- VPS 8GB: 2GB costuma ser confortável.
Depois ajuste com base em métricas reais.
Vídeo recomendado: COMO INSTALAR n8n NA VPS EM 5 MINUTOS!
Se você ainda está consolidando seu ambiente (VPS + Docker + n8n) ou quer revisar o setup para produção, este vídeo ajuda a deixar a base redonda — e isso faz diferença quando você começa a mexer com limites de CPU e memória.
Assista: https://www.youtube.com/embed/VCKzXFk_XjM?si=eOBTMrjZNPj3q07Z
Cuidados para não interromper automações críticas ao limitar recursos
Para evitar paradas, siga boas práticas ao ajustar limites:
1) Evite cortes bruscos: reduza memória em etapas (ex.: 2GB → 1.5GB → 1GB) e monitore.
2) Entenda os riscos:
- OOM (memória estourada): o processo é morto; execuções em andamento podem falhar.
- CPU estrangulada: o n8n fica lento; webhooks expiram, filas atrasam.
3) Priorize resiliência dos fluxos: - Idempotência em reexecuções.
- Checkpoints/registro de itens processados.
- Paginação e lotes menores.
4) Faça mudanças em janelas seguras, com backup e plano de rollback.
5) Use restart com responsabilidade: se entrar em loop por OOM, volte temporariamente o limite, identifique o workflow pesado e otimize.
6) Em webhooks com picos, combine limites do container com ajuste de concorrência e, se necessário, queue mode com workers.
Ajustando concorrência e otimizando workflows no n8n
Mesmo com limites de Docker, o n8n pode tentar fazer coisa demais ao mesmo tempo.
Concorrência:
- Muitos workflows em paralelo aumentam RAM e CPU.
- Em operações maiores, separe UI/webhooks de processamento usando queue mode (Redis) + workers.
Otimização de workflows:
- Evite processar itens demais de uma vez (ex.: 50 mil linhas em um único run).
- Reduza payloads grandes (JSONs, base64, anexos): prefira links/stream e remova campos inúteis cedo.
- Ajuste timeouts e retries para evitar tempestade de reprocessamentos.
Sinal de que é otimização (não só aumentar limite): se aumentar RAM “some” com o problema, mas ele volta no pico, o fluxo está retendo dados demais. A solução sustentável é reduzir volume por execução ou distribuir processamento.
Resumo:
- Limites do Docker protegem o servidor.
- Concorrência/queue mode protegem o n8n.
- Workflows otimizados protegem suas automações críticas.
💻 VPS para n8n com Docker: por que eu iria de Hostinger
Para rodar n8n com previsibilidade, uma VPS estável ajuda — principalmente quando você aplica limites de CPU/RAM e precisa de margem para banco, proxy e serviços de apoio. A VPS da Hostinger é prática: você escala recursos conforme o projeto cresce e tem infraestrutura com 99,9% de uptime.
Detalhe útil: há opção com n8n pré-instalado, reduzindo atrito para colocar o ambiente no ar e evoluir sua stack.
Planos e desconto:
- Link: https://www.hostinger.com.br/horadecodar
- Cupom: HORADECODAR
Há opções desde 1 vCPU e 4GB RAM até 8 vCPU e 32GB RAM, útil quando você adota fila/workers e aumenta volume.
Monitoramento e boas práticas para estabilidade do n8n em produção
Sem monitoramento, você só descobre que extrapolou CPU/RAM quando a automação já falhou.
Acompanhe:
- RAM do container (docker stats, alertas simples): se encosta no limite, risco de OOM.
- CPU sob carga: 100% constante degrada webhooks e UI.
- Tempo de execução dos workflows: aumentos graduais indicam gargalo.
- Erros por timeout: sinal de CPU insuficiente ou concorrência alta.
Boas práticas:
1) Separe banco de dados e n8n com cuidado; limitar n8n evita matar o PostgreSQL.
2) Planeje crescimento: limite não substitui capacidade; escale VPS ou arquitetura quando preciso.
3) Teste com carga realista em horários seguros.
Quando mudar de estratégia:
- Se, mesmo otimizando, o n8n bate no teto com frequência, evolua para queue mode + workers e/ou suba recursos.
Checklist antes de dizer “está pronto”:
- O container não bate no limite de memória em dias normais.
- Em pico, degrada de forma aceitável (sem derrubar webhooks).
- Há rollback rápido de configuração.
- Existe plano de escala (vertical ou com workers).
Como limitar CPU e memória do n8n no Docker usando comandos simples?
Você pode limitar o uso de CPU e memória do n8n no Docker usando flags como –cpus e –memory ao iniciar um container. Por exemplo: docker run –cpus=1 –memory=1g n8nio/n8n irá limitar o container a 1 núcleo de CPU e 1 GB de RAM.
É possível definir limites de recursos para o n8n no Docker Compose?
Sim, basta definir os parâmetros deploy.resources.limits no docker-compose.yml. Exemplo:
services:
n8n:
image: n8nio/n8n
deploy:
resources:
limits:
cpus: ‘1.0’
memory: 1G
Assim, o n8n irá respeitar esses limites também em ambientes orquestrados.
Como evitar que as automações críticas sejam interrompidas ao limitar recursos?
É importante analisar o consumo atual de CPU e RAM das automações do n8n para definir limites seguros. Monitore o sistema após aplicar restrições e ajuste os valores conforme necessário, garantindo que as automações críticas continuem funcionando sem quedas.
Conclusão
Saber como limitar CPU e memória do n8n no Docker protege o que importa: suas automações críticas. Ao colocar limites (via docker run ou docker-compose), você evita que um pico ou um workflow mal comportado derrube a VPS. O melhor resultado vem quando você combina isso com ajustes dentro do n8n: reduzir concorrência quando necessário, organizar fluxos para não carregar dados gigantes em memória e planejar processamento em lotes ou com fila.
O caminho recomendado é incremental: aplique limites com cuidado, monitore o comportamento real do container e vá refinando. Se o n8n vive batendo no teto, é hora de otimizar workflows, separar cargas (queue/workers) ou subir a capacidade da VPS.
Estabilidade em produção é previsibilidade. Com limites bem definidos, monitoramento básico e boas práticas de workflow, você roda n8n na VPS com muito mais confiança — sem interromper automações e sem sustos em horários críticos.