アップグレード

インストールを新しいリリースに更新し、2.1.0 から 2.2.0 へ移行する際の変更点について説明します。

アップデートにより、PentAGI のイメージが置き換えられ、リリースで変更された場合は compose ファイルも置き換えられます。.env とデータボリュームは維持され、PentAGI の起動時にデータベースのマイグレーションが実行されます。

開始前に

現在実行しているバージョンより後の各バージョンのリリースノートをお読みください。2.1.0以降、アップグレードに関する注意事項が含まれています。
データベースをバックアップしてください。インストーラーも PentAGI もこれを行わず、データを失うことなくマイグレーションをロールバックすることはできません。デフォルトの PENTAGI_POSTGRES_USER および PENTAGI_POSTGRES_DB を使用する場合：
```
docker exec pgvector pg_dump -U postgres -Fc pentagidb > pentagi-backup.dump
```
.env と compose ファイルのコピーも保持してください。インストーラーはバックアップなしで compose ファイルを置き換えます。
不要になった flow を完了させてください。実行中の sandbox は、作成時のリリースの設定のまま再利用されます。
2.1.0 からアップグレードする場合は、新しいリリースが開始される前に、2.1.0 から 2.2.0 への変更を .env およびその隣接ファイルに適用してください。Google または GitHub サインインが有効になっている場合、今すぐ OAUTH_GOOGLE_CLIENT_ID と OAUTH_GITHUB_CLIENT_ID を空にしてください。その理由については、当該セクションで説明しています。

Docker Compose

新しいリリースの compose ファイルを .env の隣にダウンロードします：docker-compose.yml および実行している各オプションスタックのファイルです。PentAGI コンテナは compose ファイルに記載されている変数のみを受け取るため、古いファイルを使用していると .env の新しい設定は反映されません。
```
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
```
スタックの起動に使用する同じ -f ファイルを使用して、イメージをプルし再起動します。pull がない場合、up -d はホスト上に既に存在するイメージを維持します。
```
docker compose pull && docker compose up -d
```
flow を実行する Docker ホスト上の sandbox イメージを更新します。これは docker compose pull では行われません。以降に作成される flow はこのイメージを使用します。
```
docker pull vxcontrol/kali-linux
```

latest イメージタグは main ブランチを追従します。特定のリリースに留まる場合は、.env で PENTAGI_IMAGE=vxcontrol/pentagi:<version> を設定してください。

インストーラー

Quick start から新しいリリースのインストーラーをダウンロードし、.env を使用して実行します。2.1.0 のインストーラーは自身を更新できません。
compose ファイルを置き換えるには、メニューに Apply Changes が表示されるように設定を変更し、それを選択して、インストーラーが期限切れのファイルをリストした際に y と回答します。
メンテナンスメニューで、Update PentAGI を実行して新しいイメージをプルし、提供された場合は Update Worker Image を実行します。Update PentAGI 単独では古い compose ファイルが維持されます。

2.1.0 から 2.2.0 へ

ファイル

compose ファイルは、その隣にある example.bedrock.provider.yml をマウントします。インストーラーはこれを作成しますが、手動インストールの場合は自分で作成してください（空のファイルで十分です）：touch example.bedrock.provider.yml。
Langfuse を実行している場合は docker-compose-langfuse.yml を置き換えてください。2.1.0 のファイルは minio/minio イメージを指定していますが、これは公開されていないため、docker compose pull は失敗します。.env で MINIO_IMAGE=minio/minio:… を設定している場合は、その行を削除してください。
knowledge graph のために、リポジトリから ./neo4j に examples/neo4j を配置してください（Graphiti はその APOC プラグインを必要とします）。モデルプリセットについては Memory and knowledge を参照してください。GRAPHITI_MODEL_NAME は読み込まれなくなりました。
初回起動時に 8 つのデータベースマイグレーションが実行されます。完了すると docker compose logs pentagi に "Database schema updated successfully" と表示されます。

全員が再度サインインする必要があります。2.1.0 のセッションは拒否されます。API トークンは引き続き機能し、スクリプトは POST /api/v1/auth/logout でログアウトします。
API トークンは REST の /users、/roles、および /tokens ルートで 403 エラーになります。アカウント、ロール、トークンの管理は、サインイン済みのブラウザセッションから行ってください。
Google および GitHub によるサインインでは、プロバイダーによって検証されたメールアドレスが、そのアドレスを持つ既存のアカウント（ローカルアカウントを含む）に、そのアカウントのロールでサインインします。2.1.0 はアカウントのメールアドレスを変更できないため、サインインが有効な場合は、OAUTH_GOOGLE_CLIENT_ID と OAUTH_GITHUB_CLIENT_ID を空にしてアップグレードし、Settings → Account で [email protected] を管理下のアドレスに変更してから、サインインを再度有効にしてください。インストーラーの Reset Admin Password は [email protected] によってのみ管理者を検索します。
リバースプロキシの背後では、TRUSTED_PROXIES を設定してください。設定しないと、すべてのユーザーがプロキシのアドレスを共有することになり、サインイン失敗のバーストが発生すると全員が 15 分間ロックアウトされます。詳細は Network exposure を参照してください。

