# Atualização > Atualize uma instalação para uma nova versão e veja o que mudar ao migrar da 2.1.0 para a 2.2.0. Uma atualização substitui as imagens do PentAGI e, quando o release as alterou, os arquivos compose. Seus `.env` e os volumes de dados permanecem, e as migrações do banco de dados são executadas quando o PentAGI inicia. ## [Antes de começar](https://pentagi.com/pt-br/docs/deployment/upgrade/#before-you-start) * Leia as [notas de lançamento](https://pentagi.com/changelog/) de cada versão posterior à que você executa; desde a 2.1.0 elas incluem notas de atualização. * Faça backup do banco de dados. Nem o instalador nem o PentAGI fazem isso, e as migrações não podem ser revertidas sem perda de dados. Com o padrão `PENTAGI_POSTGRES_USER` e `PENTAGI_POSTGRES_DB`: ```bash docker exec pgvector pg_dump -U postgres -Fc pentagidb > pentagi-backup.dump ``` Mantenha cópias de `.env` e dos arquivos compose também: o instalador substitui os arquivos compose sem fazer backup. * Conclua os [flows](https://pentagi.com/pt-br/docs/glossary/#flow) que você não precisa mais. Um [sandbox](https://pentagi.com/pt-br/docs/glossary/#sandbox) que ainda está em execução é reutilizado exatamente como foi criado, com as configurações do release que o criou. * Vindo da 2.1.0, faça as alterações em [De 2.1.0 para 2.2.0](#from-210-to-220) no `.env` e nos arquivos ao lado dele antes que o novo release comece. Com o login do Google ou GitHub ativado, limpe `OAUTH_GOOGLE_CLIENT_ID` e `OAUTH_GITHUB_CLIENT_ID` agora; a seção explica o porquê. ## [Docker Compose](https://pentagi.com/pt-br/docs/deployment/upgrade/#docker-compose) 1. Baixe os arquivos compose do novo release ao lado do seu `.env`: `docker-compose.yml` e o arquivo de cada stack opcional que você executa. O container do PentAGI recebe apenas as variáveis listadas no seu arquivo compose, então novas configurações em `.env` não têm efeito por trás de um arquivo mais antigo. ```bash cd ~/pentagi curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose.yml # and the file of each optional stack you run, for example: curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose-langfuse.yml ``` 2. Baixe as imagens e reinicie, com os mesmos arquivos `-f` que você usa para iniciar a stack. Sem `pull`, `up -d` mantém as imagens já presentes no host. ```bash docker compose pull && docker compose up -d ``` 3. Atualize a imagem do sandbox no host Docker que executa os flows, o que `docker compose pull` não faz. Os flows criados posteriormente a utilizarão. ```bash docker pull vxcontrol/kali-linux ``` A tag de imagem `latest` segue a branch main. Para permanecer em um único release, defina `PENTAGI_IMAGE=vxcontrol/pentagi:` em `.env`. ## [Instalador](https://pentagi.com/pt-br/docs/deployment/upgrade/#installer) 1. Baixe o instalador do novo release em [Quick start](https://pentagi.com/pt-br/docs/getting-started/quickstart/) e execute-o com seu `.env`. O instalador 2.1.0 não pode atualizar a si mesmo. 2. Para substituir os arquivos compose, altere uma configuração para que **Apply Changes** apareça no menu, selecione-o e responda `y` quando o instalador listar os arquivos desatualizados. 3. No menu de manutenção, execute **Update PentAGI** para baixar as novas imagens e **Update Worker Image** quando for oferecido. **Update PentAGI** por si só mantém os arquivos compose antigos. ## [De 2.1.0 para 2.2.0](https://pentagi.com/pt-br/docs/deployment/upgrade/#from-210-to-220) ### [Arquivos](https://pentagi.com/pt-br/docs/deployment/upgrade/#files) * O arquivo compose monta `example.bedrock.provider.yml` ao lado dele. O instalador o cria; em uma instalação manual, crie-o você mesmo, um arquivo vazio é suficiente: `touch example.bedrock.provider.yml`. * Substitua `docker-compose-langfuse.yml` se você executar o Langfuse: o arquivo 2.1.0 nomeia a imagem `minio/minio`, que não é mais publicada, então `docker compose pull` falha com ele. Se seu `.env` define `MINIO_IMAGE=minio/minio:…`, remova essa linha. * Para o [knowledge graph](https://pentagi.com/pt-br/docs/glossary/#knowledge-graph), coloque `examples/neo4j` do repositório em `./neo4j` — o Graphiti precisa do seu plugin APOC — e veja [Memory and knowledge](https://pentagi.com/pt-br/docs/concepts/memory/#knowledge-graph-optional) para os presets de modelo. `GRAPHITI_MODEL_NAME` não é mais lido. * Oito migrações de banco de dados são executadas na primeira inicialização. `docker compose logs pentagi` mostra "Database schema updated successfully" quando elas terminam. ### [Login e acesso](https://pentagi.com/pt-br/docs/deployment/upgrade/#sign-in-and-access) * Todos devem fazer login novamente: sessões da versão 2.1.0 são recusadas. Os tokens de API continuam funcionando, e scripts fazem logout com `POST /api/v1/auth/logout`. * Um token de API recebe 403 nas rotas REST `/users`, `/roles` e `/tokens`: gerencie contas, funções e tokens a partir de uma sessão de navegador logada. * O login com Google e GitHub agora associa um e-mail verificado pelo [provider](https://pentagi.com/pt-br/docs/glossary/#provider) à conta existente com esse endereço, incluindo contas locais, com a função dessa conta. A versão 2.1.0 não pode alterar o e-mail de uma conta, portanto, se o login estiver ativado, atualize com `OAUTH_GOOGLE_CLIENT_ID` e `OAUTH_GITHUB_CLIENT_ID` vazios, mova `admin@pentagi.com` para um endereço sob seu controle em **Settings → Account** e, em seguida, reative o login. O **Reset Admin Password** do instalador encontra o administrador apenas por `admin@pentagi.com`. * Por trás de um proxy reverso, defina `TRUSTED_PROXIES`, ou todos os usuários compartilharão o endereço do proxy e uma rajada de tentativas de login com falha bloqueará todos por 15 minutos — veja [Network exposure](https://pentagi.com/pt-br/docs/configuration/security/#network-exposure). ### [Sandboxes](https://pentagi.com/pt-br/docs/deployment/upgrade/#sandboxes) * Com `DOCKER_INSIDE=true` — o template padrão `.env` da versão 2.1.0 e do instalador — a versão 2.1.0 montava o socket Docker do host em cada sandbox. A versão 2.2.0 fornece aos [agents](https://pentagi.com/pt-br/docs/glossary/#agent) Docker apenas a partir de um daemon separado definido em `DOCKER_INSIDE_HOST`; sem ele, eles não recebem nenhum acesso, e o log diz `sandbox DISABLED`. Com `DOCKER_INSIDE_HOST`, deixe `DOCKER_SOCKET=` vazio, ou o `/var/run/docker.sock` do template ainda será montado. Veja [Worker node](https://pentagi.com/pt-br/docs/deployment/worker-node/). * Conclua os flows iniciados na versão 2.1.0: seus sandboxes mantêm a montagem antiga do socket e as capacidades até que o flow seja concluído. * Deixe `TENANT_ID` vazio: em uma instalação existente, isso aponta o PentAGI para um esquema novo e vazio. ### [Modelos e prompts](https://pentagi.com/pt-br/docs/deployment/upgrade/#models-and-prompts) * O provider customizado precisa de `LLM_SERVER_KEY`: com uma chave vazia, ele é desativado, então para um servidor sem autenticação defina qualquer valor não vazio. * `LLM_SERVER_LEGACY_REASONING` foi removido. O provider customizado envia `reasoning_effort` e converte um orçamento de `reasoning.max_tokens` em um nível de esforço; nos modelos Kimi K2, GLM anterior a 5.2 e MiniMax M, um orçamento agora faz a chamada falhar, então remova-o desses agents. * Nos arquivos de configuração do provider, uma entrada de agent que deixa `max_tokens`, `temperature`, `top_p` ou `n` em branco agora obtém os padrões do tipo de provider em vez de não enviar nada. * Os modelos padrão integrados mudaram para cada provider, exceto Bedrock; os providers salvos em **Settings → Providers** mantêm seus modelos. Cinco configurações empacotadas na imagem tiveram modelos alterados — `openrouter`, `deepinfra`, `ollama-cloud`, `moonshot` e `deepseek`. Se `LLM_SERVER_CONFIG_PATH` ou `OLLAMA_SERVER_CONFIG_PATH` apontar para um deles em `/opt/pentagi/conf/`, mantenha o arquivo 2.1.0 no host e monte-o como a configuração customizada ou Ollama. * Com `EMBEDDING_URL` em um servidor diferente do OpenAI, defina `EMBEDDING_KEY`: `OPEN_AI_KEY` não é mais enviado para lá. * Os agents pesquisam através de uma única [tool](https://pentagi.com/pt-br/docs/glossary/#tool) `web_search`. Prompts customizados com `{{.GoogleToolName}}` e as outras variáveis por engine são ignorados, com um aviso no log, até que usem `{{.WebSearchToolName}}`; refaça os prompts customizados de searcher e pentester com base nos novos padrões. ### [Outras alterações](https://pentagi.com/pt-br/docs/deployment/upgrade/#other-changes) * Dentro de dois minutos após o início e depois a cada três horas, o PentAGI relata sua versão e um resumo da instalação para `update.pentagi.com`; [Update check](https://pentagi.com/pt-br/docs/configuration/security/#update-check) lista o que é enviado, e `UPDATE_CHECK_INTERVAL=0` desativa isso. * O profiler não escuta mais na porta 7777, a menos que `PPROF_ADDR` esteja definido. * Novas configurações opcionais incluem [provider failover](https://pentagi.com/pt-br/docs/configuration/llm-providers/#failover) com `LLM_FALLBACK_PROVIDER`, `DOCKER_PORTS_BASE` para [várias instâncias](https://pentagi.com/pt-br/docs/deployment/production/#several-instances-tenant_id), `DOCKER_IMAGE_SELECTION_MODE` e `DOCKER_ALLOWED_IMAGES`, o [search engine](https://pentagi.com/pt-br/docs/glossary/#search-engine) interno `WEB_SEARCH_INTERNAL_ENABLED` e as chaves Mistral, xAI, MiniMax e Firecrawl. ## [Backup e reversão](https://pentagi.com/pt-br/docs/deployment/upgrade/#back-up-and-roll-back) O PentAGI nunca reverte migrações, e executá-las manualmente exclui dados, então o caminho de volta para a versão 2.1.0 é o backup. Pare os serviços que usam o banco de dados, recrie-o e restaure o dump: ```bash docker compose stop pentagi pgexporter docker exec pgvector dropdb -U postgres pentagidb docker exec pgvector createdb -U postgres pentagidb docker exec -i pgvector pg_restore -U postgres -d pentagidb < pentagi-backup.dump ``` Em seguida, restaure o `.env` e os arquivos compose salvos, defina `PENTAGI_IMAGE=vxcontrol/pentagi:2.1.0` e inicie a stack. Mantenha o novo `docker-compose-langfuse.yml`: a imagem MinIO do arquivo da versão 2.1.0 não pode mais ser baixada.