Como limitar memória e CPU do n8n no Docker: swap, OOM e travamentos

*# Como limitar memória e CPU do n8n no Docker: swap, OOM e travamentos

Meta descrição: Aprenda como limitar memória e CPU do n8n no Docker, ajustar swap e evitar OOM na VPS para impedir travamentos.*

Rodar o n8n em uma VPS com Docker é uma das formas mais práticas de ter automações e agentes funcionando 24/7. O porém aparece quando você começa a colocar fluxos mais pesados para rodar (muitos itens, loops, chamadas em lote, uso de IA, PDFs, anexos, etc.): de repente o servidor fica lento, o container reinicia do nada, e em casos mais chatos a VPS inteira trava.

É aqui que entra a palavra-chave deste artigo: como limitar memória e CPU do n8n no Docker. Ao definir limites, você coloca grades de proteção no container. Isso ajuda a:

• impedir que o n8n consuma toda a RAM e derrube o host;
• evitar brigas por CPU com banco de dados (Postgres), Redis, reverse proxy (Traefik/Nginx) e outros serviços;
• reduzir a chance de o Linux chamar o OOM Killer (o mecanismo que mata processos quando a memória acaba);
• tornar o comportamento do ambiente mais previsível, facilitando troubleshooting.

Ao longo do guia, você vai entender quando faz sentido limitar recursos, como configurar mem_limit e cpus no docker-compose, por que o swap é uma rede de segurança (mas não uma solução mágica), e como monitorar gargalos para agir antes do travamento.

A ideia é manter tudo bem didático e pé no chão, pensando em quem está começando com n8n, Docker e VPS.

Por que limitar recursos do n8n no Docker?

Limitar recursos parece contraintuitivo no começo: se eu limitar, não vou piorar a performance? Na prática, em VPS pequenas ou médias (ex.: 4 GB / 1–2 vCPU), limites são uma forma de garantir estabilidade. Sem limites, um workflow mal otimizado pode consumir memória em poucos minutos (principalmente quando você carrega muitos itens em memória, transforma JSON grande, faz merge de listas enormes ou processa arquivos) e isso pode derrubar não só o n8n, mas o servidor todo.

O que acontece quando a memória acaba (OOM)
No Linux, quando a RAM realmente chega ao fim, o sistema aciona o OOM Killer (Out-Of-Memory Killer), que escolhe um processo para matar e liberar memória. Em ambientes com Docker, isso pode significar:

• o container do n8n morrer e reiniciar;
• o Postgres morrer (e aí seu n8n pode corromper execuções ou ficar com erros de conexão);
• o host congelar por alguns segundos/minutos por conta de pressão de memória e swap.

A consequência para quem usa n8n é clássica: execuções que ficam em running para sempre, web UI que não abre, filas travadas, integrações falhando e sensação de instabilidade.

Por que também limitar CPU
CPU não costuma matar processos como a falta de memória, mas pode causar efeito dominó:

• o n8n fica com latência alta (webhook demora para responder);
• o banco de dados não acompanha (queries ficam lentas);
• o reverse proxy sofre para servir a UI.

Ao colocar um limite de CPU no container, você evita que um único workflow (ou uma execução presa em loop) monopolize o servidor. É especialmente útil quando você roda n8n no mesmo host que Postgres/Redis.

Objetivo real dos limites
O ponto principal não é estrangular o n8n. É criar previsibilidade: você define um teto seguro para o container e passa a enxergar claramente quando o n8n está chegando nesse teto. A partir daí, você decide entre:

• otimizar workflows;
• aumentar a VPS;
• separar serviços (n8n em uma VPS, banco em outra);
• mudar arquitetura (ex.: modo fila com workers).

🤖 Aprenda n8n e agentes com prática (sem travar sozinho)

Se você está montando n8n em VPS e já se preocupa com limites de CPU/RAM, swap e OOM, é sinal de que quer rodar automações de verdade, com estabilidade.

A Formação Agentes de IA (n8n) da Hora de Codar é mão na massa e vai do básico a projetos completos. São 221+ aulas, 11+ cursos, 21+ projetos e 20h+, com comunidade ativa (8100+ alunos) para tirar dúvidas.

Conheça a grade e veja se encaixa no seu momento:
https://app.horadecodar.com.br/lp/formacao-agentes-de-ia-n8n?utm_source=blog

Passo a passo: configurando mem_limit e cpus no docker-compose

Existem duas realidades no Docker: Compose normal (o mais comum em VPS) e Docker Swarm. Alguns parâmetros funcionam melhor em um cenário do que no outro.

1) Identifique seu tipo de Compose

• Se você roda com: docker compose up -d (ou docker-compose up -d), está no modo normal.
• Swarm usa docker stack deploy e trabalha com deploy.resources.

Aqui vamos focar no caso mais comum: VPS com Compose normal.

2) Exemplo de limites recomendados (iniciante)
Em uma VPS de 4 GB de RAM, um ponto de partida razoável para o n8n costuma ser algo como 1.5 GB a 2.5 GB de RAM para o container, dependendo do que mais roda na máquina (Postgres, Redis, Traefik, etc.). Para CPU, algo como 1.0 ou 1.5 CPU costuma ajudar a manter o host responsivo.

No docker-compose.yml, você pode adicionar limites assim (exemplo textual):
services:
n8n:
image: n8nio/n8n:latest
containername: n8n
restart: always
ports:
– 5678:5678
environment:
– N8NHOST=seu-dominio.com
– N8NPORT=5678
– N8NPROTOCOL=https
– NODEENV=production
volumes:
– n8ndata:/home/node/.n8n
mem_limit: 2g
cpus: 1.0

volumes:
n8n_data:

3) Entenda o que você acabou de configurar

• mem_limit: 2g -> o container pode usar até 2 GB. Se tentar passar disso, o kernel pode matar o processo dentro do container (ele reinicia se você tiver restart: always).
• cpus: 1.0 -> limita a fatia de CPU disponível. Em um host com 2 vCPU, 1.0 dá metade da capacidade total.

4) E se eu uso deploy.resources?
Se estiver usando Swarm, faz sentido um bloco como:
services:
n8n:
deploy:
resources:
limits:
cpus: 1.0
memory: 2G

Mas em Compose normal, esse bloco deploy costuma ser ignorado.

5) Ajuste fino (o que observar)

• Use docker stats para ver consumo real em tempo de execução.
• Ajuste aos poucos.

Se o n8n bater no limite de memória com frequência, você verá reinícios ou workflows falhando. Antes de aumentar recursos no escuro, confira qual tipo de fluxo está puxando RAM.

Vídeo recomendado para complementar (n8n na VPS)

Para ver um passo a passo bem direto de n8n rodando em VPS (o que ajuda a contextualizar Docker, recursos do servidor e estabilidade), este vídeo é um ótimo complemento:

Link: https://www.youtube.com/embed/VCKzXFk_XjM?si=eOBTMrjZNPj3q07Z

Assista, compare com o seu ambiente e depois aplique as configurações de mem_limit, cpus e swap para reduzir travamentos.

Swap na VPS: como configurar para evitar OOM Killer

Swap não melhora performance: troca velocidade por sobrevivência. Em termos simples, swap é usar disco como memória extra. É bem mais lento que RAM, mas pode impedir que o sistema chegue no ponto crítico e dispare o OOM Killer cedo demais.

Quando o swap ajuda de verdade

• VPS com pouca RAM (2–4 GB) rodando n8n + Postgres.
• Picos de consumo ocasionais (um workflow que roda 1 vez por dia e usa mais memória).
• Situações em que você prefere lentidão temporária do que queda do serviço.

Quando swap pode virar armadilha
Se o seu n8n vive no limite de memória, o sistema pode entrar em swap storm (troca intensa entre RAM e disco), ficando muito lento. Nesse caso, swap só mascara o problema: o certo é otimizar fluxos ou subir o tamanho da VPS.

Passo a passo (Ubuntu/Debian) para criar swapfile
1) Crie o arquivo:

• sudo fallocate -l 2G /swapfile
  Se fallocate não funcionar:
• sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

2) Ajuste permissões:

• sudo chmod 600 /swapfile

3) Formate e ative:

• sudo mkswap /swapfile
• sudo swapon /swapfile

4) Faça persistir após reboot:

• echo ‘/swapfile none swap sw 0 0’ | sudo tee -a /etc/fstab

5) Confira:

• swapon –show
• free -h

Dica importante: swappiness

• Defina um valor menos agressivo, por exemplo 10:
• sudo sysctl vm.swappiness=10
  Para persistir:
• echo ‘vm.swappiness=10’ | sudo tee /etc/sysctl.d/99-swappiness.conf
• sudo sysctl -p /etc/sysctl.d/99-swappiness.conf

Dicas extras para evitar OOM e otimizar o n8n

Limitar memória e CPU do n8n no Docker e configurar swap na VPS são a base. Mas, se o workflow continuar consumindo muita memória, você vai apenas trocar travamento por reinício. Pequenas mudanças de design de fluxo já reduzem muito o uso de RAM.

1) Pense em volume: quantos itens você coloca em memória?

• Prefira processar em lotes menores (mesmo que leve um pouco mais de tempo).
• Evite nodes que juntam tudo cedo demais (merge/aggregate) antes de filtrar.
• Filtre e reduza campos o quanto antes (remover colunas não usadas faz diferença em JSON grande).

2) Cuidado com arquivos e binários

• Armazene arquivos em storage (S3, Drive, etc.) e passe só link/ID entre nodes quando possível.
• Evite manter binário trafegando por muitos nodes.

3) Concurrency e explosões de execução

• Se webhooks recebem picos, crie gargalos controlados (filas, limites de execução) para não disparar tudo simultaneamente.

