Bem-vindo!
Qual tipo de recurso?
Outro
Qual a motivação para a solicitação?
A partir da versão v2.4.0, a Evolution API passou a exigir ativação de licença no primeiro acesso ao Manager em /manager.
Entendo a necessidade de um sistema de licenciamento, porém a forma atual exige uma etapa manual e interativa antes que a API possa operar normalmente. Isso quebra ambientes automatizados, headless e self-hosted que dependem da API como serviço de backend.
No meu caso, a Evolution API é utilizada em uma operação automatizada, sem interação direta do usuário. O serviço é provisionado e reiniciado por processos automatizados, como Docker, CI/CD ou infraestrutura como código.
Com a ativação obrigatória via Manager, a API pode ficar bloqueada até que alguém acesse manualmente a interface, faça login e realize a ativação da licença. Isso causa indisponibilidade e torna redeploys, atualizações e recuperações automáticas menos confiáveis.
O problema que esta solicitação busca resolver é permitir que instalações self-hosted e não interativas continuem funcionando de forma automatizada, mesmo com o novo sistema de licenciamento.
Seria importante existir uma forma oficial e documentada de ativação não interativa, ou um modo compatível com deploys automatizados, para que a API não dependa obrigatoriamente de uma ação manual no Manager antes de iniciar.
Exemplos de Uso
Contexto
Antes da v2.4.0, era possível subir a Evolution API em ambientes self-hosted de forma automatizada, sem depender de interação manual.
Com a mudança anunciada na v2.4.0, toda instalação precisa ser ativada e a API fica bloqueada enquanto a ativação não for realizada pelo Manager.
O fluxo atual parece ser:
- instalar ou atualizar a Evolution API;
- acessar
/manager;
- fazer login;
- ativar a licença manualmente;
- somente então a API fica disponível.
Esse fluxo não funciona bem para operações onde a API é implantada como componente de infraestrutura.
Exemplos de cenários afetados
1. Deploy via Docker Compose
Um servidor executa a Evolution API via Docker Compose. Após um update automático da imagem, o container sobe, mas a API não fica utilizável até que alguém acesse o Manager e ative manualmente a licença.
Isso quebra automações que esperam que a API esteja pronta após o container iniciar.
2. Deploy em Kubernetes
Em ambientes Kubernetes, pods podem ser recriados automaticamente por falha, atualização, escalonamento ou troca de nó.
Se cada instalação exigir ativação manual, o comportamento deixa de ser adequado para ambientes dinâmicos e automatizados.
3. Ambientes headless
Alguns servidores não possuem fluxo operacional com acesso manual à interface web. A Evolution API é usada apenas como backend, por integrações e sistemas internos.
Nesses casos, depender do Manager para ativação cria uma barreira operacional desnecessária.
4. CI/CD e infraestrutura como código
Em pipelines automatizados, espera-se que variáveis de ambiente, secrets ou comandos de inicialização sejam suficientes para provisionar o serviço.
A ativação manual impede que o deploy seja totalmente reprodutível.
Funcionalidade desejada
Gostaria que fosse implementada uma forma oficial de ativar ou configurar a licença sem depender exclusivamente do Manager.
Algumas possibilidades:
- ativação por variável de ambiente;
- ativação por arquivo de configuração;
- ativação por comando CLI;
- ativação por endpoint administrativo;
- ativação automática no startup quando uma chave válida estiver configurada;
- modo de compatibilidade para instalações self-hosted/comunidade;
- período de tolerância onde a API inicia com aviso, mas sem bloquear imediatamente.
Comportamento esperado
A API deveria conseguir iniciar e operar em ambientes automatizados sem exigir login manual no Manager.
Caso a licença seja obrigatória, deveria existir um fluxo documentado e suportado para ativação não interativa.
Comportamento atual
Após instalar ou atualizar para a v2.4.0, a API fica bloqueada até que a licença seja ativada manualmente pelo Manager.
Isso impede que o serviço funcione corretamente em operações automatizadas.
Como o recurso deve ser desenvolvido?
Acredito que o recurso deveria ser desenvolvido diretamente no código da API, pois está relacionado ao processo de inicialização, validação de licença e disponibilidade do serviço.
A solução ideal seria permitir que a licença fosse configurada por meio de variáveis de ambiente ou secrets, por exemplo:
LICENSE_KEY=xxxxx
LICENSE_AUTO_ACTIVATE=true
### Notas Adicionais
**Notas Adicionais**
```markdown
Gostaria também de pedir uma clarificação sobre o modelo de licenciamento atual.
A Evolution API era utilizada anteriormente como um projeto open source/self-hosted. Com a exigência de ativação obrigatória de licença na v2.4.0, não ficou claro se:
1. o projeto continua sendo open source no mesmo modelo anterior;
2. toda instalação self-hosted agora precisa obrigatoriamente de licença;
3. existe algum modo community/self-hosted sem bloqueio;
4. usuários existentes terão algum caminho de migração;
5. a ativação via Manager será sempre obrigatória ou haverá suporte para ambientes headless.
Esta solicitação não é contra a existência de licenciamento, mas sim sobre o impacto operacional causado pela exigência de ativação manual.
Para quem usa a Evolution API como backend em produção, a necessidade de interação humana no primeiro acesso quebra automações, aumenta risco de indisponibilidade e dificulta atualizações seguras.
Seria muito útil que a documentação da v2.4.0 deixasse explícito:
- quando a licença é obrigatória;
- como ativar em ambientes automatizados;
- o que acontece se a licença não for ativada;
- se há diferença entre uso comercial, community e self-hosted;
- qual é o fluxo recomendado para Docker, Kubernetes e CI/CD.
Obrigado pelo trabalho no projeto. A intenção desta issue é ajudar a tornar o novo sistema de licenciamento compatível com operações automatizadas e self-hosted.
Bem-vindo!
Qual tipo de recurso?
Outro
Qual a motivação para a solicitação?
A partir da versão v2.4.0, a Evolution API passou a exigir ativação de licença no primeiro acesso ao Manager em
/manager.Entendo a necessidade de um sistema de licenciamento, porém a forma atual exige uma etapa manual e interativa antes que a API possa operar normalmente. Isso quebra ambientes automatizados, headless e self-hosted que dependem da API como serviço de backend.
No meu caso, a Evolution API é utilizada em uma operação automatizada, sem interação direta do usuário. O serviço é provisionado e reiniciado por processos automatizados, como Docker, CI/CD ou infraestrutura como código.
Com a ativação obrigatória via Manager, a API pode ficar bloqueada até que alguém acesse manualmente a interface, faça login e realize a ativação da licença. Isso causa indisponibilidade e torna redeploys, atualizações e recuperações automáticas menos confiáveis.
O problema que esta solicitação busca resolver é permitir que instalações self-hosted e não interativas continuem funcionando de forma automatizada, mesmo com o novo sistema de licenciamento.
Seria importante existir uma forma oficial e documentada de ativação não interativa, ou um modo compatível com deploys automatizados, para que a API não dependa obrigatoriamente de uma ação manual no Manager antes de iniciar.
Exemplos de Uso
Contexto
Antes da v2.4.0, era possível subir a Evolution API em ambientes self-hosted de forma automatizada, sem depender de interação manual.
Com a mudança anunciada na v2.4.0, toda instalação precisa ser ativada e a API fica bloqueada enquanto a ativação não for realizada pelo Manager.
O fluxo atual parece ser:
/manager;Esse fluxo não funciona bem para operações onde a API é implantada como componente de infraestrutura.
Exemplos de cenários afetados
1. Deploy via Docker Compose
Um servidor executa a Evolution API via Docker Compose. Após um update automático da imagem, o container sobe, mas a API não fica utilizável até que alguém acesse o Manager e ative manualmente a licença.
Isso quebra automações que esperam que a API esteja pronta após o container iniciar.
2. Deploy em Kubernetes
Em ambientes Kubernetes, pods podem ser recriados automaticamente por falha, atualização, escalonamento ou troca de nó.
Se cada instalação exigir ativação manual, o comportamento deixa de ser adequado para ambientes dinâmicos e automatizados.
3. Ambientes headless
Alguns servidores não possuem fluxo operacional com acesso manual à interface web. A Evolution API é usada apenas como backend, por integrações e sistemas internos.
Nesses casos, depender do Manager para ativação cria uma barreira operacional desnecessária.
4. CI/CD e infraestrutura como código
Em pipelines automatizados, espera-se que variáveis de ambiente, secrets ou comandos de inicialização sejam suficientes para provisionar o serviço.
A ativação manual impede que o deploy seja totalmente reprodutível.
Funcionalidade desejada
Gostaria que fosse implementada uma forma oficial de ativar ou configurar a licença sem depender exclusivamente do Manager.
Algumas possibilidades:
Comportamento esperado
A API deveria conseguir iniciar e operar em ambientes automatizados sem exigir login manual no Manager.
Caso a licença seja obrigatória, deveria existir um fluxo documentado e suportado para ativação não interativa.
Comportamento atual
Após instalar ou atualizar para a v2.4.0, a API fica bloqueada até que a licença seja ativada manualmente pelo Manager.
Isso impede que o serviço funcione corretamente em operações automatizadas.
Como o recurso deve ser desenvolvido?
Acredito que o recurso deveria ser desenvolvido diretamente no código da API, pois está relacionado ao processo de inicialização, validação de licença e disponibilidade do serviço.
A solução ideal seria permitir que a licença fosse configurada por meio de variáveis de ambiente ou secrets, por exemplo: