Ativação obrigatória de licença na v2.4.0 quebra deployments automatizados e self-hosted

[joaosouz4dev]

Bem-vindo!

• Sim, pesquisei solicitações semelhantes no GitHub e não encontrei nenhum.

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:

1. instalar ou atualizar a Evolution API;
2. acessar /manager;
3. fazer login;
4. ativar a licença manualmente;
5. 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.