4) Suba de nível quando fizer sentido: modo fila

• Considere n8n em modo queue com Redis e workers separados. Isso isola carga e evita que UI e webhooks disputem recursos com tarefas pesadas.

5) Ajuste de expectativa: limite não é cura

• Se o n8n bate no teto toda hora, você tem três saídas: otimizar o fluxo, aumentar recursos da VPS ou separar serviços/adicionar workers.

💻 VPS para n8n com Docker: por que escolher a Hostinger

Para quem roda n8n em Docker, a VPS impacta diretamente estabilidade de RAM, desempenho de disco e possibilidade de escalar.

A VPS da Hostinger costuma funcionar bem: dá para começar pequeno e crescer, com 99,9% de uptime, armazenamento NVMe e planos adequados para n8n (por exemplo, KVM 1 com 4 GB RAM e KVM 2 com 8 GB RAM). Eles citam n8n como cenário suportado, o que ajuda iniciantes.

Confira os planos com desconto:
https://www.hostinger.com.br/horadecodar

Use o cupom HORADECODAR na contratação.

Monitoramento e troubleshooting: detectando e resolvendo gargalos

Para resolver de forma consistente, identifique se o gargalo é memória, CPU, I/O de disco, banco ou concorrência.

Comece pelo básico: consumo em tempo real

• docker stats mostra CPU, RAM e I/O por container.
• Se a RAM do n8n cresce sem parar durante uma execução e não volta, é sinal de workflow pesado ou concorrência excessiva.

Verifique logs do container

• docker logs -f n8n
  Se o serviço sobe novamente sem erro claro, suspeite de OOM.

Confirme OOM Killer no host

• sudo dmesg -T | grep -i -E ‘oom|killed process’
  Se aparecer Killed process … node, é quase certeza de falta de memória.

Sintomas comuns e leituras rápidas

• UI do n8n muito lenta, sem reinício: CPU alta ou disco lento (swap demais também deixa tudo lerdo).
• Container reinicia sozinho: geralmente OOM ou exceção fatal.
• Host congela: memória no limite + swap em excesso + disco sofrendo.

Ações práticas (ordem sugerida)
1) Reduzir a carga do workflow (lotes, filtros, evitar carregar tudo em memória).
2) Aplicar limites: mem_limit e cpus no docker-compose.
3) Adicionar swap como amortecedor, principalmente em VPS menor.
4) Revisar arquitetura se há muitas execuções concorrentes (modo fila).
5) Escalar VPS quando a demanda é real e constante.

Dica: separar n8n e banco

• Manter Postgres com memória protegida evita cascata de erros. Quando o banco cai, o n8n falha de formas confusas (principalmente em execuções longas).

Como posso limitar o uso de memória e CPU do n8n ao rodar com Docker em uma VPS?

Você pode limitar o uso de memória e CPU do n8n ao adicionar parâmetros específicos no comando ‘docker run’ ou no seu arquivo docker-compose.yml. Por exemplo, use as flags ‘–memory’ e ‘–cpus’ para definir limites de RAM e núcleos de CPU. Exemplo no docker-compose.yml: ‘mem_limit: 1g’ e ‘cpus: 1.5’. Isso impede que o container do n8n consuma todos os recursos da VPS.

Como configurar a swap do Docker para o n8n e por que isso é importante?

A swap serve como uma memória extra quando a RAM está cheia, evitando travamentos por falta de memória. No Docker, use a flag ‘–memory-swap’ para definir o limite combinado de memória RAM e swap. Por exemplo: ‘–memory=1g –memory-swap=2g’. Assim, além da RAM, seu container poderá usar até 1GB de swap, aumentando a estabilidade do n8n.

Como evitar que o n8n no Docker seja finalizado por OOM (Out of Memory)?

Para evitar que o container do n8n seja finalizado por OOM, limite a memória com as flags corretas e ajuste o swap, como descrito acima. Monitore seu uso de recursos com ferramentas como ‘docker stats’ para antecipar picos e considerar aumentar a memória se necessário. Manter limites bem definidos e o swap configurado reduz o risco de OOM e travamentos inesperados.

Conclusão

Saber como limitar memória e CPU do n8n no Docker é uma medida simples que muda o jogo em produção. Com mem_limit e cpus no docker-compose, você evita que o n8n consuma recursos sem freio e derrube o restante do servidor. Ao mesmo tempo, configurar swap na VPS cria uma camada extra para picos de uso, reduzindo a chance de travamentos e ajudando a evitar OOM killer no Docker.

Limites e swap trazem previsibilidade, mas a estabilidade de longo prazo vem de workflows bem desenhados, controle de concorrência e monitoramento (logs, docker stats e checagem de eventos de OOM no host).

Se ainda houver reinícios frequentes, encare como sinal claro: é hora de otimizar fluxos, adotar modo fila/workers ou escalar a VPS. Assim, o n8n vira uma base sólida para automações e agentes de IA 24/7.