Pular para o conteúdo
PentAGI
Implantação

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

  • Leia as notas de lançamento 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:

    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 que você não precisa mais. Um 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 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

  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.

    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.

    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.

    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:<version> em .env.

Instalador

  1. Baixe o instalador do novo release em Quick start 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

Arquivos

  • 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, coloque examples/neo4j do repositório em ./neo4j — o Graphiti precisa do seu plugin APOC — e veja Memory and knowledge 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

  • 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 à 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 [email protected] 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 [email protected].
  • 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.

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 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.
  • 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

  • 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 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

  • 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 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 com LLM_FALLBACK_PROVIDER, DOCKER_PORTS_BASE para várias instâncias, DOCKER_IMAGE_SELECTION_MODE e DOCKER_ALLOWED_IMAGES, o search engine interno WEB_SEARCH_INTERNAL_ENABLED e as chaves Mistral, xAI, MiniMax e Firecrawl.

Backup e reversão

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:

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.

Última atualização em