Conexão com EvoCrm e EvoGo somem após atualização

[gigantsc]

A cada atualização as integrações com EvoCrm e evogo somem do painel
A memória do Mempalace também tem que instalar toda vez novamente.

[DavidsonGomes]

Oi @gigantsc, obrigado pelo report. Investiguei o código e o caminho esperado de persistência — o .env já mora em /workspace/config/.env (volume nomeado evonexus_config) e é symlinked para /workspace/.env no boot do container (entrypoint.sh:103), então no fluxo Docker padrão as chaves deveriam sobreviver ao upgrade. Isso quer dizer que seu cenário não bate com a hipótese óbvia, e preciso de mais detalhes antes de propor fix:

1. Modo de instalação: Docker (docker-compose.hub.yml / Portainer / Swarm) ou instalação direta no host (git clone + make setup)?
2. Como você atualiza — npx @evoapi/evo-nexus@latest ., git pull, docker compose pull, ou outro fluxo?
3. Versão antes e depois do upgrade (visível no canto inferior do dashboard ou em package.json).
4. Após o upgrade:
   • As outras integrações (Stripe, Omie, Telegram etc) também somem, ou só EvoCrm e EvoGo?
   • O arquivo .env ainda existe e tem conteúdo? (no caso Docker, docker exec evonexus-dashboard cat /workspace/.env | grep -E 'EVO_CRM|EVOLUTION_GO')
   • As chaves estão no .env mas o painel não mostra, ou o .env está vazio/sem as chaves?
5. Mempalace: "tem que instalar toda vez" — você quer dizer que os modelos do Marker precisam baixar de novo (download), ou que os dados salvos no Mempalace (documentos, embeddings) somem? São fluxos diferentes.

Com essas respostas consigo decidir se é bug de volume, de migration, de encriptação de chave regenerada, ou algum outro caminho que ainda não mapeei. Se puder anexar também os logs do startup (docker logs evonexus-dashboard ou journalctl -u evo-nexus) entre duas iterações de upgrade, ajuda bastante.

[df4p]

Comigo o MemPalace tem o mesmo comportamento. Sempre que reinicio o container com um novo deploy, toca instalar de novo para habilitar a parte de configuração dele.

[DavidsonGomes]

Update após auditoria do código:

Sobre o Mempalace ter que reinstalar a cada deploy (@df4p confirmou): isso é determinístico. dashboard/backend/routes/mempalace.py:140 faz uv pip install mempalace direto no /workspace/.venv, e esse venv é reconstruído na build da imagem (Dockerfile.swarm.dashboard:71 → RUN uv venv .venv && uv sync --no-dev). Como /workspace/.venv não está em volume nomeado no docker-compose.hub.yml, cada docker compose pull traz imagem nova sem o pacote → "instalar de novo". Os dados do Mempalace (em /workspace/dashboard/data/mempalace) sobrevivem porque esse path está em evonexus_dashboard_data. Vou tratar isso em PR separado — opções: (a) pré-instalar mempalace no Dockerfile, (b) detectar e auto-reinstalar no startup, (c) montar o venv em volume (não recomendo — quebra com upgrades de Python).

Sobre EvoCRM/EvoGo sumirem do painel (@gigantsc): preciso de mais informação para distinguir entre dois cenários:

1. Você usa a imagem do Docker Hub (docker-compose.hub.yml apontando para evoapicloud/evo-nexus-dashboard:latest)? Nesse caso, o entrypoint que lê o /workspace/config/.env está correto — investigar se algo está recriando o .env ou se é problema de UI cache.
2. Você builda local com Dockerfile.dashboard? Esse Dockerfile não usa entrypoint.sh (CMD direto, sem ENTRYPOINT), então o .env nunca é sourceado para os.environ na inicialização. As integrações que dependem de env vars (EVO_CRM_TOKEN, EVOLUTION_GO_KEY) ficariam invisíveis para o backend depois de qualquer restart.

Pode rodar essas duas linhas e colar o output?

docker exec evonexus-dashboard sh -c 'cat /workspace/config/.env | grep -E "EVO_CRM|EVOLUTION_GO" | sed "s/=.*/=***SET***/"'
docker exec evonexus-dashboard sh -c 'env | grep -E "EVO_CRM|EVOLUTION_GO" | sed "s/=.*/=***SET***/"'

Se a primeira linha mostra as chaves mas a segunda não, é o cenário (2) — eu abro PR adicionando ENTRYPOINT no Dockerfile.dashboard. Se ambas mostram, é cache de UI / health cache stale e investigo separadamente.