Actualización — PentAGI

Actualiza una instalación a una nueva versión y qué cambiar al pasar de la 2.1.0 a la 2.2.0.

Una actualización reemplaza las imágenes de PentAGI y, cuando la versión las ha cambiado, los archivos de compose. Tu .env y los volúmenes de datos se mantienen, y las migraciones de base de datos se ejecutan cuando PentAGI inicia.

Antes de empezar

Lee las notas de la versión de cada versión posterior a la que ejecutas; desde la 2.1.0 incluyen notas de actualización.
Haz una copia de seguridad de la base de datos. Ni el instalador ni PentAGI lo hacen, y las migraciones no se pueden revertir sin perder datos. Con el PENTAGI_POSTGRES_USER y PENTAGI_POSTGRES_DB por defecto:
```
docker exec pgvector pg_dump -U postgres -Fc pentagidb > pentagi-backup.dump
```
Guarda también copias de .env y de los archivos de compose: el instalador reemplaza los archivos de compose sin hacer una copia de seguridad.
Finaliza los flows que ya no necesites. Un sandbox que sigue en ejecución se reutiliza tal como fue creado, con la configuración de la versión que lo creó.
Si vienes de la 2.1.0, realiza los cambios indicados en De 2.1.0 a 2.2.0 en .env y en los archivos que están junto a él antes de que comience la nueva versión. Con el inicio de sesión mediante Google o GitHub activado, vacía ahora OAUTH_GOOGLE_CLIENT_ID y OAUTH_GITHUB_CLIENT_ID; la sección explica por qué.

Docker Compose

Descarga los archivos de compose de la nueva versión junto a tu .env: docker-compose.yml y el archivo de cada pila opcional que ejecutes. El contenedor de PentAGI recibe solo las variables que lista su archivo de compose, por lo que las nuevas configuraciones en .env no tienen efecto detrás de un archivo anterior.
```
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
```
Extrae las imágenes y reinicia, con los mismos archivos -f con los que inicias la pila. Sin pull, up -d mantiene las imágenes que ya están en el host.
```
docker compose pull && docker compose up -d
```
Actualiza la imagen del sandbox en el host Docker que ejecuta los flows, algo que docker compose pull no hace. Los flows creados después la utilizarán.
```
docker pull vxcontrol/kali-linux
```

La etiqueta de imagen latest sigue a la rama principal. Para mantenerte en una versión concreta, establece PENTAGI_IMAGE=vxcontrol/pentagi:<version> en .env.

Instalador

Descarga el instalador de la nueva versión desde Inicio rápido y ejecútalo con tu .env. El instalador 2.1.0 no puede actualizarse a sí mismo.
Para reemplazar los archivos de compose, cambia una configuración para que aparezca Apply Changes en el menú, selecciónalo y responde y cuando el instalador liste los archivos desactualizados.
En el menú de mantenimiento, ejecuta Update PentAGI para extraer las nuevas imágenes, y Update Worker Image cuando se te ofrezca. Update PentAGI por sí solo mantiene los archivos de compose antiguos.

De 2.1.0 a 2.2.0

Archivos

El archivo de compose monta example.bedrock.provider.yml junto a él. El instalador lo crea; en una instalación manual créalo tú mismo, un archivo vacío es suficiente: touch example.bedrock.provider.yml.
Reemplaza docker-compose-langfuse.yml si ejecutas Langfuse: el archivo 2.1.0 nombra la imagen minio/minio, que ya no se publica, por lo que docker compose pull falla con ella. Si tu .env establece MINIO_IMAGE=minio/minio:…, elimina esa línea.
Para el knowledge graph, coloca examples/neo4j del repositorio en ./neo4j — Graphiti necesita su plugin APOC — y consulta Memoria y conocimiento para los presets de modelo. GRAPHITI_MODEL_NAME ya no se lee.
Ocho migraciones de base de datos se ejecutan en el primer inicio. docker compose logs pentagi muestra "Database schema updated successfully" cuando terminan.

Todos deben iniciar sesión de nuevo: las sesiones de 2.1.0 son rechazadas. Los tokens de API siguen funcionando, y los scripts cierran sesión con POST /api/v1/auth/logout.
Un token de API obtiene un 403 en las rutas REST /users, /roles y /tokens: gestiona cuentas, roles y tokens desde una sesión de navegador con sesión iniciada.
El inicio de sesión con Google y GitHub ahora registra un correo electrónico verificado por el provider en la cuenta existente con esa dirección, incluidas las cuentas locales, con el rol de esa cuenta. La versión 2.1.0 no puede cambiar el correo electrónico de una cuenta, por lo que si el inicio de sesión está activado, actualiza con OAUTH_GOOGLE_CLIENT_ID y OAUTH_GITHUB_CLIENT_ID vacíos, mueve [email protected] a una dirección que controles bajo Settings → Account, y luego vuelve a activar el inicio de sesión. El Reset Admin Password del instalador encuentra al administrador solo por [email protected].
Detrás de un proxy inverso, establece TRUSTED_PROXIES, o todos los usuarios compartirán la dirección del proxy y una ráfaga de intentos de inicio de sesión fallidos bloqueará a todos durante 15 minutos — consulta Exposición de red.

