Esta versão mexe em como o sistema chega e se atualiza no seu servidor. Em uso, três coisas mudam para melhor: a instalação deixa de ter uma etapa que podia falhar por falta de memória no meio (o servidor não compila mais nada — tudo vem pronto), fica bem mais rápida, e o agente de IA passa a receber as correções de cada versão. A recomendação de servidor continua exatamente a mesma: o que consome memória é operar o sistema no dia a dia — 7 serviços e cerca de 150 MB por número de WhatsApp conectado —, e isso não mudou nem um pouco.
Action required1
This release asks you to do something before or after updating. Read this block first.
Se o seu servidor foi instalado antes desta versão, rode o update.sh DUAS vezes.
As duas execuções são necessárias nesta versão. O agente que corrige isso sozinho entrou depois da 1.3.0 (está em Não lançado) — se você está atualizando para a 1.3.0, ele não existe no que você vai instalar. Esta nota já disse o contrário, e a frase teria feito você esperar cinco minutos por algo que nunca ia acontecer.
Medido em ensaio numa VPS: a primeira execução traz o agente novo, mas deixa a versão dele "solta" — acompanhando o canal em vez de ficar fixa, como o resto do sistema. Isso faria o agente saltar sozinho para a versão seguinte num reinício futuro, enquanto o resto do servidor continuaria onde está. A segunda execução fixa tudo na mesma versão.
Para saber em que pé você está, sem mexer em nada:
curl -fsSL https://raw.githubusercontent.com/melgarafael/DeskcommCRM/main/hostgator-setup-kit/diagnostico.sh | bashEle só lê e explica — não escreve, não reinicia, não atualiza. Se disser que está afetada, o passo a passo (com como voltar atrás) está em docs/runbooks/remediar-worker-congelado.md.
Fora isso, nada exige ação sua. Um .env antigo continua funcionando: as configurações novas têm valor padrão e o próprio update.sh as acrescenta.
Fixed6
O agente de IA nunca recebia atualização
O worker — o processo que faz o agente atender 24 horas por dia — era compilado dentro do seu servidor no dia da instalação, e nenhuma atualização o reconstruía. Na prática: você atualizava o CRM, o site mudava, e o agente continuava rodando exatamente o código do dia em que você instalou, para sempre. Correções e melhorias do agente não chegavam. Agora ele é uma imagem pronta, publicada junto com o resto, e o update.sh a traz como traz o app.
Duas instalações "na mesma versão" rodavam código diferente
Uma instalação nova ficava apontada para o canal latest, que — apesar do nome — acompanha o desenvolvimento em andamento, não a última versão lançada. Quem instalou em semanas diferentes tinha software diferente, e não havia como dizer qual. Agora o instalador grava o número da versão (ex.: 1.2.1), e é essa versão que fica no seu servidor até você decidir atualizar.
O CRM podia não subir por causa de um serviço externo fora do ar
A configuração pedia ao Docker que verificasse o registro de imagens a cada subida; se ele não respondesse, o contêiner não subia — mesmo com a imagem já baixada no seu disco. Agora que o seu servidor fica numa versão fixa, essa verificação deixa de ser feita na sua instalação (quem acompanha um canal móvel continua com ela, que é onde ela serve para alguma coisa).
O agendador de tarefas dependia da internet para voltar
A cada reinício ele baixava dois programas antes de começar. Sem internet no momento do reboot — justo quando a máquina está se recuperando de alguma coisa —, as tarefas automáticas não voltavam. Agora já vêm dentro da imagem.