Sandboxes

DOCKER_INSIDE=true（2.1.0 の .env テンプレートおよびインストーラーのデフォルト）の場合、2.1.0 はホストの Docker ソケットをすべての sandbox にマウントしていました。2.2.0 では、agent は DOCKER_INSIDE_HOST で設定された別のデーモンセットからのみ Docker にアクセスできます。これが設定されていない場合、agent は Docker にアクセスできず、ログには sandbox DISABLED と表示されます。DOCKER_INSIDE_HOST を使用している場合は、DOCKER_SOCKET= を空にしてください。そうしないと、テンプレートの /var/run/docker.sock が依然としてマウントされます。詳細は Worker node を参照してください。
2.1.0 で開始された flow を完了させてください。これらの sandbox は、flow が完了するまで古いソケットマウントと機能を引き続き保持します。
TENANT_ID を空のままにしてください。既存のインストールでは、これは PentAGI を新しい空のスキーマに向けます。

モデルとプロンプト

カスタムプロバイダーには LLM_SERVER_KEY が必要です。キーが空だと無効になるため、認証のないサーバーの場合は任意の空でない値を設定してください。
LLM_SERVER_LEGACY_REASONING は削除されました。カスタムプロバイダーは reasoning_effort を送信し、reasoning.max_tokens バジェットを努力レベルに変換します。Kimi K2、GLM 5.2 以前、および MiniMax M モデルでは、バジェットがあるとコールが失敗するため、これらの agent から削除してください。
プロバイダー設定ファイルにおいて、max_tokens、temperature、top_p、または n を空白のままにした agent エントリは、何も送信しない代わりに、プロバイダータイプのデフォルト値を取得します。
Bedrock を除くすべてのプロバイダーで、組み込みのデフォルトモデルが変更されました。Settings → Providers に保存されたプロバイダーはモデルを維持します。イメージにバンドルされた 5 つの設定ファイルでモデルが変更されました — openrouter、deepinfra、ollama-cloud、moonshot、および deepseek。LLM_SERVER_CONFIG_PATH または OLLAMA_SERVER_CONFIG_PATH が /opt/pentagi/conf/ の下でこれらのいずれかを指している場合は、ホスト上に 2.1.0 のファイルを保持し、それをカスタムまたは Ollama 設定としてマウントしてください。
OpenAI 以外のサーバーで EMBEDDING_URL を使用する場合は、EMBEDDING_KEY を設定してください。OPEN_AI_KEY はそこには送信されなくなりました。
agent は 1 つの web_search tool を介して検索を行います。{{.GoogleToolName}} および他のエンジンごとの変数を使用したカスタムプロンプトは、{{.WebSearchToolName}} を使用するまで警告とともにログに表示され、無視されます。カスタムの searcher および pentester プロンプトを新しいデフォルトに基づいて再ベースしてください。

その他の変更

開始後2分以内、その後3時間ごとに、PentAGI はバージョンとインストールの概要を update.pentagi.com に報告します。Update check には送信内容が一覧表示され、UPDATE_CHECK_INTERVAL=0 でこれをオフにできます。
PPROF_ADDR が設定されていない限り、プロファイラーはポート 7777 でリッスンしません。
新しいオプション設定には、LLM_FALLBACK_PROVIDER を使用した provider failover、several instances 用の DOCKER_PORTS_BASE、DOCKER_IMAGE_SELECTION_MODE、DOCKER_ALLOWED_IMAGES、内部 search engine WEB_SEARCH_INTERNAL_ENABLED、および Mistral、xAI、MiniMax、Firecrawl のキーが含まれます。

バックアップとロールバック

PentAGI はマイグレーションを逆方向に実行せず、手動で実行するとデータが削除されるため、2.1.0 に戻る方法はバックアップを使用することです。データベースを使用しているサービスを停止し、データベースを再作成してダンプを復元してください。

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

その後、保存しておいた .env と compose ファイルを戻し、PENTAGI_IMAGE=vxcontrol/pentagi:2.1.0 を設定してスタックを起動してください。新しい docker-compose-langfuse.yml はそのまま維持してください。2.1.0 のファイルに含まれる MinIO イメージはもうプルできません。