Sandboxes

Con DOCKER_INSIDE=true — la plantilla .env de 2.1.0 y el valor por defecto del instalador — la versión 2.1.0 montaba el socket Docker del host en cada sandbox. La versión 2.2.0 da a los agents Docker solo desde un daemon separado configurado en DOCKER_INSIDE_HOST; sin él no obtienen ninguno, y el registro dice sandbox DISABLED. Con DOCKER_INSIDE_HOST, deja DOCKER_SOCKET= vacío, o el /var/run/docker.sock de la plantilla seguirá montado. Consulta Worker node.
Finaliza los flows iniciados en 2.1.0: sus sandboxes mantienen el montaje antiguo del socket y las capacidades hasta que el flow finalice.
Deja TENANT_ID vacío: en una instalación existente, apunta a PentAGI hacia un esquema nuevo y vacío.

Modelos y prompts

El provider personalizado necesita LLM_SERVER_KEY: con una clave vacía está desactivado, así que para un servidor sin autenticación establece cualquier valor no vacío.
LLM_SERVER_LEGACY_REASONING se elimina. El provider personalizado envía reasoning_effort y convierte un presupuesto de reasoning.max_tokens en un nivel de esfuerzo; en los modelos Kimi K2, GLM anteriores a 5.2 y MiniMax M, un presupuesto ahora hace fallar la llamada, así que elimínalo de esos agents.
En los archivos de configuración del provider, una entrada de agent que deje max_tokens, temperature, top_p o n en blanco ahora obtiene los valores por defecto del tipo de provider en lugar de no enviar nada.
Los modelos por defecto integrados cambiaron para cada provider excepto Bedrock; los providers guardados en Settings → Providers mantienen sus modelos. Cinco configuraciones incluidas en la imagen cambiaron de modelos — openrouter, deepinfra, ollama-cloud, moonshot y deepseek. Si LLM_SERVER_CONFIG_PATH o OLLAMA_SERVER_CONFIG_PATH apunta a uno de ellos bajo /opt/pentagi/conf/, mantén el archivo 2.1.0 en el host y móntalo como la configuración personalizada o de Ollama en su lugar.
Con EMBEDDING_URL en un servidor distinto al de OpenAI, establece EMBEDDING_KEY: OPEN_AI_KEY ya no se envía allí.
Los agents buscan a través de una única tool web_search. Los prompts personalizados con {{.GoogleToolName}} y las otras variables por motor se ignoran, con una advertencia en el registro, hasta que usen {{.WebSearchToolName}}; basa de nuevo los prompts personalizados de searcher y pentester en los nuevos valores por defecto.

Otros cambios

En los dos minutos siguientes al inicio y luego cada tres horas, PentAGI informa de su versión y un resumen de la instalación a update.pentagi.com; Comprobación de actualizaciones lista lo que envía, y UPDATE_CHECK_INTERVAL=0 lo desactiva.
El profiler ya no escucha en el puerto 7777 a menos que PPROF_ADDR esté establecido.
Las nuevas configuraciones opcionales incluyen conmutación por error del provider con LLM_FALLBACK_PROVIDER, DOCKER_PORTS_BASE para varias instancias, DOCKER_IMAGE_SELECTION_MODE y DOCKER_ALLOWED_IMAGES, el search engine interno WEB_SEARCH_INTERNAL_ENABLED, y las claves de Mistral, xAI, MiniMax y Firecrawl.

Copia de seguridad y reversión

PentAGI nunca ejecuta migraciones hacia atrás, y ejecutarlas manualmente elimina datos, así que la forma de volver a 2.1.0 es la copia de seguridad. Detén los servicios que usan la base de datos, recréala y restaura el volcado:

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

Luego vuelve a colocar el .env y los archivos de compose guardados, establece PENTAGI_IMAGE=vxcontrol/pentagi:2.1.0 e inicia la pila. Mantén el nuevo docker-compose-langfuse.yml: la imagen MinIO del archivo de 2.1.0 ya no se puede extraer.