TL;DR: migrar da Evolution API self-hosted para uma solução gerenciada compensa quando você opera 10 ou mais instâncias e o tempo de manutenção de infra passa a competir com o desenvolvimento do produto. O modelo "gratuito" costuma custar de R$700 a R$1.500 por mês em servidor, horas de DevOps e downtime. Com 2 ou 3 instâncias estáveis, continue no self-hosted. A migração é feita rodando os dois ambientes em paralelo e leva de 1 a 3 dias, sem downtime.
Se você usa a Evolution API para 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 para 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 para 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. Para 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 para o momento que seu negócio está.
Quais são os sinais de que o self-hosted está te travando?
São cinco sinais, e bastam dois deles para o alerta acender: instâncias caindo em pico, time virando equipe de infraestrutura, medo de atualizar, dor para escalar e segurança virando incerteza. Esses são os padrões que mais aparecem em conversas com agências e devs que operam dezenas de instâncias.
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 para o 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 para configurar, mais um container consumindo memória, mais uma coisa para 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á para 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.
Por que Docker vira problema em escala?
Porque rodar 20 ou mais instâncias de WhatsApp em produção com Docker é um problema de operação, não de deploy. Docker é ótimo para deploy: isolamento, portabilidade, facilidade de reproduzir ambientes. Mas usar Docker para sustentar dezenas de sessões de WhatsApp em produção é diferente de usar Docker para 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?
Entre R$700 e R$1.500 por mês para uma operação com 10 ou mais instâncias, somando servidor, horas técnicas e o risco de downtime. Na superfície, a Evolution API parece gratuita: o software é open-source, você baixa e usa. O custo total de operação vai bem além da licença.
| Componente do custo | O que entra | Custo mensal típico |
|---|---|---|
| Servidor | VPS para ~10 instâncias, memória, disco, IP fixo, backup | R$150 a R$500 |
| Tempo do time | 8 a 15 horas/mês de manutenção, updates, debug e onboarding de cliente (a R$50/hora) | R$400 a R$750 |
| Downtime | Leads que esfriam, vendas paradas, cliente reclamando. Uma agência que perde 4 horas numa campanha pode perder milhares | Difícil de calcular, sempre real |
| Atualizações | Homologação, parada para migrar containers, ajuste de scripts, teste de webhooks, rollback quando quebra | Um turno inteiro por evento |
| Total realista | R$700 a R$1.500 |
Quando você soma tudo, o modelo "gratuito" para uma operação com 10 ou mais instâncias costuma ficar nessa faixa. 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?
Muda quem carrega a 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 estas:
| Critério | Evolution API (self-hosted) | Zapster (gerenciado) |
|---|---|---|
| Setup de nova instância | Configura Docker, portas, volumes e variáveis de ambiente | Cria em um clique no dashboard |
| Webhooks | Configuração manual por instância, ajustando URLs e eventos | Configuração no dashboard, com filtro por tipo de evento e retry automático |
| Escalabilidade | Mais instâncias significa mais servidor, mais configuração, mais monitoramento | Cria mais instâncias e a infra escala sozinha |
| Isolamento | Containers dividem os recursos do mesmo servidor | Cada instância é um Pod Kubernetes dedicado |
| Atualizações | Você testa e aplica manualmente | A plataforma cuida disso |
| Suporte | Comunidade open-source (boa, mas sem SLA) | 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 para o oficial por compliance ou escala, não precisa mudar código. A API é a mesma, os webhooks são os mesmos. Essa diferença entre os dois modelos está detalhada no comparativo de API oficial do WhatsApp versus API não oficial.
Como migrar sem derrubar nada?
Rodando os dois ambientes em paralelo e movendo os números aos poucos. A migração não precisa ser tudo de uma vez, e é justamente o paralelo que garante zero downtime. O caminho seguro tem seis passos:
- Suba uma instância piloto. Cria uma conta na Zapster e conecta um número de teste, por QR Code ou pela API oficial, dependendo do que quiser experimentar.
- Replique os webhooks. Configura os mesmos eventos que você já tem na Evolution, ajusta as URLs e testa o recebimento.
- Pluga as 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.
- Rode em paralelo por alguns dias. Mantém a Evolution funcionando normalmente enquanto valida tudo na nova plataforma: manda mensagens de teste, verifica se os webhooks chegam, confere se as automações disparam.
- Migre os números de verdade. Começa pelos clientes menos críticos e vai subindo conforme a estabilidade se confirma.
- Desligue o ambiente antigo. Só depois de validar métricas e estabilidade no ambiente novo.
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 para os 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 os ambientes em paralelo.
- Migrar clientes gradualmente, começando pelos menos críticos.
- Validar métricas e estabilidade antes de desligar o ambiente antigo.
Vale considerar a API oficial da Meta na hora de migrar?
Vale, porque trocar de infraestrutura é o momento mais barato para também trocar o tipo de conexão. A API oficial do WhatsApp (Cloud API da Meta) está ganhando espaço por motivos concretos: sem risco de bloqueio do número, limites de envio claros e documentados, e suporte a templates de mensagem aprovados pela Meta.
A desvantagem é o modelo de cobrança. Veja a diferença:
| Critério | QR Code (não oficial) | API oficial (Cloud API) |
|---|---|---|
| Cobrança | Por instância, independente do volume | Por conversa/mensagem, variando por país e categoria |
| Risco de bloqueio do número | Existe | Não existe quando as políticas da Meta são respeitadas |
| Limites de envio | Não documentados oficialmente | Claros e documentados por tier |
| Templates aprovados | Não se aplica | Sim, obrigatório para iniciar conversa |
| Melhor cenário | Alto volume com margem apertada | Operação que precisa de previsibilidade e compliance |
Para operações de alto volume com margem apertada, a conta precisa ser feita antes de trocar. Na Zapster, você pode ter instâncias oficiais e não oficiais na mesma conta. O mesmo endpoint de envio funciona para ambas, os mesmos webhooks. Isso significa que você pode começar com QR Code, que é mais barato, e migrar números específicos para o oficial quando o cenário pedir, sem reescrever nada.
Se quiser entender melhor como funciona a API oficial, temos um guia de integração com a API oficial do WhatsApp em escala.
Para quem faz sentido migrar (e para quem não faz)?
Faz sentido para quem opera 10 ou mais instâncias e vê o tempo de manutenção subir. Não faz para quem tem 2 ou 3 instâncias rodando bem. Nem todo mundo precisa migrar, e vou ser direto sobre isso.
| Situação | Migrar faz sentido | Continuar no self-hosted faz sentido |
|---|---|---|
| Volume de instâncias | 10 ou mais, com manutenção crescendo | 2 a 5, estáveis |
| Onde o time gasta tempo | Mais em DevOps do que no produto | Time com experiência em Docker e Kubernetes, que gosta de controlar a stack |
| Expectativa de estabilidade | Clientes que esperam SLA | Downtime é raro e tolerável |
| Custo atual de servidor | Alto ou imprevisível | Baixo e previsível |
| Necessidade de API oficial | Quer a opção sem montar infra separada | Não está no radar |
A Evolution é um projeto de qualidade, mantido por uma comunidade ativa. Se o modelo self-hosted funciona para o 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. Se você ainda está escolhendo entre fornecedores, o comparativo das melhores APIs de WhatsApp coloca as opções lado a lado.
Principais conclusões
- A decisão não é sobre a qualidade da Evolution API, é sobre o momento do seu negócio.
- O ponto de virada costuma ser 10 instâncias, quando manutenção de infra passa a competir com desenvolvimento.
- O custo real do self-hosted em escala fica entre R$700 e R$1.500 por mês, somando servidor, horas técnicas e downtime.
- Isolamento por instância elimina o efeito cascata, que é o problema mais caro do modelo com containers compartilhados.
- Migração em paralelo, começando pelos clientes menos críticos, entrega zero downtime em 1 a 3 dias.
- Trocar de infraestrutura é o momento certo para avaliar também a API oficial da Meta.
Para fechar
Migrar da Evolution API para 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 para o produto, para o atendimento, para a 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 para automações seguras.