Wafly › Comparativos › Baileys em produção

Baileys em produção em 2026: o que a biblioteca não resolve

Atualizado em 27 de julho de 2026 · dados conferidos no GitHub e no npm no mesmo dia

Se você é dev e está avaliando integrar WhatsApp, o Baileys é quase sempre a primeira parada: é gratuito, tem mais de 10 mil estrelas no GitHub e resolve o protocolo multi-device inteiro em TypeScript. Nada nesta página desmerece isso. O objetivo aqui é outro: mostrar o que continua sendo seu problema depois que a lib funciona, com fonte para cada afirmação, para você decidir com números em vez de otimismo.

O que o Baileys entrega (e o que não)

A biblioteca fala o protocolo do WhatsApp Web por WebSocket, sem navegador. Isso é a parte difícil e ela faz bem. O que a documentação oficial deixa explícito que é responsabilidade sua:

• Persistência de sessão. A doc diz, literalmente, que você deve implementar seu próprio auth state, seja em SQL, NoSQL ou Redis. Na v7 ele precisa suportar as chaves lid-mapping, device-list e tctoken.
• Um getMessage() ligado ao seu banco, necessário para reenvio de mensagem perdida e para decriptar voto de enquete.
• Cache de metadados de grupo. Sem cachedGroupMetadata, cada envio para grupo busca a lista de participantes. A própria doc avisa que isso causa rate limit e risco de banimento.
• Reconexão. Não existe reconexão gerenciada: você observa connection.update e reconecta na mão.
• Mapeamento PN↔LID. Toda sessão nova usa LID por padrão, e o mapeamento fica com você.

Some a isso monitoramento, fila, retry, deploy, atualização quando o WhatsApp muda, e você percebe que escolheu construir um produto de infraestrutura como pré-requisito para construir o seu produto.

Estado do projeto em julho de 2026

Fonte: API do GitHub e registry do npm, consultados em 27/07/2026.

Traduzindo: o projeto está vivo, mas lento. Nove meses de release candidate significa que quem roda a versão nova roda um RC em produção, e quem fica na 6.x fica para trás no protocolo. Vale registrar também a CVE-2026-48063, de severidade crítica, que permitia spoofing de mensagem e injeção de chaves falsas; foi corrigida em 20/05/2026 nas versões 7.0.0-rc12 e 6.7.22. Qualquer instalação anterior a isso está exposta, e uma dependência sem quem a atualize é exatamente como esse tipo de falha fica em produção por meses.

A armadilha de licença

Este é o ponto que mais surpreende quem já está com o produto em produção, porque a licença do repositório principal parece resolver a questão. Não é uma opinião nossa sobre risco jurídico: é a licença declarada da dependência, verificável em segundos. Não somos advogados e isto não é parecer jurídico; se o seu produto é fechado e distribuído, leve essa cadeia de dependências para quem é.

Para comparação: o WPPConnect é LGPL-3.0-or-later, que costuma ser mais previsível para consumo como dependência, embora obrigue a publicar modificações se você fizer fork da lib.

Os cinco problemas que aparecem em produção

Não são teoria: são as discussões mais movimentadas do repositório hoje.

