Se você usa a Evolution API pra conectar números de WhatsApp, provavelmente conhece o ciclo: tudo funciona por semanas, aí uma campanha grande entra, o servidor trava, três instâncias caem de uma vez e você passa a manhã seguinte reiniciando containers em vez de trabalhar no produto. Ou então sai uma atualização da Evolution, você aplica, e dois fluxos que rodavam há meses quebram sem aviso.
A Evolution API é uma ferramenta boa. Não estou aqui pra falar mal dela. Mas tem um ponto onde manter tudo rodando no seu servidor começa a custar mais do que deveria. Não só em dinheiro. Em tempo do time, em madrugadas resolvendo queda, em clientes reclamando antes de você sequer perceber que algo parou.
Esse artigo é sobre o que muda quando você sai do modelo self-hosted e vai pra uma solução onde outra empresa cuida da infraestrutura. Vou ser direto sobre onde faz sentido, onde não faz, e como migrar sem derrubar nada no processo.
O que é a Evolution API e por que ela ficou tão popular no Brasil
A Evolution API é um projeto open-source que permite conectar vários números de WhatsApp numa API REST. Você sobe num servidor, geralmente com Docker, e cada número vira uma instância que pode enviar e receber mensagens, processar webhooks e se integrar com ferramentas como N8n, Make ou Chatwoot.
Ela ganhou espaço no Brasil por três motivos bem práticos: é gratuita, flexível e tem uma comunidade ativa que ajuda com dúvidas e configurações. Pra quem está começando com automação de WhatsApp ou tem poucos números conectados, funciona muito bem.
O setup tradicional passa por instalar o Docker no servidor, configurar as variáveis de ambiente, subir os containers e ajustar cada instância separadamente. Com 3, 5 números, isso é gerenciável. Você faz o deploy uma vez, monitora de vez em quando, e segue trabalhando no que importa.
O cenário muda quando a operação cresce. Com 10, 15, 20 instâncias no mesmo servidor, os problemas começam a se acumular:
- Containers disputam memória e CPU. Um pico de envio num número pode afetar todos os outros
- Uma instância travando pode derrubar o container vizinho que compartilha recursos
- Cada webhook precisa ser configurado manualmente, por instância, por cliente
- Atualizações da Evolution exigem que você teste em staging antes de aplicar em produção, senão arrisca quebrar fluxos que já funcionavam
A Evolution continua sendo uma boa ferramenta. A pergunta é se gerenciar a infraestrutura dela faz sentido pro momento que seu negócio está.
Sinais de que o modelo self-hosted está te travando
Esses são os padrões que mais aparecem em conversas com agências e devs que operam dezenas de instâncias. Se você se identificar com dois ou mais, vale prestar atenção.
O primeiro é instâncias caindo em horário de pico. Campanha de Black Friday, envio em massa, promoção relâmpago. O tráfego sobe, o servidor não aguenta, e as mensagens ficam presas na fila. O cliente reclama antes de você abrir o terminal.
O segundo é o time virando equipe de infraestrutura. O desenvolvedor que deveria estar criando automações está debugando erro de rede entre containers, ajustando volumes Docker e monitorando uso de disco. Tempo de dev gasto com DevOps é tempo que não vai pro produto.
O terceiro é o medo de atualizar. Cada versão nova da Evolution pode quebrar integrações que já funcionam. Com 5 instâncias, você testa rápido e atualiza. Com 20, precisa de staging, homologação, plano de rollback. Isso pode levar horas, e mesmo assim algo pode escapar.
O quarto é que escalar dói. Novo cliente? Mais uma instância, mais um webhook pra configurar, mais um container consumindo memória, mais uma coisa pra monitorar de madrugada. No modelo self-hosted, cada novo número é trabalho manual repetitivo.
E o quinto é a segurança virando incerteza. Cada servidor exposto é uma superfície de ataque. Volume Docker mal configurado, endpoint sem autenticação, certificado SSL que expirou e ninguém percebeu. Quando a operação é pequena, dá pra vigiar tudo. Quando cresce, algo sempre escapa.
Se dois ou três desses pontos soam familiares, a complexidade da infra provavelmente está crescendo mais rápido que a sua capacidade de mantê-la estável.
O problema específico do Docker em escala
Docker é ótimo pra deploy. Isolamento, portabilidade, facilidade de reproduzir ambientes. Mas usar Docker pra rodar 20+ instâncias de WhatsApp em produção é diferente de usar Docker pra subir um projeto pessoal.
Os problemas que mais aparecem em quem opera Evolution API com Docker em escala:
- Erros de rede entre containers que aparecem de forma intermitente e são difíceis de reproduzir
- Gerenciamento de volumes fica complexo quando cada instância tem seus próprios dados de sessão
- Upgrade de imagens pode quebrar dependências que não estão documentadas
- Recuperação de falhas depois de um update mal-sucedido consome horas do time
- Roteamento de webhooks exige configuração nova a cada cliente, dificultando padronização
A pergunta que vale a pena fazer: quanto tempo o time economizaria se não precisasse gerenciar Dockerfiles, scripts de restart e logs de containers caindo?
Quanto realmente custa rodar Evolution API no seu servidor
Na superfície, a Evolution API parece gratuita. O software é open-source, você baixa e usa. Mas o custo total de operação vai além da licença:
Tem o custo do servidor. Uma VPS básica pra rodar 10 instâncias fica entre R$150 e R$500 por mês, dependendo de quanto recurso você precisa. Memória, disco, IP fixo, backup, tudo entra na conta.
Tem o custo do tempo. Manutenção, updates, debug de problemas em produção, configuração de novos clientes, monitoramento. Dependendo da operação, isso consome de 8 a 15 horas por mês do time técnico. Se você paga R$50/hora pra um dev, são R$400 a R$750 por mês só em manutenção de infra.
Tem o custo do downtime. Quando cai, os leads esfriam, as vendas param, os clientes reclamam. Esse custo é difícil de calcular, mas é real. Uma agência que perde 4 horas de operação durante uma campanha pode perder milhares de reais em receita.
E tem o custo das atualizações. Versão nova da Evolution exige homologação. Tempo de parada pra migrar containers, ajustar scripts, testar webhooks. Se algo quebra, reverter e corrigir pode levar mais um turno inteiro.
Quando você soma tudo, o modelo "gratuito" pra uma operação com 10+ instâncias costuma ficar entre R$700 e R$1.500 por mês em custo real. Isso muda a conta na hora de comparar com uma solução gerenciada onde você paga por instância e não se preocupa com o resto.
O que muda com uma solução gerenciada
Migrar de self-hosted pra gerenciado significa que outra empresa cuida da infraestrutura. No caso da Zapster, cada instância roda isolada em Kubernetes. Se uma instância tiver problema, as outras não são afetadas. Sem compartilhamento de recursos, sem efeito cascata.
Na prática, as diferenças mais visíveis são:
Setup de nova instância: na Evolution, você configura Docker, portas, volumes, variáveis de ambiente. Na Zapster, cria em um clique no dashboard.
Webhooks: na Evolution, configura manualmente por instância, ajustando URLs e eventos. Na Zapster, configura no dashboard com filtros por tipo de evento e retry automático.
Escalabilidade: na Evolution, mais instâncias significa mais servidor, mais configuração, mais monitoramento. Na Zapster, é só criar mais instâncias. A infra escala sozinha.
Isolamento: na Evolution com Docker, containers compartilham os recursos do servidor. Na Zapster, cada instância é um Pod Kubernetes dedicado.
Atualizações: na Evolution, você testa e aplica manualmente. Na Zapster, a plataforma cuida disso.
Suporte: na Evolution, depende da comunidade open-source (que é boa, mas não tem SLA). Na Zapster, tem suporte direto.
Um ponto que vale destacar: a Zapster suporta tanto conexão por QR Code (não oficial) quanto a API oficial da Meta na mesma plataforma. Se amanhã você precisar migrar um número pro oficial por compliance ou escala, não precisa mudar código. A API é a mesma, os webhooks são os mesmos.
Como migrar sem derrubar nada
A migração não precisa ser tudo de uma vez. O caminho mais seguro é rodar os dois ambientes em paralelo e ir movendo aos poucos. Funciona assim:
Primeiro, cria uma conta na Zapster e sobe uma instância piloto com um número de teste. Conecta por QR Code ou pela API oficial, dependendo do que quiser experimentar.
Depois, configura os webhooks replicando o que você já tem na Evolution. Ajusta as URLs e testa o recebimento de eventos.
O terceiro passo é plugar suas automações existentes. Se usa N8n, Make ou código customizado, basta trocar a URL base e o token de autenticação. A estrutura dos endpoints é compatível.
Aí vem a parte mais importante: roda em paralelo por alguns dias. Mantém a Evolution funcionando normalmente enquanto valida tudo na Zapster. Manda mensagens de teste, verifica se os webhooks chegam, confere se as automações disparam corretamente.
Quando tiver confiança, começa a migrar os números de verdade. O ideal é começar pelos clientes menos críticos e ir subindo conforme tudo se confirma estável.
O processo todo costuma levar de 1 a 3 dias, dependendo da quantidade de instâncias e da complexidade das automações. E o mais importante: zero downtime pros seus clientes durante a transição.
Checklist de migração
- Documentar todas as integrações, webhooks e dependências do ambiente atual
- Criar instâncias na Zapster para cada número ou cliente
- Configurar eventos de webhook (mensagens recebidas, entregues, lidas, falhas)
- Atualizar URLs e tokens nas ferramentas de automação (N8n, Make, código)
- Testar envio e recebimento com ambientes em paralelo
- Migrar clientes gradualmente, começando pelos menos críticos
- Validar métricas e estabilidade antes de desligar o ambiente antigo
API oficial da Meta: por que considerar na hora de migrar
Se você já está pensando em mudar de infraestrutura, faz sentido considerar também o tipo de conexão. A API oficial do WhatsApp (Cloud API da Meta) está ganhando espaço por alguns motivos concretos: sem risco de bloqueio do número, limites de envio claros e documentados, suporte a templates de mensagem aprovados pela Meta.
A desvantagem é que a API oficial cobra por conversa (o preço varia por país e tipo de conversa), enquanto a conexão por QR Code cobra por instância independente do volume. Pra operações de alto volume com margem apertada, a conta precisa ser feita.
Na Zapster, você pode ter instâncias oficiais e não oficiais na mesma conta. O mesmo endpoint de envio funciona pra ambas. Os mesmos webhooks. Isso significa que você pode começar com QR Code, que é mais barato, e migrar números específicos pra oficial quando o cenário pedir, sem reescrever nada.
Se quiser entender melhor como funciona a API oficial, temos um guia sobre integração com a API oficial do WhatsApp.
Pra quem faz sentido migrar (e pra quem não faz)
Nem todo mundo precisa migrar. Vou ser direto sobre isso.
Migrar faz sentido se você gerencia 10 ou mais instâncias e o tempo gasto com manutenção de infra está aumentando. Faz sentido se o time técnico gasta mais tempo com DevOps do que com o produto. Faz sentido se você precisa de estabilidade garantida porque atende clientes que esperam SLA. E faz sentido se quer ter a opção de usar API oficial sem ter que montar uma infra separada pra isso.
Pode não fazer sentido se você tem 2, 3 instâncias e tudo funciona bem. Se o time tem experiência com Docker e Kubernetes e gosta de ter controle total da stack. Se o custo do servidor atual é baixo e downtime é raro. Nessas condições, a Evolution API self-hosted continua sendo uma escolha válida.
A Evolution é um projeto de qualidade, mantido por uma comunidade ativa. Se o modelo self-hosted funciona pro seu momento, continue com ele. A migração faz sentido quando o custo de manter começa a ultrapassar o custo de pagar por uma solução gerenciada.
Pra fechar
Migrar da Evolution API pra uma solução gerenciada não é sobre a ferramenta ser ruim. É sobre o momento do negócio. Quando a operação cresce, o self-hosted começa a consumir energia que deveria ir pro produto, pro atendimento, pra venda.
A transição pode ser gradual. Sem downtime. Rodando em paralelo até ter confiança. E com a Zapster, você ganha isolamento por instância, suporte a API oficial e não oficial, webhooks com retry automático e um dashboard que centraliza a gestão.
Se os sinais que descrevi aqui soam familiares, pode valer testar. Cria uma conta gratuita na Zapster, sobe uma instância piloto e vê como funciona na prática. Sem compromisso, sem migração forçada.
E se quiser um comparativo mais técnico entre as duas ferramentas, temos um artigo dedicado a Evolution API vs Zapster API.
Perguntas frequentes
O que é a Evolution API para WhatsApp?
É um projeto open-source que permite conectar vários números de WhatsApp via API REST. Popular entre agências de automação e desenvolvedores no Brasil por ser gratuita e compatível com N8n, Make e Chatwoot.
Quanto custa usar a Evolution API?
O software é gratuito, mas o custo total de operação inclui servidor (VPS ou dedicado), tempo de DevOps pra manutenção e o risco de downtime. Pra operações com 10+ instâncias, o custo real costuma ficar entre R$700 e R$1.500 por mês quando se soma tudo.
Consigo migrar sem parar minha operação?
Sim. A migração pode ser feita rodando os dois ambientes em paralelo. Você mantém a Evolution funcionando enquanto configura e testa na nova plataforma. Só desliga o ambiente antigo quando tudo estiver validado.
A Zapster suporta a API oficial do WhatsApp?
Sim. Dá pra conectar números via QR Code (não oficial) e via API oficial da Meta (Cloud API) na mesma conta, usando a mesma API e os mesmos webhooks.
Preciso reescrever minhas automações ao migrar?
Na maioria dos casos, não. Se você usa N8n, Make ou integrações HTTP, basta trocar a URL base e o token de autenticação. A estrutura dos endpoints e webhooks é compatível.
A Evolution API é ruim?
Não. A Evolution é um projeto sólido com uma comunidade ativa. O ponto não é a qualidade da ferramenta, mas se gerenciar a infraestrutura dela faz sentido pro seu momento. Pra operações menores, funciona muito bem. Pra quem está escalando e quer focar no produto em vez de na infra, uma solução gerenciada pode fazer mais sentido.
