O Evolution CRM não cobra licença, então esta página é sobre a única fatura que existe de fato: o servidor. E sobre uma característica que muda a natureza dessa fatura.
A conta que não cresce com a equipe
Vale começar pelo que diferencia, porque é isso que justifica assumir a operação.
Em Kommo, WATI e BotConversa, você paga por assento. Cada atendente contratado aumenta a mensalidade, e continua aumentando enquanto a operação crescer.
Aqui você paga o servidor. O quinto atendente custa zero. O décimo quinto custa zero em licença e um pouco de memória. Em algum momento a máquina aperta e você sobe de plano, o que é um degrau, não uma linha reta.
A consequência prática: em operação que cresce em gente, a curva de custo é completamente diferente. A conta detalhada, com o ponto de virada por número de atendentes, está em preços. O resumo é que a virada acontece na faixa de cinco a oito assentos, e depois dela a diferença deixa de ser desconto e vira outra ordem de grandeza.
Que máquina o seu volume pede
O Evo CRM é uma stack completa: painel, banco, processamento de automação e agentes. Ele pede mais que a Evolution API, que é só a tubulação.
O que dimensiona não é o número de atendentes em si. É a quantidade de conversas simultâneas e o tamanho do histórico, porque toda conversa aberta mantém estado e todo atendimento antigo continua no banco.
2 vCPU e 4 GB. Ponto de partida razoável. Equipe pequena, algumas dezenas de conversas simultâneas, automação leve. Serve para implantar e validar a operação com gente de verdade usando.
4 vCPU e 8 GB. Onde a maioria das operações com equipe fica confortável. Muitas conversas abertas ao mesmo tempo, agentes de IA ativos, histórico crescendo, relatório rodando sem travar o atendimento.
Acima disso. Quando o atendimento é a operação inteira, com dezenas de pessoas e volume contínuo, vale separar o banco em instância própria em vez de crescer a máquina única. É o momento de tratar como infraestrutura, não como aplicação.
Três decisões de instalação que evitam retrabalho
PostgreSQL desde o início, com volume persistido. Não é aplicação para banco embutido. E persistência mal configurada significa perder conversa de cliente num reinício, que é o pior tipo de perda.
Mídia em armazenamento externo se o volume for alto. Áudio e imagem de atendimento enchem disco mais rápido do que a intuição sugere, e disco cheio não degrada devagar: derruba a plataforma. O sintoma aparece como “o painel não abre”, e a causa demora a ser encontrada.
Retenção definida. Histórico de anos é bom para consulta e ruim para desempenho. Decidir o que fica quente e o que vai para arquivo é mais fácil no começo do que quando o banco já está grande.
O caminho curto
Instalar na mão é Docker mais banco mais proxy reverso mais certificado, e depois a configuração do canal oficial do WhatsApp. Funciona, e é algumas horas na primeira vez.
A HostGator vende um VPS com o Evolution CRM pronto para uso, com servidor no Brasil e cobrança em real, a partir de R$ 69,99 por mês no plano de três anos. Segundo a HostGator, o provisionamento é instantâneo, com acesso root, disco NVMe e suporte com fila prioritária.
Vale ser exato sobre o alcance disso: resolve o provisionamento, não a operação. O servidor é seu, o root é seu, e atualizar a plataforma, acompanhar versão e garantir que o backup restaura continuam na sua conta. É atalho de instalação, não terceirização de manutenção.
Duas coisas que o atalho não abrevia: a aprovação do número no WhatsApp Business Platform, que depende do Meta e leva dias, e o desenho das filas e do treinamento da equipe, que é onde implantação de CRM realmente falha. Tratei disso no tutorial.
Latência a favor do servidor no Brasil: painel que a equipe usa o dia inteiro tem responsividade percebida, e cada ida e volta a um datacenter fora do país aparece na sensação de lentidão.
O que você assume ao hospedar atendimento
Esta seção é mais séria aqui do que numa ferramenta de automação, e vale dizer por quê: o que está no seu servidor é o histórico de conversa dos seus clientes.
Você virou guardião de dado pessoal de terceiros. Nome, telefone, e o conteúdo do que essas pessoas te contaram. Isso implica acesso restrito, painel atrás de autenticação forte, e a obrigação de manter a versão em dia. Não é higiene de servidor: é responsabilidade sobre dado de outra pessoa.
Queda é receita parada, e é silenciosa. Se a plataforma cai, a mensagem que chega nesse período não entra. O cliente não recebe erro, ele só não é atendido, e você descobre pela reclamação. Monitoramento com alerta que acorda alguém não é luxo nesse cenário.
Backup que restaura de verdade. O que importa é o banco com contatos e conversas, mais a mídia. Teste a restauração num servidor limpo. Backup nunca restaurado não é backup, e aqui o que está em jogo é o histórico comercial da empresa.
Atualização. Plataforma de atendimento exposta na internet com versão velha é superfície de ataque com dado de cliente dentro. Acompanhar release deixa de ser opcional.
O que muda quando o time dobra
Uma pergunta que quase nunca é feita na hora de escolher e que aparece seis meses depois: o que acontece com a infraestrutura quando a equipe vai de cinco para dez pessoas?
Na nuvem, nada acontece na infraestrutura e tudo acontece na fatura. Você contrata, paga mais, e a plataforma se ajusta sozinha.
Aqui é o inverso, e vale saber a ordem em que as coisas apertam:
Primeiro a memória. Mais gente atendendo significa mais conversas abertas ao mesmo tempo, e conversa aberta mantém estado. O sintoma é lentidão no painel em horário de pico, não erro.
Depois o banco. Dobro de atendimento é dobro de histórico por mês. Consulta e relatório ficam mais lentos antes de qualquer coisa quebrar, e é aí que a política de retenção se paga.
Por último o disco. Mídia acumula proporcionalmente ao atendimento. Este é o único dos três que não avisa: ele simplesmente derruba a plataforma quando enche.
O planejamento que funciona é simples: monitore memória e disco com alerta antes de 80%, e revise o dimensionamento sempre que a equipe crescer 50%. Subir de plano de VPS é questão de minutos quando planejado, e de madrugada quando não.
Quando essa troca não compensa
Já disse em outras páginas e repito aqui porque é a decisão que mais gente erra: com dois ou três atendentes, não compensa. A economia em licença é pequena, o custo em horas é real, e você herda a responsabilidade de guardar dado de cliente. Uma plataforma na nuvem faz isso melhor e mais barato nessa escala. As opções estão em alternativas.
O self-hosted começa a fazer sentido quando o time cresce, quando existe alguém cuidando de infraestrutura, ou quando o requisito de manter o dado em casa é uma exigência e não uma preferência.
Onde ir depois
A conta completa, com o ponto de virada por atendente, está em preços. O julgamento sobre a plataforma servir ao seu caso, no review. O passo a passo de implantação, incluindo o desenho de filas, no tutorial.