Qual servidor você precisa para cada stack de automação

Para quem é

Quem quer disparar e receber mensagens de WhatsApp dentro dos próprios workflows do n8n — atendimento simples, notificações, bots de qualificação de lead.

Qual plano usar

Básico (4GB RAM) cobre até 3 números. De 5 a 15 números, vá de Performance (12GB) — é o plano recomendado na tabela de cenários da home. Acima de 20 números, Ultra (20GB).

Como funciona

n8n consome o webhook da Evolution API, que mantém a sessão do WhatsApp Web (Baileys) aberta. Cada número é uma instância separada da Evolution rodando em paralelo, então RAM cresce linear com o número de números conectados.

Problemas comuns

• QR Code não conecta quando falta RAM disponível pra abrir nova sessão.
• Muitas instâncias no mesmo Redis sem isolamento derrubam o cache de todas juntas.
• Workflows disparando em paralelo sem fila (queue mode) somam picos de CPU.

Quando subir de plano

Mais de 15 números simultâneos, ou execuções concorrentes de workflow passando de ~10 ao mesmo tempo.

Para quem é

Equipes que precisam de uma caixa de entrada única (Chatwoot) para atendentes humanos, com automações do n8n cuidando de triagem, respostas automáticas e integrações, tudo puxando WhatsApp pela Evolution API.

Qual plano usar

Chatwoot é uma aplicação Rails e sozinha já consome tipicamente 1-2GB+ de RAM em produção — isso soma por cima da base de n8n (1,5-2GB) e das instâncias Evolution (150-300MB cada). Com poucos números (até 5, ≈3,5GB de Evolution), o total já fica em 6-7,5GB, então o mínimo realista é Performance (12GB). Com 20 números (≈8,5GB de Evolution) o total passa de 11-12,5GB e empurra pra Ultra (20GB).

Como funciona

Chatwoot recebe e organiza as conversas, o n8n consome os webhooks do Chatwoot e/ou da Evolution API pra automatizar respostas e integrações, e a Evolution API é a ponte com o WhatsApp Web. São três serviços com bancos e workers próprios competindo pelos mesmos vCPUs.

Problemas comuns

• Subestimar o footprint do Chatwoot sozinho é o erro mais comum — ele não é "mais um app leve".
• Sidekiq (worker do Chatwoot) competindo por CPU com os workers do n8n em execuções simultâneas.
• Postgres compartilhado entre Chatwoot e n8n sem tuning vira gargalo de I/O em picos.

Quando subir de plano

Mais de 10-15 números WhatsApp junto com Chatwoot ativo, ou mais de 2-3 atendentes usando o Chatwoot ao mesmo tempo — comece direto em Performance e não em Básico.

Para quem é

Quem quer construir um funil de qualificação, agendamento ou vendas com uma sequência visual de perguntas (Typebot) em vez de escrever cada resposta manualmente na lógica do n8n.

Qual plano usar

Typebot é mais leve que Chatwoot — não é um app de atendimento em tempo real com múltiplos workers, então o footprint extra fica mais próximo de centenas de MB do que de 1-2GB. Com até 5 números Evolution (≈3,5GB) e a base de n8n (1,5-2GB), Básico (4GB) já fica apertado — Performance (12GB) é o ponto de partida seguro assim que o Typebot entra em produção. Só automação leve sem muitos números pode caber em Básico.

Como funciona

Typebot serve o fluxo conversacional e expõe um webhook por conversa; o n8n orquestra a lógica de negócio por trás (CRM, planilha, agendamento); a Evolution API entrega as mensagens no WhatsApp do lead.

Problemas comuns

• Fluxos do Typebot com muitas variáveis/condições aumentam o tempo de resposta em VPS com pouca CPU.
• Sessões do Typebot "penduradas" (usuário que some no meio do funil) acumulam estado sem expirar se não configurado.
• Evolution API instável derruba a etapa de entrega mesmo com o funil funcionando certo.

Quando subir de plano

Mais de 5-10 números WhatsApp rodando o funil ao mesmo tempo, ou volume de conversas simultâneas no Typebot que comece a gerar fila perceptível.

Para quem é

Quem automatiza integrações internas, ETLs simples, sincronização entre sistemas e notificações por e-mail/Slack, sem depender de WhatsApp — o cenário mais barato de rodar.

Qual plano usar

Esse é o piso de RAM da casa: n8n + PostgreSQL + Redis juntos ficam em torno de 1,5-2GB idle. Para testes e poucos workflows, um servidor com 2GB de RAM já roda, ainda que apertado com o sistema operacional por cima. Para produção com folga de verdade — múltiplos workflows ativos e execuções concorrentes — Básico (4GB) é o piso recomendado.

Como funciona

PostgreSQL guarda o histórico de execuções e as credenciais do n8n; Redis entra quando o n8n roda em modo fila (queue mode) para distribuir execuções entre workers, evitando que um workflow pesado trave os demais.

Problemas comuns

• Rodar sem queue mode em um servidor com 2GB de RAM e ver a interface travar quando dois workflows disparam juntos.
• Histórico de execuções crescendo sem limpeza automática até estourar o disco.
• Confundir "sem WhatsApp" com "sem risco de RAM" — workflows com muitos nós de HTTP/loop também pesam.

Quando subir de plano

Mais de 20-30 workflows ativos, ou quando o time começar a pedir para adicionar Evolution API, Chatwoot ou Typebot por cima — aí vale migrar para uma das stacks acima.

Para quem é

Quem quer uma interface visual para subir, atualizar e monitorar containers Docker sem digitar comandos no terminal a cada deploy.

Qual plano usar

Cada um desses painéis tem seu próprio piso de RAM, tipicamente na faixa de 1-2GB só para o painel rodar, antes de qualquer app ser instalado por dentro dele. Para o painel + poucos apps leves, Básico (4GB) resolve. Assim que os apps gerenciados por dentro (n8n, Evolution API etc.) entram em produção, é o total de tudo somado — painel + apps — que define se você precisa de Performance ou Ultra.

Como funciona

Coolify, EasyPanel e Portainer são ferramentas concorrentes entre si: cada uma fala diretamente com o Docker/Docker Swarm da VPS para orquestrar containers, redes e volumes. Você escolhe uma — elas não se complementam, disputam a mesma função.

Problemas comuns

• Instalar mais de um painel na mesma VPS "para testar" e deixar os dois rodando — dobra o overhead à toa.
• Esquecer que o painel em si já consome RAM e dimensionar o plano só pelos apps.
• Atualizações do painel que exigem reinício de todos os containers gerenciados, gerando downtime se não avisado.

Quando subir de plano

Quando o número de containers gerenciados pelo painel (apps + bancos + workers) passar de uma dúzia rodando ao mesmo tempo, ou quando um dos apps gerenciados (como Evolution API com muitos números) já pedir Performance por conta própria.