Wafly › Blog › Consumo de servidor

Quanto de servidor uma API de WhatsApp realmente consome

Atualizado em 31 de julho de 2026 · baseado em dados da nossa própria operação e em fontes primárias citadas ao longo do texto

Quase todo comparativo de API de WhatsApp discute preço de licença e número de endpoints. Quando alguém decide self-hostear, a surpresa raramente vem da licença: vem da conta de servidor no fim do mês. Esta página faz essa conta com os números que dá para verificar, e diz explicitamente onde a gente não mediu.

De onde vem o consumo: navegador ou protocolo

Existem duas famílias de implementação de WhatsApp não oficial, e elas têm perfis de consumo completamente diferentes.

A primeira automatiza o WhatsApp Web dentro de um navegador headless. É o caso do WPPConnect, que roda Node.js com Chromium por sessão. Cada número conectado carrega um Chromium inteiro, com renderização, JavaScript da página e todo o overhead de um navegador de verdade rodando sem tela.

A segunda implementa o protocolo do WhatsApp diretamente, sem navegador nenhum. É o caso do Baileys (Node.js, protocolo nativo, sem navegador) e do whatsmeow, que é o que roda na nossa infraestrutura. O processo mantém a conexão, as chaves de criptografia e o estado da sessão, e nada mais.

A diferença arquitetural entre as duas famílias explica quase toda a variação de custo de máquina. Não é otimização de código, é o que cada uma decidiu carregar.

Quanto de RAM por número, na prática

O caso extremo do lado do navegador está documentado publicamente: relato de 30 GB de 32 GB consumidos em servidor de produção. Não é um bug exótico, é o comportamento esperado quando você multiplica um Chromium por número conectado numa máquina que não foi dimensionada para isso.

A conta do servidor para 1, 10 e 50 números

Trabalhando só com o número que está verificado, cerca de 387 MB de RAM por sessão de WPPConnect, a projeção de memória fica assim:

A coluna da direita não é exagero. Sessão de WhatsApp tem pico: sincronização de histórico ao reconectar, recebimento de mídia e reinício de sessão consomem bem acima da média em rajada. Dimensionar pela média é o erro que produz o caso de 30 GB de 32 GB.

Deliberadamente não colocamos preço de VPS nesta tabela. O preço do GB de RAM varia por provedor, região e compromisso de prazo, e um número desses envelhece rápido. Pegue o valor do seu provedor e multiplique. O que essa tabela dá é a variável que quase ninguém considera antes de contratar: você dimensiona por conexões simultâneas, não por volume de mensagens.

O segundo gargalo: banco de dados e conexões

Memória é o custo visível. O que costuma quebrar depois é o banco.

Na nossa operação, o serviço de conexão roda distribuído em 6 deployments do serviço de conexão com um pool de 2 conexões de Postgres por instância. Parece pouco por instância, e é justamente esse o ponto: multiplicado por dezenas de números, o total de conexões abertas encosta no teto do banco muito antes de a CPU ou a memória darem sinal. Quem self-hosteia costuma descobrir esse limite em produção, no dia em que sobe do décimo para o vigésimo número.

O histórico de mensagens é o outro eixo. Ele cresce com o tráfego e não com o número de conexões, então é um custo que aparece meses depois de a arquitetura já estar decidida. Vale planejar retenção antes, não quando o disco encher.

Onde o self-host realmente ganha

Não somos neutros nessa comparação, então vamos ser explícitos sobre onde o self-host é a escolha certa.

• Uma ou duas instâncias de uso interno. O custo de máquina é irrelevante nessa escala e você não paga mensalidade nenhuma. A Evolution API é Apache 2.0 e gratuita para self-host.
• Controle total sobre o dado. Se a política da empresa não permite mensagem trafegando por terceiro, a discussão de custo nem começa.
• Necessidade de modificar a biblioteca. Quem precisa de comportamento fora do padrão vai precisar do código na mão.

E onde ele costuma sair caro: quando o número fora do ar custa dinheiro. O gasto real do self-host não é a máquina, é o tempo de quem religa a sessão às 22h de domingo, acompanha mudança de protocolo do WhatsApp e mantém a biblioteca atualizada. Vale lembrar que o Baileys está com 7.0.0 em release candidate desde outubro de 2025 e carrega CVE-2026-48063, severidade crítica, o que dá a dimensão do trabalho de manutenção que vem junto.

Como medir antes de contratar máquina

Antes de fechar servidor, rode este teste, que leva menos de uma hora:

1. Suba a biblioteca escolhida com um número real conectado.
2. Deixe a sessão no ar por 24 horas, com tráfego parecido com o seu.
3. Meça a memória residente do processo no pico, não na média. Em Linux, acompanhe o RSS do processo ao longo do dia.
4. Force uma reconexão e meça de novo: a sincronização é o pico verdadeiro.
5. Multiplique o pico pelo número de conexões que você pretende manter, e some 50% de folga para o sistema operacional e o banco.

Se o resultado couber no seu orçamento de infraestrutura, self-host faz sentido. Se não couber, a mensalidade de um gerenciado provavelmente é mais barata que a máquina que você teria que contratar, e é exatamente essa a conta que a maioria não faz antes de decidir.

O que isso tem a ver com estabilidade do número

Servidor mal dimensionado não bane número, mas produz o sintoma que costuma ser confundido com banimento: sessão caindo sozinha. Memória no limite derruba processo, processo derrubado reconecta, e um número que reconecta o tempo todo é um número instável para quem depende dele.

Na nossa frota, a causa dos bloqueios que registramos é outra e está bem separada disso: 17 eventos de erro 463 registrados, 100% deles em mensagem para contato sem histórico de conversa, nenhum em resposta a quem escreveu primeiro. Ou seja, comportamento de abordagem, não consumo de máquina. Vale mencionar aqui porque os dois problemas se apresentam do mesmo jeito para quem está de fora, com o número parando de funcionar, e o diagnóstico é completamente diferente. Se quiser entender o lado do bloqueio, o assunto está detalhado em número banido no WhatsApp.

Perguntas frequentes

Continue lendo

WhatsApp e Meta são marcas de seus respectivos donos, sem relação com a Wafly. Os preços de terceiros citados foram verificados na data indicada em cada tabela e mudam sem aviso: confira na fonte antes de decidir. Encontrou algo desatualizado ou discorda de alguma conclusão? Fale com a gente.