1. Passkey no pareamento. Desde 30/06/2026, conectar por QR ou pairing code trava pedindo passkey (issue #2672, 87 comentários). Sem correção nem contorno oficial até o fechamento desta página. É uma mudança do WhatsApp, e quem depende da lib fica parado esperando.
2. Sessão corrompida. "Bad MAC", "Failed to decrypt", "No session", "Invalid PreKey". Existe uma issue guarda-chuva (#1769) criada pelo próprio time para consolidar mais de dez issues duplicadas, aberta desde setembro de 2025.
3. Mensagem "enviada" que não chega. A lib reporta sucesso e a mensagem não é entregue (#1963, #2653). É o pior modo de falha possível: silencioso.
4. Conexão viva e surda. As mensagens param de chegar, mas o socket continua aberto; só volta apagando a instância e lendo o QR de novo (#2060, #2331).
5. Vazamento de memória entre RCs. O padrão se repete a cada release candidate, e um dos casos é justamente o cenário multi-tenant, com várias sockets sob o mesmo key store (#1377).

Cada um desses itens é resolvível. A pergunta não é se você consegue, é se resolver isso é o seu negócio.

O 463 e o TC token: onde a engine importa

Este é o ponto mais técnico da página e o mais relevante para quem envia mensagem para contato novo.

O erro 463 (reachout timelock) acontece quando você manda mensagem para alguém que nunca falou com você e o pacote não carrega os campos de TC token. O WhatsApp contabiliza isso num limite de "abordagem", e a repetição vira restrição de conta. O issue #2707 descreve exatamente isso: 463 levando a banimento, porque a lib não gerencia o ciclo do token automaticamente. Existe trabalho em andamento numa branch separada, mas em 27/07/2026 não estava integrado ao master.

Aqui vale a transparência que a gente sempre pratica nestes comparativos: a Wafly não roda Baileys. Nossa infraestrutura é construída sobre whatsmeow, uma implementação em Go do mesmo protocolo, e o ciclo de TC token está implementado no nosso lado. Também tratamos o fluxo de passkey, que é o que está travando o pareamento no Baileys e no WPPConnect desde junho: no nosso caso ele foi validado em produção em julho de 2026.

E agora a parte que quase nenhum fornecedor escreve: trocar de biblioteca não te deixa imune a banimento. A detecção do WhatsApp é independente da lib e atinge whatsmeow e Baileys igualmente, inclusive contas de baixo volume. O que muda o resultado de verdade é o padrão de uso, e é sobre isso que escrevemos nesta página, com os dados que medimos na nossa frota.

E o WPPConnect?

É a outra opção open source popular no Brasil, e a arquitetura é diferente: em vez de falar o protocolo direto, ele abre um Chromium por sessão via Puppeteer, carrega o WhatsApp Web de verdade e injeta código na página. Isso traz uma vantagem real (o comportamento é o do cliente oficial) e um custo grande.

O número mais útil vem de dentro do projeto: uma issue aberta pelo próprio time mostra uma sessão consumindo cerca de 387 MB em quatro processos do Chromium, com 15% de CPU. A mesma discussão relata produção real batendo 30 GB de 32 GB de RAM, com um caso de uma única sessão usando 12 GB, sem forma nativa de descobrir qual sessão estava vazando.

Em compensação, o WPPConnect tem cadência de release melhor que a do Baileys (v2.2.4 em 24/07/2026) e licença mais previsível. O ponto de atenção é o bus factor: a manutenção humana se concentra em duas pessoas. E, como já dito, ele foi atingido pelo mesmo problema de passkey em julho de 2026.

Baileys vs WPPConnect vs Wafly

Quando ficar no Baileys

Existem casos claros em que o Baileys é a escolha certa e pagar por API seria desperdício:

• Projeto pessoal, protótipo ou volume pequeno. Se um número cair e voltar meia hora depois, e ninguém perder dinheiro com isso, o custo zero ganha de qualquer argumento.
• Você precisa de controle total do protocolo. Comportamento fora do padrão, experimentação, pesquisa: com uma API gerenciada você fica limitado ao que ela expõe.
• Seu produto é justamente infraestrutura de WhatsApp. Aí manter a lib não é distração, é o core.
• Restrição real de orçamento. R$ 59,90 por número é dinheiro, e quem está começando às vezes tem mais tempo do que caixa. É uma troca legítima.

Quando vale pagar

A conta fica simples quando você coloca a sua hora na planilha. Se manter a integração custa 4 horas por mês entre atualizar, investigar sessão corrompida e reconectar número, e a sua hora vale R$ 100, o "grátis" custa R$ 400 por mês. Nesse cenário a comparação não é R$ 59,90 contra R$ 0, é R$ 59,90 contra R$ 400 mais o risco de a operação parar num dia em que você não pode atender.

Some o custo de oportunidade: o mês que você gasta implementando auth state, cache de grupo, reconexão e observabilidade é um mês que você não gastou no que o seu cliente paga para ter. Fizemos essa mesma conta, com mais detalhe, na análise do self-host da Evolution API, que por sua vez também roda Baileys por baixo.

Perguntas frequentes

Continue comparando

Baileys, WPPConnect, whatsmeow, Evolution API e WhatsApp são marcas e projetos de seus respectivos donos, sem relação com a Wafly. Dados de estrelas, issues, versões e datas conferidos na API do GitHub e no registry do npm em 27/07/2026; projetos open source mudam rápido, confira na fonte. As observações sobre licenciamento descrevem licenças declaradas publicamente e não constituem orientação jurídica. Encontrou algo desatualizado? Fale com a gente que corrigimos.