# Actualización

> 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](https://pentagi.com/es/docs/deployment/upgrade/#before-you-start)

* Lee las [notas de la versión](https://pentagi.com/changelog/) 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:

  ```bash
  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](https://pentagi.com/es/docs/glossary/#flow) que ya no necesites. Un [sandbox](https://pentagi.com/es/docs/glossary/#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](#from-210-to-220) 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](https://pentagi.com/es/docs/deployment/upgrade/#docker-compose)

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

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

   ```bash
   docker compose pull && docker compose up -d
   ```

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

   ```bash
   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](https://pentagi.com/es/docs/deployment/upgrade/#installer)

1. Descarga el instalador de la nueva versión desde [Inicio rápido](https://pentagi.com/es/docs/getting-started/quickstart/) y ejecútalo con tu `.env`. El instalador 2.1.0 no puede actualizarse a sí mismo.
2. 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.
3. 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](https://pentagi.com/es/docs/deployment/upgrade/#from-210-to-220)

### [Archivos](https://pentagi.com/es/docs/deployment/upgrade/#files)

* 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](https://pentagi.com/es/docs/glossary/#knowledge-graph), coloca `examples/neo4j` del repositorio en `./neo4j` — Graphiti necesita su plugin APOC — y consulta [Memoria y conocimiento](https://pentagi.com/es/docs/concepts/memory/#knowledge-graph-optional) 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.

### [Inicio de sesión y acceso](https://pentagi.com/es/docs/deployment/upgrade/#sign-in-and-access)

* 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](https://pentagi.com/es/docs/glossary/#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 `admin@pentagi.com` 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 `admin@pentagi.com`.
* 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](https://pentagi.com/es/docs/configuration/security/#network-exposure).

### [Sandboxes](https://pentagi.com/es/docs/deployment/upgrade/#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](https://pentagi.com/es/docs/glossary/#agent) 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](https://pentagi.com/es/docs/deployment/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](https://pentagi.com/es/docs/deployment/upgrade/#models-and-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](https://pentagi.com/es/docs/glossary/#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](https://pentagi.com/es/docs/deployment/upgrade/#other-changes)

* 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](https://pentagi.com/es/docs/configuration/security/#update-check) 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](https://pentagi.com/es/docs/configuration/llm-providers/#failover) con `LLM_FALLBACK_PROVIDER`, `DOCKER_PORTS_BASE` para [varias instancias](https://pentagi.com/es/docs/deployment/production/#several-instances-tenant_id), `DOCKER_IMAGE_SELECTION_MODE` y `DOCKER_ALLOWED_IMAGES`, el [search engine](https://pentagi.com/es/docs/glossary/#search-engine) interno `WEB_SEARCH_INTERNAL_ENABLED`, y las claves de Mistral, xAI, MiniMax y Firecrawl.

## [Copia de seguridad y reversión](https://pentagi.com/es/docs/deployment/upgrade/#back-up-and-roll-back)

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:

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

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.