Impreza Host

impreza-mcp

Impreza Host 用の Model Context Protocol サーバーです。AI コーディングツール（Claude Code、Cursor、Codex CLI、Continue、Zed など）からチャットを離れずに、顧客が構築したアプリを Impreza のマネージド VPS にデプロイできます。

この MCP サーバーを読み込んだ状態で Claude に「これをデプロイして」と伝えると、Claude は impreza_deploy_custom を直接呼び出します。プロジェクトをパッケージ化してアップロードし、Impreza VPS 上でビルドして実行し、URL を返します。

ローカル CLI をペアリングする

clientarea の Impreza API → Connect an AI assistant で、アシスタントに必要な権限を選択して一度限りのコードを生成します。ローカル MCP サーバーを実行するマシンで npx -y impreza-mcp login --code <code-from-clientarea> を実行します。コードの有効期限は 10 分で、1 回だけ使用できます。

CLI は既存の API 認証情報を送信せずに、POST /v1/mcp/pair でコードを交換します。返されたキー、シークレット、スコープ、有効期限は ~/.impreza/credentials.json に保存されます。コードとシークレットが表示されることはありません。POSIX では、ディレクトリのモードは 0700、ファイルのモードは 0600 です。Windows では、アカウントのみがアクセスできる保護された ACL を使用します。どちらの認証情報環境変数も設定されていない場合、サーバーはこのファイルを自動的に読み込みます。IMPREZA_API_KEY と IMPREZA_API_SECRET が両方とも明示的に設定されている場合は、保存済みの認証情報より優先されます。環境変数の認証情報が片方だけ設定されている場合、保存済みのもう片方は使用されません。

別の API エンドポイントを使用する場合は、ペアリング前に IMPREZA_BASE_URL を設定します。HTTPS が必須です。v3 onion エンドポイントでは明示的な SOCKS5 プロキシを指定した IMPREZA_PROXY が必要で、直接接続へのフォールバックは行われません。エンドポイントとプロキシは認証情報とともに保存されます。API URL が異なる場合、保存済みの認証情報は使用されません。ペアリングではリダイレクトを追跡せず、コードの自動再試行も行いません。

既存の認証情報ファイルが上書きされることはありません。再度ペアリングする前に、clientarea で古いペアリング済みキーを失効させ、そのファイルを削除してください。交換またはディスクへの書き込みに失敗した場合、コードがすでに使用済みになっている可能性があります。clientarea で新しいキーを確認して失効させてから、別のコードを生成してください。ペアリング後に AI クライアントを再起動します。

すでに所有しているサーバーを追加する（0.53.0）

• impreza_add_server は、顧客がすでに所有しているサーバー（root アクセスと送信 HTTPS が利用可能な、任意のプロバイダー上の Linux マシン）を接続し、有効期限が 10 分の一度限りのトークンを含む、1 行のインストールコマンドを返します。すべてのアカウントで最初の外部サーバーは無料で、プランも残高も必要ありません。Impreza VPS が 1 台でも有効になると、アカウントは Bundled（外部サーバー 5 台）に移行します。トークンは 1 回だけ表示され、保存されるのはそのハッシュのみです。紛失または期限切れになった場合は、このツールを再度呼び出してください。未使用のトークンは期限切れになるまで無料枠を占有し、新しいサーバーの追加数には 1 日あたりの上限があります。label は省略可能なプレーンテキストで、最大 120 文字です。API と同じく、Unicode コードポイント数で数えます。マネージド Impreza VPS には impreza_install_agent を使用してください。deploy スコープが必要です。
• start-from-nothing スキルは、顧客がすでにサーバーを所有しているかを最初に確認し、ホスト型コネクターの匿名ロビーについて説明します。ここでは、アカウント作成と公開情報の読み取り（ドキュメント検索、VPS のオファーと見積もり、製品、アプリ、マニフェストの確認、ドメインの利用可能状況と料金）を行えます。
• ツールのタイトルと説明は、現在の API ガイダンスに沿っています。シークレット値はアカウント所有者がポータルで入力し、VPS の注文にはエージェントをリクエストしない限り追加されません。また、保持されるアーカイブと監視対象の Git 参照は、API の適用方法に沿って説明されます。

HTTP 以外のポートへのインバウンドアクセス（0.52.0）

• impreza_get_ingress は、アプリケーションが公開する HTTP 以外の各ポート（データベース、ゲームサーバー、RustDesk など）にアクセスできるアドレス範囲を読み取ります。すべてのデプロイメントは、最初は開放されています。応答にはリビジョン、ステータス（open、pending、enforced、理由を伴う not_enforced、または最小エージェントバージョンを伴う agent_update_required）と、ポートごとの開放または制限の状態およびその接続元が含まれます。読み取りスコープが必要です。
• impreza_set_ingress は、許可リストを希望する完全な状態に置き換えます。rules には制限するポートのみを指定し、各ポートに IPv4 または IPv6 の CIDR 接続元を設定します。rules=[] にすると、すべてのポートが再び開放されます。制限を設定すると自分のアクセスがブロックされる可能性があるため、confirm: true が必要です。開放する場合は不要です。読み取った base_revision を渡してください。古いリビジョンは REVISION_CONFLICT で拒否されます。エージェントは約 1 分以内に設定を適用します。制限を適用できない場合、ポートは開放されたままとなり、ステータスには理由を伴う not_enforced が表示され、アプリでアラートが発生します。管理スコープが必要です。
• HTTP と HTTPS は対象外です。これらはプロキシと Shield を経由します。適用にはエージェント 0.6.26 以降が必要です。

正確なチャージ額と API パス内の ID の検証（0.51.0）

• 正確なチャージ額。 impreza_topup は金額を正確な小数文字列（例："25.50"）として受け取り、2 進浮動小数点数への変換を行わず、そのまま API に送信します。JSON の数値も引き続き受け付けます。指数表記、符号、空白、または小数点以下 3 桁以上を含む文字列は拒否されます。
• API パスに含めるすべての ID を検証します。 0.50.0 で導入した deployment_id の保護を、パッケージが API URL パスに含めるすべての識別子に拡張しました。対象には、task、backup、VPS、image、invoice、command、read、run の ID、agent ID、onion クライアント名、ドメインでルーティングするツール内のドメイン、逆引き DNS 用の専用 IP が含まれます。パスのセグメントを追加または変更する値（.、..、/、\、%、空白文字、制御文字）は、リクエストがプロセスから送信される前に拒否されます。有効な ID はこれまでどおり送信されます。

アプリの保護、より安全なデプロイ ID、ベア VPS の注文（0.50.0）

• ガイド付きプロンプトによるアプリの保護。 prompts/list に impreza_protect_app が追加されました。実行中のアプリを起点に、お客様が所有する別の国のサーバーにコールドスタンバイを構築する手順をアシスタントに案内します。人間と対象を選び、スタンバイを作成し（impreza_deploy_catalog_app に standby: true を指定）、ペアを組んで最初の復元訓練を実施します。各手順には個別の明示的な人間の確認が必要です。検証済みの訓練後、測定したコピーの経過時間と訓練の所要時間を報告します。これらは測定値であり、RPO や RTO を保証するものではありません。サーバーの購入、スタンバイへの昇格、トラフィックの切り替え、DNS の変更は行いません。また、レビュー済みのフェイルオーバー対応アプリ（Memos 0.31.0 と Uptime Kuma 2.5.5）が対象です。ほかのすべてのプロンプトと同様、権限を付与するものではありません。
• サーバーのロケーション： impreza_list_servers は、構造化出力で各サーバーの failover_location を返します。含まれるのは country_code、country_basis（verified、operator_verified、または declared。外部サーバーについてお客様が申告した国は、Impreza による検証済みではありません）、および country_notice です。
• デプロイ ID にパスセグメントを追加できません。 API URL のパスセグメントを追加または変更する deployment_id（.、..、/、\、%、空白文字、制御文字を含むもの）は、リクエストがプロセスから送信される前に拒否されます。有効な ID は従来どおり、そのまま送信されます。
• API 経由で注文した VPS は、デフォルトで何もインストールされていない状態です。 impreza_order_vps と impreza_vps_offer は、API の動作を説明するようになりました。app を指定しない場合、VPS は app: "none"（ベア OS、エージェントなし）で起動します。デプロイ可能な状態を希望する場合は、明示的に app: "@agent" を指定するか、お客様の確認を得たうえで後から impreza_install_agent を提案してください。注文後は impreza_list_services をポーリングしてください。impreza_list_servers に表示されるのは、エージェントがインストール済みのサーバーだけです。
• 直接依存関係を正確に固定。 パッケージの直接的な実行時依存関係は、テストに使用した正確なバージョンに固定されています（依存関係のバージョンを参照）。

エージェントのインストール、チャット外でのシークレット入力、カスタムアプリの保護（0.49.0）

• impreza_install_agent は、まだエージェントがインストールされていない管理対象 VPS に対し、お客様の明示的な同意がある場合に限って Impreza エージェントを提供します。最初の呼び出しでは何もインストールせず、有効期間の短い confirm_token を返します。同じ引数にそのトークンを加えて2回目に呼び出すと、インストールが開始されます。impreza_get_agent_install は、VPS がインストールに対応しているかどうかを示し、エージェントがオンラインになるまでインストールを追跡します。
• シークレットがチャットを経由することはありません。 impreza_prepare_secret_entry は、既存アプリまたは変数グループのシークレット変数用に、10分間有効で一度だけ使用できるポータルリンクを返します。アカウント所有者がリンクを開いてサインインし、そこで値を入力します。impreza_get_secret_entry が報告するのは pending、stored、expired、cancelled のいずれかだけで、値やそのハッシュは決して返しません。ツールは引数でのシークレット値（パスワード、Git トークン、onion の秘密鍵、ビルドシークレット）を拒否し、代わりにポータルを案内するようになりました。REST API に変更はありません。
• カスタムプロジェクトの管轄区域間フェイルオーバー： impreza_deploy_custom では standby: true を指定して、別のサーバーにコールドスタンバイを作成できます。ソースは同じものに固定されます（イメージダイジェスト、正確な Git コミット、または凍結済みの Compose アップロード）。プロジェクトでは、すべての永続ボリュームを宣言する必要があります。また、カスタムのペアは検証済みの訓練後にのみ切り替わります。

デプロイの進行状況とエージェントの再起動

Compose のレビューとデプロイでは、ローカルのビルドコンテキストとランタイムの env_file、configs、または secrets を含む、保持された 1 つのアップロードに対する context_id を受け付けます。レビューとデプロイの両方で、同じコンテキストを指定する必要があります。ランタイムファイルには、compose-source-files-v1 を備えたエージェント 0.6.11 以降が必要です。

カスタム Node サーバー／静的デプロイでは、プロジェクトの正確な packageManager およびコミット済みロックファイルと一致する [email protected] や [email protected] などの node_package_manager を受け付けます。npm の場合は省略してください。対応バージョンは、単独で使用する pnpm 10～12 と Yarn 4 のプロジェクトです。このフィールドを npm_workspace と組み合わせて使用することはできません。検査時にバージョン指定が推定され、保存済みプランにも保持されます。対応する入力と制限については、デプロイのドキュメントを参照してください。

impreza_list_deployments の last_operation.progress を読み取り、最後に報告されたステップとタイムスタンプを確認してください。エージェント 0.6.6 以降は結果を送信する前に最終結果を保存するため、再起動後はデプロイを繰り返さず、同じレシートを再送します。 エージェント 0.6.7 以降では、完了した準備チェックポイントを検証し、デプロイを再実行せずに以前の構成を復元できます（recovery=reconciling）。再試行する前に、最終的な失敗またはキャンセルの確認を待ってください。 recovery=required は、自動照合を検証できなかったことを意味します。サポートにお問い合わせください。ビルドの実行中、チェックポイントの欠落、置き換えに関する不確実性がある場合は、処理がブロックされたままになります。エージェントの終了後も、長時間実行中のビルドが継続することがあります。進行状況はリアルタイムの進捗率ではなく、現在のランタイムの正常性を示す証拠でもありません。既存のエージェントは、次のデプロイの前に明示的に更新してください。デプロイの進行状況を参照してください。

デプロイをキャンセルする

デプロイ ID と正確な last_operation.command_id を指定して、 impreza_cancel_deployment を使用してください。管理権限が必要です。キューに入ったデプロイはすぐにキャンセルされます。実行中の準備処理にはエージェント 0.6.5 以降が必要です。エージェント 0.6.12 以降では、サーバー管理者が対応する Ubuntu 24.04 amd64 ホストで制御ビルドを有効にしている場合、所有するビルドを中断できます。その他の準備処理は、現在のステップが完了するまで待機します。キャンセルの確認には、クリーンアップの検証と構成の復元が引き続き必要です。requested は cancelled を意味しません。置き換え／復旧はキャンセルできません。追跡中の Task のキャンセルは別途行います。 キャンセルガイドを参照してください。

ランタイムの正常性とデプロイ操作

impreza_list_deployments は、runtime と last_operation を別々に返します。 ビルドに失敗しても、以前のアプリケーションが正常な状態で残ることがあります。ランタイムの状態、観測時刻、理由を確認してください。古い測定値や欠落した測定値は、引き続き不明として扱われます。ヘルスチェックで確認されていない実行状態は正常ではありません。観測にはエージェント 0.6.4 以降が必要です。外部の HTTP／DNS／TLS は検証されません。既存のサーバーは明示的に更新してください。ランタイムの正常性を参照してください。

保存済みプロジェクトプランと安全な再試行

impreza_plan_project では、context_id の代わりに git_url と40文字の正確な git_commit も指定できます。オプションの git_username と git_token は、フェッチにのみ使用されます。サーバーは 変更されない保存用アーカイブを取得し、アップロード容量を計上して、 アーカイブの SHA256 とともに source.origin を返します。保存済み設定を 準備または適用する前に、これらの値を確認してください。対応しているのは ポート443でのパブリックネットワーク経由の HTTPS のみです。リダイレクトと サブモジュールは拒否されます。検査時にプロジェクトコードは実行されません。 これらのオプションを使用するには、対応するコントロールプレーンの機能が 必要です。使用する前に、ローカルの MCP パッケージを更新してください。

保持された context_id を指定して impreza_plan_project を使用し、 アーカイブのインベントリと選択した設定ファイルを検査します。必要に応じて project_dir、dockerfile_path、Python の start_command、または php_document_root を選択してください。検出結果と analysis.deployment_options を確認します。

MCP 0.32.0+ では、plan_id、ゼロベースの option_index、アプリ名、 サーバーおよびランタイムの設定を指定して impreza_prepare_project_deployment を呼び出します。アプリ、ジョブ、 DNS レコードを作成せずに、有効な設定を検証して保存します。返された設定を 確認してから、execution_id と configuration_digest のみを指定して impreza_apply_project_deployment を呼び出します。以後のフォームやリクエストの 変更で、その記録を上書きすることはできません。

同じ保存済みデプロイメントを再実行すると、有効期限切れ後やアプリ削除後も、 最初の受付レシートが返されます。レシート、アプリ、キュージョブは一括で 確定されます。応答が不確かな場合は、別のデプロイメントを準備せず、同じ ID と ダイジェストで再試行してください。受付はキューに登録されたことを意味します。 アプリのステータス、ログ、ヘルスを確認してください。失敗したジョブの再起動や 既存アプリの更新は行われません。

impreza_list_prepared_deployments は、最新の保存済み設定20件を一覧表示するか、 1つの execution_id を取得します。環境変数の値は準備済みレコード内で暗号化され、 確認応答には含まれず、受付時にそのレコードから消去されます。その後、アプリは 通常の環境変数ストレージを使用します。確認内容には変数名が表示されます。 文字列値は最大100個まで指定でき、システム変数やルーティング変数の上書きは できません。

アカウントごとの保留中レコードは最大20件で、有効期間はソースプランの期限を 超えず、最大24時間です。初回適用前に、ソース、ルール、ターゲットの利用可否と IP、有効な設定が再確認されます。ドメイン、ポート、容量の予約、依存関係の固定、 ビルドの保証はありません。DNS はアプリのトランザクションの対象外であり、 試行が中断された後も残ることがあります。期限切れの保留中レコードは、アカウントで 次に準備を行った際に削除されます。受付済みのレシートは保持されます。

ソースの検査は MCP 0.31.0+ でも引き続き利用できます。以前の impreza_deploy_project_plan はオプションから直接作成し、冪等ではありません。 プランの作成にはデプロイ権限が必要です。一覧表示には読み取り権限が必要です。 準備と適用にはデプロイ権限が必要です。これらのアカウント全体を対象とするツールには、 リソース制限のない認証情報が必要です。このフローだけを理由にエージェントを 更新する必要はありません。レシピの要件は引き続き適用されます。 プロジェクトプランと確認ガイドを 参照してください。

保持されるソースアップロード

impreza_upload_context を dir と任意の label を指定して使用すると、デプロイせずに変更不可のソースバージョンをアップロードできます。レスポンスには context_id、SHA256、サイズ、有効期限が含まれます。impreza_list_contexts でバージョンを一覧表示または確認できます。

impreza_deploy_custom を mode: "dockerfile" と context_id を指定して使用し、アプリを作成します（または、ローカルの dir を直接デプロイします）。impreza_redeploy_deployment を使用してアプリを再ビルドし、必要に応じて別の保持済み context_id を指定できます。アプリの ID、ドメイン、ホストポート、ボリューム、ビルドレシピは固定されたままです。障害やロールバック後には、選択されたソースが実行中のリリースと異なる場合があります。デプロイ履歴を確認してください。

使用中のソースは引き続き利用できます。参照されていないバージョンは、アップロード時または最後のデプロイリクエストから7日後に期限切れになります。切り離しから7日後ではありません。デフォルトのクォータは、期限切れでない、または参照中のアーカイブが10個、アカウントあたり300 MiB、アーカイブあたり100 MiBです。参照中のソースもカウントされます。未使用のバージョンを削除するには、顧客の確認後に impreza_delete_context を context_id と confirm: true を指定して使用します。メタデータの参照には読み取りスコープ、アップロードにはデプロイスコープ、削除には管理スコープが必要です。リソースに制限された認証情報では、アカウントのアップロードを管理できません。

パッカーは、一般的な依存関係／VCS フォルダー、.env と .env.*（example/sample/template ファイルを除く）、.npmrc、.pypirc を除外します。任意のシークレットをスキャンしたり、.gitignore/.dockerignore を解釈したりすることはありません。アップロードする内容を確認してください。ポータルのアーカイブは変更されずに送信されます。従来の REST アップロードは、retain=true を指定して保持を有効にしない限り、一時的なままです。以前にアップロードしたソースを使用するアプリは、再デプロイ時に新しい保持済みコンテキストを選択して移行できます。これらの MCP ツールには 0.22.0 以降が必要です。ソースの保持だけを目的にエージェントを更新する必要はありません。詳しくはソースアップロードガイドをご覧ください。

Node.js npm ビルド

リポジトリに Dockerfile がなくても、impreza_deploy_custom を mode: "dockerfile"、build_strategy: "node_npm"、git_url（またはローカルの dir）、target_port（通常は 3000）とともに使用して、独立した npm HTTP アプリケーションをデプロイできます。API は Node 24 のレシピを生成します。内容は、npm ci、任意のビルドスクリプト、本番用の依存関係の整理、非 root ユーザーでの npm start です。選択したプロジェクトフォルダーには、package.json、package-lock.json、本番用の start スクリプトが必要です。サーバーで Docker Compose 2.17 以降と BuildKit が利用可能である必要があります。npm ワークスペースを使用する場合は、npm_workspace で明示的に選択してください。名前付き認証情報には build_secrets を使用し、プライベート npm インストールには npmrc シークレットを使用します。この機能には agent 0.6.11 以降が必要です。アプリは 0.0.0.0 と設定済みポートでリッスンする必要があります。実行時の PORT をそのポートに合わせてください。

Git からの再デプロイとプレビューでは、レシピのスナップショットが再利用されます。保持済みのアップロードソースは再利用とソースバージョンの選択に対応しています。以前の一時アップロードは引き続き1回のみ使用できます。レシピでは、ソースのコピーから .git、node_modules、.env、.env.*、.npmrc が除外されますが、任意のシークレットはスキャンされません。認証情報をソースコードに含めないでください。HTTP 起動プローブは / で 500 未満のレスポンスを受け入れます。これはアプリケーションが正しく動作するかをテストするものではありません。

パブリックビルド変数

正常起動を必須にするには、require_healthy_start=true、明示的な healthcheck_path、および build_strategy=node_npm を指定して有効にします。ポータルで「正常起動を必須にする」を有効にしてください。「サーバー」に Agent 0.6.3 以降が表示されている必要があります。明示的に更新し、次のハートビートを待ってください。startup_timeout_seconds には 30〜600 の整数を指定できます。デフォルトは 60 です。この時間枠はコンテナの作成後に始まり、安定したヘルス状態の確認も含まれます。Git の取得、依存関係やイメージのビルド、および復旧には、それぞれ別の制限時間が適用されます。実行中のすべてのサービスが Docker の正常状態を報告し、少なくとも 1 つのコンテナでリクエストを処理できる必要があります。HTTP リダイレクト、認証エラー、およびタイムアウトは、設定された 2xx プローブの条件を満たしません。初回インストールが失敗した場合、コンテナは削除され、永続ボリュームは保持されます。失敗の詳細には診断ログが含まれます。置き換えに失敗した場合、利用可能であれば、正常であることが確認済みの以前のリリースに復旧します。復旧と手動ロールバックでは、保存されたリリースの起動ポリシーが使用されるため、正常になるまで時間のかかるリリースも、元の制限時間が維持されます。障害復旧では、データベースへの書き込みや変更可能なデータは元に戻りません。コントロールプレーンは作成時に非互換のエージェントを拒否し、現在のポーリングで startup-health-v1 がサポートされていない場合は、このポリシーを一切配信せず、一致するヘルス確認がある場合にのみ成功を受け入れます。プレビューにはポリシーが引き継がれ、再デプロイではスナップショットが維持されます。デプロイの読み取りでは startup_health が公開されます。保存されたポリシーを変更するには、新しいデプロイを選択してください。省略または false の場合は従来の動作が維持されます。起動タイムアウトを設定するには、このオプションを有効にする必要があります。この公開オプションは、生成された Node ビルド向けです。起動後のゼロダウンタイム切り替えや、継続的な自動ロールバックを提供するものではありません。ローカル MCP 入力のサポートには 0.20.0 以降が必要です。既存のエージェントは、お客様がアップデーターを実行した場合にのみ更新されます。詳しくは https://docs.imprezahost.com/tutorials/agent-apps-panels.html#required-startup をご覧ください。

Node のヘルスチェック：build_strategy=node_npm の場合は、healthcheck_path（例：/health または /api/ready）を任意で設定するか、ポータルの「ヘルスチェックパス」に入力してください。生成された Docker のヘルスチェックは、コンテナ内の 127.0.0.1 に対して target_port を使って HTTP GET を送信し、ステータスが 200〜299 であることを要求します。リダイレクトには従わず、認証情報も送信しません。このルートはログインなしで動作し、アプリがリクエストを処理するために必要な依存関係の状態を報告する必要があります。/ または ASCII 文字で 200 文字以下のパスを指定してください。各セグメントは英字、数字、アンダースコア、またはハイフンで始まり、その後にはピリオドやチルダも使用できます。末尾のスラッシュは使用できます。URL、クエリ文字列、フラグメント、パーセントエスケープ、空白、親セグメント、および連続するスラッシュは拒否されます。従来の / プローブを使用して 500 未満のステータスを受け入れるには、フィールドを省略してください（ポータルでは空欄のままにします）。/ を明示的に設定した場合は、2xx が必要です。既存のデプロイのスナップショットは変更されません。保存された healthcheck_path はデプロイの読み取りで返され、新しいプレビューに引き継がれ、再デプロイ時も保持されます。変更するには、新しいデプロイが必要です。静的サイトでは引き続き index.html プローブが使用され、カスタム Dockerfile では独自の HEALTHCHECK が定義されます。プローブは 5 秒ごとに実行され、リクエストのタイムアウトは 2 秒です。起動を必須にしない場合、エージェント 0.6.2 以降は最大 60 秒間、起動状態を確認します。置き換えに失敗した場合、利用可能であれば、正常であることが確認済みの以前のリリースに復旧します。復旧先がない場合、初回インストールは起動時の警告を伴って完了することがあります。そのため、準備完了と判断する前にヘルス状態とログを確認してください。このデフォルトポリシーでは、継続的なロールバック、ゼロダウンタイムのルーティング、外部からの稼働時間チェックは提供されません。起動期限を強制するには、エージェント 0.6.3 以降で正常起動を必須にしてください。ローカル MCP 入力には 0.19.0 以降が必要です。healthcheck_path だけを使用する場合は、0.6.2 以降であればエージェントの更新は必要ありません。 公開ビルド設定：生成される node_npm および node_npm_static レシピでは、npm run build（その prebuild／postbuild スクリプトを含む）でのみ利用できる文字列値のオブジェクト public_build_vars を指定できます。たとえば、{"VITE_API_URL":"https://api.example.com"} を指定すると、Vite で公開 API URL をサイトにコンパイルできます。名前は VITE_、NEXT_PUBLIC_、PUBLIC_ のいずれかで始まり、大文字、数字、アンダースコアのみを含み、128 文字以内である必要があります。上限は、エントリー数が20件、値が1つあたり4096 UTF-8 バイト、名前と値の合計が16384バイトです。空文字列はそのまま保持されます。NUL は拒否されます。値はリテラルデータとして扱われ、シェル展開や変数展開は行われません。ポータルには公開ビルド変数を KEY=value の行として入力します。値の一部になってしまうため、前後に引用符を付けないでください。これらの値は公開されるものであり、バンドル、イメージのメタデータ、ログに含まれる場合があります。パスワード、トークン、シークレットは絶対に指定しないでください。これらは npm ci には渡されず、実行時変数にも自動的に追加されません。実行時変数は実行中のコンテナを設定するものであり、コンパイル済みのブラウザファイルを書き換えることはありません。設定は作成時に保存され、デプロイメントの読み取り時に公開され、新しいプレビューに引き継がれ、再デプロイ時にも再利用されます。プレビューの実行時設定の継承や上書きによって、このビルドスナップショットが変更されることはありません。異なる公開ビルド値を使用するには、別のデプロイメントを作成してください。既存のスナップショットでは、公開ビルド値はデフォルトで設定されていません。対応するビルド認証情報には、agent 0.6.11+ の build_secrets を使用してください。未対応のビルド設定には、カスタム Dockerfile が必要です。ローカル MCP には 0.18.0+ が必要です。既存のビルド実行機能を超える agent の更新は不要です。

ビルド設定ガイドを参照してください。

プロジェクトのサブフォルダーにあるアプリ

サブフォルダーから独立した npm アプリをデプロイするには、node_npm または node_npm_static で project_dir（デフォルトは .）を設定するか、ポータルで「プロジェクトフォルダー」を選択します。たとえば、apps/site には独自の package.json と、それに対応する package-lock.json が必要です。static_output_dir はそのフォルダーからの相対パスです。npm のインストールとビルドでは、選択したフォルダーのみが /app にコピーされます。リポジトリ／アップロード全体は Docker のビルドコンテキストとして使用されるため、ルートにある .dockerignore は引き続き適用されます。パスは120文字以内、非表示でないセグメントは5つまでです。親ディレクトリ、node_modules、シンボリックリンクを含むパスは拒否されます。フォルダーが見つからない場合やビルドに失敗した場合は、正常な状態で稼働しているランタイムが維持されます。project_dir の値はデプロイメントの読み取り時に返され、作成時に保存され、新しいプレビューに引き継がれます。再デプロイ時には保存済みのレシピが再利用されます。既存のスナップショットでは、デフォルトは . です。フォルダーを変更するには、新しいデプロイメントが必要です。この機能は、1つのリポジトリ内にある独立したアプリをサポートします。共有ワークスペースやフォルダー外の依存関係には対応していません。その場合は、カスタム Dockerfile を使用してください。アナライザーはサブフォルダーを検出しません。選択したアプリのメタデータを指定し、「プロジェクトフォルダー」を自分で確認してください。ローカル MCP には 0.17.0+ が必要です。既存のビルド実行機能を超える agent のアップグレードは不要です。

プロジェクトフォルダーガイドを参照してください。

Compose スタックをインポートする

impreza_prepare_compose を compose_yaml とともに使用し、web_service と整数の target_port を明示的に選択します。デプロイする前に、サービス、永続ボリューム、必須変数、変更内容、ブロッカーを確認します。デプロイには impreza_deploy_custom を mode: "compose" とともに使用し、同じ YAML／サービス／ポートを指定して、返された analysis_id を compose_review_id に設定します。

最大 12 個のサービス、プライベートブリッジネットワーク、ローカルの名前付きボリューム、サービス依存関係を含む、自己完結型のパブリックイメージスタックに対応しています。元のホストポートバインディングは削除され、選択した HTTP サービスのみがプロキシに接続され、管理対象のループバックポートを受け取ります。コンテナ名とボリューム名はデプロイごとの固有名になります。YAML ではサービスごとに CPU／メモリの制限を宣言してください。

レビューでは、イメージの取得、コードの実行、リソースの予約は行いません。ローカルのビルドコンテキストと補助ファイルを使用するには、レビュー時とデプロイ時に同じ context_id を保持しておく必要があります。実行時の env_file で受け付けられるのは、補間や継承される裸のキーを含まない、リテラル値の代入のみです。エイリアス、プロファイル、ホスト権限、外部リソースは、このインポートの対象外です。シークレットを埋め込む代わりに、大文字の変数を参照してください。実行時の値は 1 行の文字列で、最大 4 KiB とし、前後の空白、引用符、バックスラッシュ、ドル記号、または # の前の空白を含めることはできません。変数には明示的な参照を指定します。すべてのサービスの環境変数が自動的に含まれるわけではありません。必須値は、作成時、編集時、再デプロイ時に確認されます。

インポートしたソースはマニフェストとして保存されます。再デプロイでは、このソースと名前付きデータが再利用されます。ソース／トポロジーを変更するには、新しいデプロイが必要です。失敗からの復旧には既存のエージェントポリシーが適用され、データベースへの書き込みは元に戻されません。パブリックイメージスタックのローカル MCP サポートには 0.21.0 以降が必要です。保持されるビルド／実行時ソースには MCP 0.34.0 以降とエージェント 0.6.11 以降が必要です。 Compose インポートガイドを参照してください。

プロジェクト設定を準備する

デプロイする前に、impreza_prepare_project を package_json、dockerfile、および任意の dockerfile_path とともに使用します。フレームワークのヒント、利用可能なビルドコマンドと起動コマンド、最終 Dockerfile ステージで明示されたポート、確認が必要な検出事項が返されます。各ファイルの上限は 32 KiB です。送信前にファイルに認証情報が含まれていないか確認し、.env ファイルやシークレットは決して送信しないでください。

これは、指定されたテキストの助言を目的とした分析です。リポジトリの取得、コードの実行、Dockerfile の生成、リソースのデプロイは行いません。Git によるデプロイでは、デフォルトで Dockerfile が使用されます。対応する npm プロジェクトでは、Node レシピを選択できます。分析 ID はメタデータを識別するものであり、実行可能なプランではありません。 /v1/platform/deployments/custom/prepare を公開する API が必要です。

主流プロバイダーではなく、このホストを選ぶ理由

どのプロバイダーでもアプリを実行できます。このホストは、エージェントがユーザーの身元に結び付かないインフラストラクチャを、ブラウザーを開くことなく、最初から最後まで取得して運用できるように構築されています。

• アカウントの開設に KYC もメールアドレスも不要です。 アカウントは、生成されたクライアント ID と復旧トークンで構成されます。書類も、自撮り写真も、電話番号も必要ありません。
• 暗号資産で入金できます。 impreza_topup は BTC、XMR、USDT、TRX に対応しており、impreza_order_vps はその残高でサーバーを購入します。エージェントはカードを使わずに、「サーバーが必要」という状態からデプロイの実行まで進められます。
• オフショアと国内の管轄区域を並べて選択でき、アカウントごとではなくプロジェクトごとに選べます。
• Tor は追加機能ではなく、デプロイ先の選択肢です。 impreza_add_onion を使うと、1 回の呼び出しでデプロイに .onion アドレスが割り当てられ、エージェントは通常のサイトを公開するのと同じように、隠しサービスを公開できます。impreza_onion_auth_* は Tor v3 の制限付き検出（クライアント認証）を管理します。サーバーにキーペアの生成を依頼しない限り、秘密鍵が顧客の Tor クライアントから外に出ることはありません。生成を依頼した場合も、秘密鍵は一度だけ表示され、保存されません。
• 設定に API キーは不要です。 ホスト型コネクターは OAuth で認証します。

これらがプロジェクトに関係しない場合は、主流のプロバイダーを選ぶのが適切で、通常は導入時のコストも安くなります。このサービスは、これらが重要となるプロジェクトのためにあります。たとえば、圧力下での調査やジャーナリズム、検閲の回避、セキュリティ関連の業務、そしてサポートへの問い合わせひとつで法的な氏名と結び付けられるべきではないあらゆる用途です。

リリース保持型のロールバック

ソースツリーに impreza_rollback_deployment が追加されています。impreza_api_call を使って、/platform/deployments/{id} からデプロイの release_history を読み込み、rollback_supported: true の rel_... エントリを選択します。

ツールを呼び出す前に、選択したリリースと中断の可能性について顧客に説明してください。その後、deployment_id、target_version、confirm: true を指定して呼び出します。ホスト型コネクターでは、代わりに 2 回の呼び出しを使う confirm_token フローを使用します。この操作には manage スコープと、互換性のある API およびエージェントが必要です。

過去のリリースがすでに保持されていない場合があります。エージェントは、コンテナーを置き換える前に、ローカルイメージと、変更のないポート、ストレージ、ルーティングを確認します。現在正常に動作しているランタイムを保存し、選択したリリースの起動に失敗した場合は復旧を試みます。データベースの内容や変更可能なデータはロールバックされません。キューに登録された応答は、復元が完了したことを示すものではありません。結果はデプロイ履歴で確認してください。

impreza-mcp 0.12.0 で利用できます。互換性のある API およびエージェントが必要です。

静的 npm サイト

静的 npm サイトでは、Git／コンテキストソース（mode=dockerfile）で build_strategy=node_npm_static を選択するか、ポータルで「静的サイト + npm」を選択します。選択したプロジェクトフォルダー内に独立した npm パッケージが必要です。また、対応する package-lock.json と、選択した出力フォルダーに index.html を生成するビルドスクリプトが必要です。Node 24 が依存関係をインストールしてビルドを実行し、権限を持たない Nginx が、設定可能な SPA フォールバックを使って選択した出力フォルダーのみを配信します。start スクリプトは不要です。target_port のデフォルト値は 8080 です。Compose 2.17 以降と BuildKit が必要です。SSR とサーバー関数には対応していません。明示的な npm_workspace と build_secrets は、ドキュメントに記載されたソースとエージェントの要件を満たす場合にサポートされます。実行時変数（VITE_* や PORT を含む）によって静的バンドルが書き換えられたり、設定済みの Nginx ポートが変更されたりすることはありません。index.html を含む相対出力フォルダーを選択するには static_output_dir（デフォルトは dist）を使用し、SPA フォールバックまたは不明なルートに対する 404 を選択するには static_spa（ブール値、デフォルトは true）を使用します。ポータルでは両方のフィールドを設定できます。パスは 120 文字以内、5 セグメント以内に制限され、隠しセグメント、親セグメント、node_modules セグメントは使用できません。出力内またはその親パスにあるシンボリックリンクは拒否されます。これらの設定は作成時に選択され、レシピのスナップショットに保存され、static_options として公開され、新しいプレビューにも引き継がれます。再デプロイでは保存済みのレシピが再利用されます。既存のデプロイでこれらの設定を変更するには、新しいデプロイを作成する必要があります。既存のスナップショットには元のレシピが保持されます。ローカル MCP オプションの入力には 0.16.0 以降が必要です。サポート対象の公開設定には public_build_vars を使用してください。それ以外のビルド時設定にはカスタム Dockerfile が必要です。ソース内の .env/.env.*/.npmrc/.git/node_modules は除外されます。出力フォルダーは公開されるため、生成されたファイルをすべて確認してください。index.html がない場合や、出力がシンボリックリンクの場合、ビルドは失敗します。既存のプレビュー／再デプロイのスナップショットでは、元のストラテジーが保持されます。ローカル MCP には 0.15.0 以降が必要です。既存のビルド実行ツールに加えてエージェントをアップグレードする必要はありません。アナライザーは static_npm_recipe と、条件付きで deployment_options を返します。メタデータは、静的ビルドが正常に機能することの証明ではありません。

ステータス

パッケージバージョン：0.55.1。 ツールカタログは、アプリのデプロイに加え、アカウントと暗号資産の残高、カタログと注文、ドメイン／DNS と登録、請求書、スナップショットとバックアップに対応した VPS のライフサイクル、専用／ベアメタルサーバー、プランのアップグレード、Titan／Google Workspace のメールボックスを網羅しています。また、5 つの AI ツール向けに、すぐに貼り付けられる設定スニペットを生成するセットアップウィザードも備えています。

さらに、アプリの稼働開始後に必要となる機能もすべて備えています。顧客自身の S3 バケットへのバックアップと復元、出力を保持するアプリのタイマー、ポーリングを不要にする送信 Webhook、アプリ自身のファイルの読み取り、アプリ独自のコマンドラインの実行が可能です。

ローカル（npx）サーバーとホスト型 OAuth コネクターは、**同じツールカタログ（ローカルパッケージには 219 個のツール）**を公開しています。明示された一方向の差異は残っています。impreza_get_log_request はホスト型のみです（コントロールプレーンのみが単独の request_id を解決できます。ローカルではアプリに対して impreza_tail_logs を再度呼び出してください。リクエストは重複排除されます）。impreza_list_approvals、impreza_get_approval、impreza_get_credential_policy はホスト型が優先されます（ローカルでは、同じ読み取り操作を impreza_api_call 経由の REST 呼び出しで実行できます）。また、impreza_upload_context はローカルのみです（バイナリーの tarball ストリーミングはホスト型のトランスポートに適していません）。

0.11.0 の新機能

アプリ独自のコマンドラインを実行できます。 WordPress の WP-CLI、Nextcloud の occ、Gitea の gitea admin、ダンプ用のデータベースクライアントを実行するには impreza_app_cli を使い、出力を取得するには impreza_get_cli_run を使います。まず run_id を指定せずに impreza_get_cli_run を呼び出してください。アプリで使えるコマンドラインを一覧表示し、それぞれの用途を説明して、動作する例を1つ示します。

• Docker ソケットは不要です。これは主張ではなく、実測で確認されています。 コマンドはアプリ独自のイメージからビルドした別コンテナで実行され、アプリ独自のネットワークに接続され、データがマウントされます。これは公式 CLI イメージが想定している構成です。cap_drop: ALL が設定され、マシンに新たな権限は付与されません。
• 引数は文字列ではなく、リストで渡します。 各要素は execve を通じて1つの argv エントリになるため、分割、グロブ展開、置換は行われません。引用符の扱いを気にする必要はなく、値に含まれる $ や ; もそのままです。実稼働サイトで検証済みです。option update blogname 'dollars $HOME and a ; semicolon' を実行すると、送信したとおりの内容が読み戻されます。
• 破壊的な操作が可能であり、それを前提に扱われます。 コマンドラインからはアプリ自体と同じ操作がすべて可能なため、manage スコープが必要で、確認が必須です。引数は許可リストではなく自由に指定できます。これは purge_data を指定した uninstall ですでに許容されている上限と同じです。また、wp のサブコマンド一覧を維持するのはすぐに古くなりますが、確認による保護以上のものは何も守れません。
• CLI のバージョンはアプリに合わせられます。 コマンドラインがアプリ独自のイメージに含まれる場合は、そのデプロイから取得されるため、カタログの更新に合わせて更新されます。古い Nextcloud の occ を新しいデータベースに対して実行すると、メンテナンスコマンドによってインストール環境が破損する可能性があります。

カスタムデプロイにはコマンドラインがありません。独自のイメージであるため、プラットフォームでは何が含まれているか把握できません。その場合は、種類が command のスケジュールタスクを使用してください。

0.10.0 の新機能

アプリ独自のファイルの中を確認できます。 impreza_get_logs で読み取れるのは標準出力です。しかし、正しく起動しなかったデプロイで本当に知りたい「その変数は設定ファイルに反映されたのか」という疑問には答えられません。そこで、2つのツールを追加しました。確認には impreza_inspect_app、結果の取得には impreza_get_app_read を使います。

• 操作は4種類だけで、5種類目はありません。 ディレクトリの list、ファイルの read（上限256 KB）、末尾の行を取得する tail、拡張正規表現を使ってパス配下を検索する grep です。インターフェースにコマンド文字列がないため、シェルもありません。
• 設計上、読み取り専用です。 1回限りのコンテナでアプリのストレージを読み取り専用でマウントします。これはバックアップで使用しているのと同じ仕組みです。Docker ソケットも書き込み機能もありません。そのため、アプリが failed 状態で起動できない場合にも使えます。最も必要とされるのは、まさにそのようなときです。
• 対象はアプリ独自のストレージのみです。 data、またはアプリのマニフェストで宣言されている名前付きボリュームのいずれかが対象です（WordPress では data と wp_db が公開されるため、データベースファイルも読み取れます）。指定したアプリで利用できる一覧を確認するには、read_id を指定せずに impreza_get_app_read を呼び出してください。
• 返される内容は信頼できず、秘密情報が含まれることもよくあります。 アプリの設定ファイルには、データベースのパスワードが含まれている場合があります。内容が届くのはお客様だけです。このフィールドはリクエストログの拒否リストに登録されており、記録は1日以内に削除されます。

0.6.1 以降

npm ページでは説明されていなかった 3 つのリリース。それぞれに、ひとつの大きな機能が追加されました。

• 0.7.0 — バックアップと復元： デプロイのデータを、アカウントが所有する Impreza S3 バケットにバックアップできます。データの隣にチャンクごとの SHA-256 マニフェストが保存されるため、お客様自身の認証情報を使って、当社に問い合わせることなくコピーを検証できます。さらに、スケジュール（デフォルトは毎日、3 件を保持）と、別のアプリにも復元できる機能を備えています。これにより、アプリをサーバー間で移動できます。
• 0.8.0 — スケジュールタスク： アプリにタイマーを設定し、出力を保存します。Nextcloud の cron や、訪問者のいないサイトでの WordPress の wp-cron など、正しく動作するためにスケジュールタスクが必要なアプリに便利です。
• 0.9.0 — アウトバウンド Webhook： デプロイ、バックアップ、VPS のイベントを購読して、ポーリングを停止できます。HMAC 署名付きの配信と配信ログを備えています。

0.6.1 の新機能

tools/list に、アカウントが実際に所有するものが反映されるようになりました。 ツールの約 3 分の 1 は、それらが動作するマシンを所有している場合にのみ意味があります。VPS がなければ VPS の電源操作ツールは「見つかりません」としか返せないため、VPS を所有するまで一覧から除外されます。一般的なアカウントでは、ツール数が 97 個から約 70 個になり、何かを尋ねる前に消費されるコンテキストが約 6,000 トークン減ります。

動作について、知っておくとよいことが 3 つあります。

• 購入に関する機能は、決してフィルタリングされません。 何も所有していないアカウントこそ、何かを購入する必要があります。そのため、注文、チャージ、請求書、カタログは常に一覧に表示されます。
• 購入すると、セッション中に一覧が増えます。 サーバーは注文と同じレスポンスで notifications/tools/list_changed を送信するため、これに対応しているクライアントは再接続せずに新しいツールを取得できます。
• フェイルオープンで動作します。 このサーバーが API に問い合わせられない場合、推測するのではなく、すべてのツールを一覧表示します。

ツールを非表示にすることは、認可の境界ではありません。アカウントが所有していないものは、API が引き続き拒否します。これは、利用できないツールが一覧に含まれないようにするものです。

0.6.0 の新機能

匿名性を重視して構築されたホストでのみ意味を持つ機能が 4 つあります。

• ダークプレビュー — ブランチをプッシュすると、専用の一時的な Tor .onion でプレビューを取得できます。他のすべてのプラットフォームでは、プレビュー URL にブランチ名が含まれ、それがパブリック DNS と恒久的な Certificate Transparency ログに記録されます。ブランチ名には、チケット ID、顧客名、未公開機能が含まれることがあります。この機能では、どちらの記録も作成されず、ブランチが削除されるか TTL が切れると鍵も破棄されます。impreza_configure_previews、impreza_list_previews、impreza_retire_preview。
• エージェント用サブ認証情報 — 保有している認証情報から、より権限を絞った認証情報を作成し、サブタスクに渡せます。デプロイ 1 件、1 時間、支出不可といった制限を設定できます。子の権限がどの軸でも親を超えることはなく、認証情報を取り消すと、どれだけ深く派生していても、それが作成したすべての認証情報が取り消されます。impreza_mint_subcredential、impreza_list_credentials、impreza_revoke_credential、impreza_agent_activity。
• 確認できるプライバシーレポート — impreza_privacy_report は、アカウントについて保存しているすべてのフィールド、その用途、保存期間、他に誰が閲覧できるかを返します。さらに、実際に残っている最古のレコードを基準に、当社のデータ保持状況を測定します。内容ではなく、件数と日付範囲のみを示します。
• 推測する前に確認 — ドキュメントを検索する、デプロイ前にデプロイマニフェストを検証する（サードパーティ CDN、パブリック DNS リゾルバー、漏えいしたシークレットのプライバシー検査を含みます）、または問題の原因を診断できます。impreza_search_docs、impreza_validate_manifest、impreza_doctor。

さらに、長時間の処理がポーリングを求めることなく完了を報告できる Tasks 拡張機能と、対応するクライアント内に表示される 3 つの MCP Apps パネル（支払いカード、サーバーカード、デプロイウィザード）もあります。

以下の表は全一覧ではなく、抜粋です。多くの人が最初に利用するツールを掲載しています。クライアント独自のツール一覧が正確な情報源です。この一覧にないツールは、impreza_api_search で検索できます。

ツール	ラップ対象
アプリとデプロイメント
impreza_list_servers	GET /v1/platform/servers
impreza_list_apps	GET /v1/platform/apps
impreza_list_deployments	GET /v1/platform/deployments + /custom（統合）
impreza_upload_context	POST /v1/platform/deployments/custom/contexts?retain=true
impreza_list_contexts	GET /v1/platform/deployments/custom/contexts[/{context_id}]
impreza_delete_context	DELETE /v1/platform/deployments/custom/contexts/{context_id}
impreza_deploy_custom	POST /v1/platform/deployments/custom（3つのモード）
impreza_deploy_catalog_app	POST /v1/platform/deployments
impreza_uninstall_deployment	POST .../uninstall
impreza_get_logs	POST .../logs（同期テール、最後のN行）
impreza_restart_deployment	POST .../restart
impreza_redeploy_deployment	POST .../custom/{id}/redeploy（同じドメインでインプレース再ビルド）
impreza_add_onion	POST .../onion/add
impreza_set_onion_profile	POST .../onion/profile（standard / hardened / max の強化レベル）
impreza_export_onion_key	POST .../onion/export（お客様のX25519キーで封印され、平文が転送されることはありません）
impreza_fetch_onion_key_export	GET .../onion/export/{command_id}（一度だけ読み取り可能 — データは消去されます）
impreza_rotate_onion_key	POST .../onion/rotate（新しい.onionアドレス。古いアドレスは無効になります）
impreza_onion_auth_list	GET .../onion/clients
impreza_onion_auth_add	POST .../onion/clients（pubkey、またはgenerate:true → private_keyを一度だけ表示）
impreza_onion_auth_revoke	DELETE .../onion/clients/{name}
impreza_change_domain	POST .../domain
impreza_git_webhook_status	GET .../custom/{id}/git-webhook
impreza_git_webhook_connect	POST .../custom/{id}/git-webhook/connect
impreza_git_webhook_disconnect	POST .../custom/{id}/git-webhook/disconnect
アカウントと残高
impreza_account_info	GET /v1/account
impreza_list_services	GET /v1/account/services
impreza_topup	POST /v1/account/topup — BTC / XMR / USDT / TRXでチャージ
impreza_topup_status	GET /v1/account/topup/{invoice_id}
impreza_topup_payment	GET /v1/account/topup/{invoice_id}/payment — 暗号資産のアドレスと支払い金額
カタログと注文
impreza_list_products	GET /v1/products — 製品と料金。VPSは最小サイズで掲載されています（configurable: true）
impreza_vps_offer	GET /v1/products/vps — VPSのロケーション、オペレーティングシステム、CPU / メモリ / ディスクの範囲と料金。構成全体を指定すると、GET /v1/products/vps/quoteで正確な料金を取得できます
impreza_order_vps	POST /v1/orders — ロケーション、OS、サイズで指定したVPS（またはproduct_idで指定した固定プラン）。残高から支払われます。デフォルトではImprezaエージェントがインストールされた状態で起動します（app: "@agent"。構成可能なVPSと固定VPSプランのどちらでも、同じアプリをimpreza_vps_offerで見積もり、結果のapp_requestedとして返します）。テキスト以外のappはリクエスト前に拒否されます。OSのみの場合はapp: "none"を指定します（カスタマーポータルではOSのみがデフォルトです）。エージェントを後から追加する場合は、顧客の確認を得てimpreza_install_agentを使用してください。202はエージェントの準備完了を意味しません。impreza_list_servicesをポーリングし、エージェントのインストールと接続が完了するとimpreza_list_serversに表示されます
ドメインとDNS
impreza_domain_check	GET /v1/domains/check
impreza_domain_details	GET /v1/domains/{domain}
impreza_list_dns	GET /v1/domains/{domain}/dns
impreza_add_dns_record	POST /v1/domains/{domain}/dns
impreza_update_dns_record	PUT /v1/domains/{domain}/dns
impreza_delete_dns_record	DELETE /v1/domains/{domain}/dns
impreza_set_nameservers	PUT /v1/domains/{domain}/nameservers
VPSのライフサイクル（Proxmox）
impreza_vps_status	GET /v1/vps/proxmox/{id}/status
impreza_vps_power	POST /v1/vps/proxmox/{id}/{start|shutdown|reboot|stop}
impreza_vps_list_backups	GET /v1/vps/proxmox/{id}/backups
impreza_vps_create_backup	POST /v1/vps/proxmox/{id}/backups
impreza_vps_list_templates	GET /v1/vps/proxmox/{id}/templates
impreza_vps_reinstall	POST /v1/vps/proxmox/{id}/reinstall — 破壊的操作（データを消去）
impreza_vps_resize	POST /v1/services/{id}/resize — 日割り料金でvCPU、メモリ、ディスクを増強します（先にGET /v1/services/{id}/resize/quoteで見積もり）。max_amountで上限を固定します

インストールとセットアップ

前提条件

• Node ≥ 20
• API キーとシークレットを持つ Impreza Host アカウント （clientarea → API Keys。MCP サーバーを実行するマシンの IP をキーのホワイトリストに登録する必要があります）

npx で一度だけ実行

グローバルインストールは不要です。npx impreza-mcp で動作します。

またはグローバルインストール

npm install -g impreza-mcp

そのまま貼り付けられる設定スニペットを取得

最も手早い方法は、バイナリに直接問い合わせることです。

npx impreza-mcp setup --tool claude-code
# also: cursor | continue | zed | codex-cli

ウィザードは、AI ツールの MCP 設定に追加する JSON ブロックと、正確なファイルパス、設定後の手順（通常は「AI ツールを完全に終了してから再起動」）を出力します。ディスクには書き込みません。既存の設定を誤って上書きし、他の MCP サーバーの設定を消してしまわないよう、自分で貼り付けてください。

または手動で設定

Claude Code — ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）または %APPDATA%/Claude/claude_desktop_config.json（Windows）に追加します。

{
  "mcpServers": {
    "impreza": {
      "command": "npx",
      "args": ["-y", "impreza-mcp"],
      "env": {
        "IMPREZA_API_KEY": "imp_...",
        "IMPREZA_API_SECRET": "..."
      }
    }
  }
}

Claude Code を再起動します。ツールは MCP アイコンの下に表示されます。

Cursor — ~/.cursor/mcp.json に追加します（上記と同じ形式です）。

Continue — ~/.continue/config.json に追加します。

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "impreza-mcp"],
          "env": {
            "IMPREZA_API_KEY": "imp_...",
            "IMPREZA_API_SECRET": "..."
          }
        }
      }
    ]
  }
}

Zed — 設定に追加します。

{
  "context_servers": {
    "impreza": {
      "command": {
        "path": "npx",
        "args": ["-y", "impreza-mcp"],
        "env": {
          "IMPREZA_API_KEY": "imp_...",
          "IMPREZA_API_SECRET": "..."
        }
      }
    }
  }
}

チャットでの使用

セットアップ後は、AI に自然な言葉で話しかけてください。

「Impreza のサーバーを一覧表示して。」 → impreza_list_servers を呼び出します

「このディレクトリを Impreza VPS にデプロイして、.onion 経由で公開して。」 → 作業ディレクトリを Dockerfile モードのカスタムデプロイとしてパッケージ化し、アップロードして、 onion=true でデプロイし、.onion アドレスを報告します。

「自分のエージェントで実行中のアプリは？」 → 適切なサーバーに絞り込んで impreza_list_deployments を呼び出します。

認証とセキュリティ

IMPREZA_API_KEY と IMPREZA_API_SECRET は、AI ツールの MCP 設定環境変数に保存されます。impreza-mcp 自体が所有するディスク上のファイルには保存されません。MCP サーバーはシークレットをメモリ上だけに保持し、HTTP リクエストヘッダーにのみ設定します。

この MCP サーバーを実行するマシン（ほとんどの場合はお使いのノート PC）の IP を、API キーのホワイトリストに登録する必要があります。Impreza の clientarea でホワイトリストを管理してください。

Tor 経由での使用

MCP サーバーはローカルの Tor デーモン経由で API のすべての呼び出しをルーティングできるため、API リクエストには設定済みのプロキシが使用されます。ネットワークプロバイダーには Tor への接続が引き続き見えます。このオプションを使っても、Tor を使用していることは隠せません。

1. Tor をインストールして起動します（tor デーモンまたは Tor Browser。どちらも一般的に SOCKS5 リスナーを公開します。デーモンの場合は 127.0.0.1:9050、Tor Browser の場合は 127.0.0.1:9150 です。ローカルの設定を確認してください）。

2. MCP 設定の環境変数に IMPREZA_PROXY を追加します。

   "env": {
     "IMPREZA_API_KEY": "imp_...",
     "IMPREZA_API_SECRET": "...",
     "IMPREZA_PROXY": "socks5://127.0.0.1:9050"
   }
   

以降、すべての API リクエストは Tor 経由で送信され、API ホスト名も Tor 自身が解決するため（リモート DNS）、ローカルでの名前解決は行われず、DNS リークは発生しません。トランスポートはフェイルクローズ方式です。プロキシに到達できない場合、または接続を拒否された場合、リクエストは失敗します。直接のクリアネット接続に黙ってフォールバックすることはありません。

必要に応じて、IMPREZA_BASE_URL を API の .onion ミラーに指定できます。Tor が onion 接続を認証して暗号化するため、http:// が受け付けられるのは v3 .onion ホストのみです。クリアネットのホストには https:// が必要です。onion URL を使う場合も、IMPREZA_PROXY を明示的に指定する必要があります。onion URL が HTTPS を使用している場合でも、クライアントは直接の DNS 解決と接続を拒否します。プロキシ経由のリクエストではリダイレクトを拒否し、リクエストのタイムアウト時間を制限し、最大 16 MiB のレスポンスボディを受け付けます。

アカウント側での調整が 1 つあります。Tor の出口 IP は絶えず変わるため、API キーに固定 IP のホワイトリストを設定しても機能しません。clientarea でキーの IP 要素を tofu または keyonly に設定してください。

PHP のデプロイ

PHP アプリを確認するには、composer_json と必要に応じて php_document_root を指定して impreza_prepare_project を使用します。mode: "dockerfile" および build_strategy: "php_composer" を指定した impreza_deploy_custom を使用し、Git、ローカルディレクトリ、または保持されたアップロードからデプロイします。PHP 8.4/Apache のレシピは、composer.json と一致する composer.lock から本番環境用の依存関係をインストールします。Composer のスクリプトやプラグインは使用せず、実際のプラットフォーム要件を確認します。アプリケーションには project_dir を、index.php を含む公開サブフォルダーには php_document_root を指定します（既定値は public）。Apache は target_port（既定値は 8080、最小値は 1024）で非 root ユーザーとして実行されます。公開ファイルを配信し、存在しないパスは index.php に送ります。

ヘルスチェックでは、/ または指定した healthcheck_path で、リダイレクトを伴わない HTTP 2xx が必要です。オプションの require_healthy_start には、明示的なパスと agent 0.6.3 以降が必要で、起動猶予時間は 30～600 秒です。プレビューと再デプロイでは、保存済みのレシピが維持されます。カスタムリポジトリ、プライベート依存関係の認証情報、インストールプラグイン、追加拡張機能、.htaccess ルール、フロントエンドのビルド、アプリケーションのセットアップやマイグレーションには、カスタム Dockerfile が必要です。start_command と公開ビルド変数は PHP のオプションではありません。分析は参考情報であり、ロックファイルやリポジトリは確認しません。PHP デプロイガイドを参照してください。

Python のデプロイ

Python アプリを確認するには、requirements_txt と明示的な start_command を指定して impreza_prepare_project を使用します。mode: "dockerfile" および build_strategy: "python_pip" を指定した impreza_deploy_custom を使用し、Git、ローカルディレクトリ、またはアップロードされたコンテキストからデプロイします。Python 3.13 のレシピは、PyPI からフラット形式の requirements.txt をインストールし、非 root ユーザーとして実行されます。独立したアプリケーションフォルダーには project_dir を指定します。本番サーバーを target_port（既定値は 8000）で 0.0.0.0 にバインドして起動します。たとえば、Flask と gunicorn を requirements に宣言したうえで、exec gunicorn --bind 0.0.0.0:$PORT app:app を使用します。PORT と HOST は実行時変数です。認証情報を保存済みのコマンドに含めないでください。

既定の Python ヘルスプローブでは、/ で HTTP 2xx が必要です。別のルートを使用する場合は healthcheck_path を指定します。オプションの require_healthy_start には、明示的なパスと agent 0.6.3 以降が必要で、起動猶予時間は 30～600 秒です。プレビューと再デプロイでは、保存済みのレシピが維持されます。依存関係のオプション、include、URL、ローカルプロジェクト、プライベートビルド認証情報、システムパッケージ、その他のパッケージマネージャーには、カスタム Dockerfile が必要です。公開ビルド変数は引き続き npm のみで使用できます。分析は参考情報であり、実際の依存関係はサーバー上のビルドで解決されます。Python デプロイガイドを参照してください。

ビルド

npm install
npm run build
# dist/server.js is the entry point

監視下での準備

管理者が agent 0.6.12 以降の制御されたビルドを有効にしない限り、これらの従来のワーカールールが適用されます。制御されたビルドでは、新しいビルドに対して、実行者の停止と復旧が検証されます。

agent 0.6.8 以降：対応する Linux/systemd のデプロイでは、イメージのプルとビルドが別の監視対象プロセスで実行されます。agent が再起動した場合、処理を繰り返さず、正確なワーカーのレシートを待ちます。永続化された成功レシートがある場合に限り、既存の準備調整が許可されます。すなわち、操作／フェーズとコンテナーに変更がないことを再検証し、以前の設定を復元して、失敗として終了するか、以前に要求されたキャンセルを確定します。recovery=reconciling には、元のワーカーの処理待ちが含まれる場合があります。レシートの欠落／無効、ワーカーの失敗またはタイムアウト、レシート取得前のホスト再起動、従来の監視なしの処理、置き換えの不確実性、データの所有権、およびオニオンの準備については、引き続き確認が必要です。プロセスやサービスが消失しても、処理完了の証明にはなりません。お客様は再試行する前に最終結果を待つ必要があります。デプロイの自動再試行、即時のビルド終了、データのロールバック、実行時の正常性保証は追加されません。

ライセンス

MIT — LICENSE を参照してください。

監視下での置き換え

Agent 0.6.9 以降：新たにサポートされる Linux/systemd のデプロイでは、承認済みコンテナの置き換え、起動チェック、ライフサイクルフック、ルート、通常の起動時復旧が、1 つの監視対象ワーカーにまとめられます。エージェントが再起動した場合、recovery=reconciling、step=reconciling_replacement の処理は元のワーカーを待機します。検証済みの永続的な最終レシートは、コンテナやフックを再実行せずに配信されます。以前のリリースが復元されたデプロイ失敗も対象です。レシートの欠落や無効化、ワーカーの消失またはタイムアウト、完了前のホスト再起動、旧式の監視対象外操作、データの所有権変更、オニオンのプロビジョニングには、引き続きサポートが必要です。プライベートジャーナルを保持し、キューを先に進めるために再試行しないでください。これにより、デプロイの自動再試行、データベースのロールバック、ゼロダウンタイムのトラフィック切り替えが追加されるわけではありません。次回のデプロイ前に、エージェントを明示的に更新してください。

Python のデプロイでは、python_pip、pyproject.toml、uv.lock とともに [email protected] を選択できます。Python 3.13 では、インストールはロックされ、本番環境専用で、編集不可です。公開 PyPI ソースのみを使用できます。カスタムの uv ワークスペース／インデックスを使用するには、Dockerfile が必要です。このレシピをサポートする MCP 0.34.0 以降とコントロールプレーンを使用してください。

PostgreSQL アプリケーション接続

impreza_prepare_service_binding は、同じプロジェクト環境とサーバーにあるイメージアプリケーション用の専用 PostgreSQL 接続を確認します。impreza_prepare_service_binding_removal は、正確な deployment_id と binding_id を指定して、削除または保留中のクリーンアップの再試行を確認します。保存済みのプランは impreza_get_service_binding_plan で読み取り、明示的な確認後にのみ、正確なダイジェストと confirm: true を指定して impreza_apply_service_binding_plan で適用してください。削除してもデータベースのデータは保持され、専用ログインは、その接続を使わない正常な置き換えが完了した後にのみ無効になります。受け付け済みとは、キューに登録されたことを意味し、完了が検証済みであることを意味しません。エージェント 0.6.13 以降と互換性のあるコントロールプレーンが必要です。

impreza_prepare_service_binding_rotation は、既存の接続に対する認証情報のローテーションを、deployment_id、binding_id、mode（rotate または abandon）を指定して確認します。ローテーションでは専用ログインを別の新しいログインに置き換え、ローテーション後の DATABASE_URL を使った正常な置き換えが完了した後にのみ、以前のログインを無効にします。データベースとそのデータは常に保持されます。起動に失敗した場合、現在の認証情報を使った以前のアプリケーションが引き続き稼働し、改めて確認を受けた再試行が必要です。以前のログインが無効化されたことを確認できなかった場合、ローテーションはクリーンアップ保留のままとなり、新たな rotate の確認で再試行します。abandon は未使用の候補認証情報を破棄し、現在の認証情報を保持します。クリーンアップだけが残っている状態では拒否されます。上記のとおり、返された確認結果は impreza_apply_service_binding_plan で適用してください。準備では何もキューに登録されず、認証情報も返されません。ローテーションには postgres-service-binding-rotation-v1 を通知するエージェントが必要です。古いエージェントはディスパッチを拒否し、失敗したジョブは、お客様にエージェントを明示的に更新するよう案内します。ID、設定、アプリケーションは保持されます。ローテーションには v2 プロトコルの接続が必要です。旧式の第 1 プロトコルの接続は引き継がれません。

パブリック HTTPS 診断

impreza_probe_deployment は deployment_id を受け取り、コントロールプレーンを通じて保存済みのパブリックホスト名を確認します。リダイレクトをたどったり、アプリケーションの認証情報を送信したりせずに、パブリック DNS の名前解決、TLS 検証、HTTPS HEAD のステータスを報告します。レスポンス本文の読み取りや依存関係の検証は行いません。アカウントあたり 30 秒ごとに 1 回実行できます。エージェントの更新は不要です。

イメージの昇格と環境

impreza_prepare_image_promotion、impreza_get_image_promotion、impreza_apply_image_promotion は、既存の宛先設定に対して、レジストリの正確なダイジェストをレビューします。適用には、返されたレビューダイジェストと明示的な確認が必要です。宛先の変数とデータは、そのアプリケーション内に保持されます。

プロジェクト／環境ツールは、明示的なコンポーネントの関連付けを使って、既存のアプリケーションを整理します。変数のコピー、ネットワーク接続の作成、ワークロードのデプロイは行いません。プロジェクト環境ガイドをご覧ください。

レビュー付きデプロイワークフロー

バージョン 0.38.0 では、環境設定の比較、トラフィック切り替えの準備／確認／適用、パスワード保護を任意で設定できる明示的なブランチプレビューが追加されました。比較では変数名のみが返され、値は返されません。トラフィック切り替えには、レビュー済みのダイジェストと確認が必要です。切り替え元は稼働したままになり、復旧を確認できない場合はオペレーターによる調整が必要です。保護されたプレビューの認証情報は一度だけ表示されます。 トラフィック切り替えと保護されたプレビューには、バージョン 0.6.16 以降のエージェントが必要です。既存サーバーの更新は、お客様から依頼があった場合にのみ行われます。データベースの支援付き復元は REST ワークフローです。プロジェクト環境とデプロイの安全性をご覧ください。

Basic Cloud VPS の管理

Basic Cloud VPS では、impreza_api_call を通じてステータスと割り当て済みリソースを確認でき、impreza_cloud_power を通じて起動、正常なシャットダウン、再起動を実行できます。impreza_list_services で取得した WHMCS サービス ID を使用してください。高度な Cloud インフラストラクチャツールは提供対象外となり、廃止された呼び出しは FEATURE_NOT_AVAILABLE を返します。それ以外のインフラストラクチャ変更については、Impreza サポートにお問い合わせください。注文とキャンセルには通常のアカウントワークフローが適用されます。登録済みエージェントを通じたアプリケーション管理は別の機能です。

設定、メトリクス、復旧（0.39.0）

エクスポート／準備／取得／適用ツールを使ってアプリケーション設定をレビューし、アプリごとのメトリクスとアラートルールを確認できます。また、バックアップの各パートをダウンロードし、PostgreSQL の復元をレビューして新しいデータベースに適用できます。レビューの適用には、そのダイジェストと明示的な確認が必要です。受け付けられた作業はキューに登録されますが、完了が確認されたことを意味するものではありません。カスタムデプロイツールと準備ツールでは、static_files と go_build もサポートされています。メトリクスと MariaDB バインディングには、バージョン 0.6.17 以降のエージェントが必要です。権限、例、制限については設定、メトリクス、復旧をご覧ください。サーバーは自動更新されません。

Tor 経由の分離されたランタイム（0.42.0）

カスタムイメージとソースのデプロイでは、impreza_deploy_custom と保存済みのデプロイ準備を通じて、tor_egress: true を指定して有効にできます。このオプションには、tor-egress-v1 を通知するエージェント、Docker Engine 28 以降、SOCKS5h 対応のアプリケーションが必要です。ランタイムには、直接のアウトバウンド接続へのフォールバックはありません。ソースのダウンロード、イメージのプル、ビルドでは、サーバーの通常のネットワーク接続が維持されます。カタログからのインストール、インポートしたマニフェスト、外部サービスのバインディングはサポートされていません。利用可能性と確認方法については、Tor ランタイムガイドをご覧ください。このオプションは、MCP クライアント自体の接続に Tor を使うことや、インバウンドの onion アドレスを公開することとは別の機能です。

管轄区域のフェイルオーバーとより安全な読み取り（0.48.0）

レビュー付きコールドフェイルオーバー。 14 個のツールを使い、レビューを確認したうえで、アプリを自分が所有する別の国の別サーバーにあるコールドスタンバイへ移行できます。レビュー対象のアプリは、カタログにある Memos 0.31.0 と、0.48.1 以降の Uptime Kuma 2.5.5 です。impreza_deploy_catalog_app に standby: true を指定して、ドメインも onion も設定せずにスタンバイを作成します。スタンバイには公開ルートが設定されていない状態で起動します。次に、ペアリングして内容を読み取ります（impreza_pair_failover_standby、impreza_get_failover_standby）。外部サーバーの場合は、まず impreza_declare_external_failover_country で国を申告します（Impreza による検証はなく、申告するのはお客様です。管理対象サーバーでは国が報告されます）。バックアップ／復元／再デプロイの正確な手順を確認し（impreza_confirm_failover_sync）、レビューを準備、読み取り、適用します（impreza_prepare_failover、impreza_get_failover、impreza_apply_failover。移行先の有効化を再試行する必要がある場合は impreza_retry_failover_activation も使用します）。

検証済みのフェイルオーバー後は、impreza_prepare_failback、impreza_get_failback、impreza_apply_failback を使って旧ホストを解放し、ペアを反転できます。旧プライマリがコールドスタンバイになり、トラフィックは移動しません。トラフィックを戻すには、通常のバックアップ、復元、同期の確認、レビュー付きフェイルオーバーを行います。impreza_set_failover_drill_policy、impreza_run_failover_drill、impreza_get_failover_drill を使うと、必要に応じて、または 60～10080 分ごとに、プラットフォームが実行するコールドコピーでスタンバイを更新し、各手順にかかった時間を記録できます。

移行対象：管理ゾーンのホスト名、またはシール済みエクスポートを通じた公開 onion アドレスです。カスタムドメイン、プライベート onion サービス、データベースのバインディング、専用サーバーには対応していません。適用するとソースが停止し、トラフィックが中断したり、復元したバックアップ以降に行われた書き込みが失われたりする可能性があります。ソース、移行先、バックアップの経過時間をユーザーと確認してから、正確な cutover_id（または failback_id）、review_digest、confirm: true を渡してください。受け付けは非同期です。検証済みになるか、対応可能なエラーが報告されるまでレビューを読み取ってください。API でフェイルオーバーが有効になっていない場合、これらのツールは API の 404 を返します。ホステッドコネクターには、制限のないアカウント認証情報が必要です。ガイド：管轄区域のフェイルオーバー。

0.48.0 のその他の変更：

• impreza_vps_resize_recommendation：エージェントが報告する継続的な負荷に基づいて、構成可能な VPS に CPU、メモリ、ディスクの追加が必要かどうかを判断します。
• impreza_get_host_inventory は、include_ssh_fingerprints: true を渡さない限り、SSH ホストキーのフィンガープリントを省略します。
• API エラーは code と next_steps を含む structuredContent として返されます。
• npx -y impreza-mcp login --code <code> を実行すると、クライアントエリアで取得したワンタイムコードを使ってローカルサーバーをペアリングできます（ローカル CLI のペアリングを参照）。
• 公開手順書では、impreza_doctor と impreza_get_logs を使ってデプロイの失敗を診断します。

アカウント概要、プレイブック、安全性の高い運用（0.47.0）

新しいツールが12個、プロンプトが5個追加されました。

• アカウント概要： impreza_get_account_overview は、1回の読み取り専用呼び出しでアカウントの状況をアシスタントに伝えます。サーバー、アプリと環境、ドメイン、未解決のアラート、最近のデプロイ失敗、推奨される次のアクションを確認できます。一部のリソースに限定された認証情報では、各セクションにその範囲の情報だけが表示されます。
• プロンプトとしてのプレイブック： prompts/list では、次の5つの手順ガイドを利用できます。 impreza_publish_git、impreza_change_domain、 impreza_diagnose_deployment、impreza_restore_backup、および impreza_update_agent です。権限が付与されることはありません。すべての手順は引き続きツールを介して実行され、確認が必要です。
• サーバーのエージェントの一時停止と再開： impreza_pause_agent は、新しいコマンドのディスパッチを停止し、そのサーバーに限定された認証情報を一時停止します。 impreza_resume_agent は、それらを再開します。すでにディスパッチされた処理は完了する場合があります。 どちらの操作にも、manage スコープと confirm: true を持つ、リソース制限のない認証情報が必要です。
• 人間の承認を必要とするホストプラン： impreza_host_permissions、 impreza_prepare_host_plan、impreza_get_host_plan、および impreza_apply_host_plan を使って、VPS の再インストールを準備できます。実行前に、担当者がダッシュボードで正確なサーバー、テンプレート、ダイジェスト、有効期限を確認して承認します。AI が自分のプランを承認することはできません。
• ダウンタイムなしの再デプロイ： impreza_get_zero_downtime は、アプリが対象となるかどうかと、対象外となるすべての理由を説明します。impreza_set_zero_downtime は、カスタムアプリでこの機能を有効にし、レディネスチェックを設定します。agent 0.6.27 以降が必要です。
• 読み取り： impreza_get_shield（Shield ポリシーと過去24時間の WAF 検出結果。訪問者の識別情報は含まれません）、impreza_privileged_audit（アカウント上の特権操作に関する入場監査）、および impreza_get_host_inventory（許可リストに登録されたホスト情報。agent 0.6.28 が必要です。まだリリースされていないことも通知されます）。
• 構造化出力： 読み取りツールは outputSchema を宣言し、structuredContent を返します。一度だけ表示されるシークレットはテキストにのみ含まれ、構造化された結果には含まれません。

ローカル版とホスト版の機能差解消（0.46.0）

ローカルパッケージに、これまでホスト型コネクターだけにあった16個のツールが追加されました。

• プロジェクトと環境：impreza_rename_project、impreza_delete_project、 impreza_rename_environment、impreza_delete_environment；
• 変数グループ：impreza_get_variable_group、impreza_set_variable_group；
• 設定の昇格：impreza_prepare_config_promotion、 impreza_get_config_promotion、impreza_apply_config_promotion；
• 順序指定の環境デプロイ：impreza_deploy_environment、 impreza_get_environment_deploy、impreza_list_environment_deploys；
• エージェントの更新：impreza_get_update_policy、impreza_set_update_policy、および impreza_request_agent_update；
• Shield：impreza_set_shield。

ツールのアノテーション（読み取り専用、破壊的、冪等）は、ホスト型コネクターと一致するようになりました。破壊的なツールを confirm が指定されていない、または false の状態で呼び出すと、リクエストを送信する前に拒否されます。

PostgreSQL の特定時点への復旧（0.45.0）

ステータス、設定、復旧ドリル、およびレビュー済みの UTC 復旧ポイントの準備・取得・適用を行う6つのツールが追加されました：impreza_get_pitr、impreza_configure_pitr、 impreza_drill_pitr、impreza_prepare_pitr_restore、 impreza_get_pitr_restore、および impreza_apply_pitr_restore です。ステータスの取得には read スコープ、変更には deploy スコープが必要です。物理的な PostgreSQL の復旧は、プロバイダー上の複数のバインディングに及ぶ場合があるため、ホスト型コネクターにはリソース制限のない認証情報が必要です。

WAL とベースバックアップは、アカウントのストレージを消費します。失敗が6回連続すると、自動処理は一時停止し、原因を修正して設定を再度保存するまで再開されません。無効化すると保護は停止しますが、保存済みのオブジェクトは保持されます。復旧にはレビューのダイジェストと confirm: true が必要です。新しいデータベースが作成され、稼働中のアプリケーションの接続先が切り替わることはありません。レビューをポーリングし、レシートに verified または failed と表示されるまで確認してください。受け付けられただけでは、復旧に成功したことにはなりません。

スケジュールタスク（0.45.0）

impreza_create_task はアプリにスケジュールタスクを作成し、impreza_update_task は既存のタスクを変更します（省略したフィールドは現在の値が維持されるため、 enabled=false にすると、スケジュールや履歴を失わずにタスクを一時停止できます）。これは ホステッドコネクターと同じ動作です。これらのツールは、削除された impreza_schedule_task を置き換えるものです。引き続きこれを呼び出しているクライアントやプロンプトを更新してください。impreza_list_tasks、 impreza_run_task、impreza_delete_task に変更はありません。

VPS のサイズ変更（0.44.0）

impreza_vps_resize を使うと、構成可能な VPS の vCPU、メモリ、またはディスクを増やせます。まず impreza_api_call で /services/{id}/resize/quote を呼び出し、新しいサイズを query として渡して料金を確認してください。この呼び出しは、今日請求される按分額（課金 システム独自の金額）、VPS の更新時の料金、および残高で支払い可能かどうかを返します。次に、 同じサイズを指定し、max_amount に due_today の値を設定して impreza_vps_resize を呼び出してください。これにより、その間に価格が変わっていた場合は請求せずに処理を拒否できます。 サイズは増やすことのみ可能です。ディスクはすぐに拡張されます。新しい vCPU 数とメモリは、impreza_vps_power の action=reboot で VPS を再起動すると有効になります（サーバー内から再起動した場合は、以前の値が維持されます）。詳しくは VPS のサイズ変更をご覧ください。

構成可能な VPS（0.43.0）

VPS は、ロケーション、オペレーティングシステム、vCPU、メモリ、SSD ディスクを選択できる、1 つの構成可能な製品です。impreza_vps_offer は、各請求サイクルについて、すべての選択肢と単位あたりの料金をアカウントの通貨で一覧表示します。構成全体（billing_cycle、location、os、cpu_cores、memory_gb、 disk_gb）を指定すると、正確な料金、残高で支払い可能かどうか、現在そのロケーションに空きがあるかどうかを返します。impreza_order_vps は、product_id を省略してその構成を注文します。Tor Hosting などの固定プランは、引き続き product_id で注文します。請求される料金は、見積もり時の料金です。詳しくは VPS の注文をご覧ください。

プライベートな onion プレビューと保持された ID（0.42.0）

プレビューの作成では private: true をサポートしています。任意で 1 つ以上の onion_clients を指定できます。指定するレビュー担当者には、名前と X25519 公開鍵が必要です。クライアントを指定しない場合は、レビュー担当者の鍵ペアが生成され、秘密鍵は一度だけ表示されます。このモードには onion-private-preview-v1 を備えたエージェント 0.6.20 が必要です。最初の onion 公開前にレビュー担当者の認証が設定されます。繰り返しデプロイしても、それ以降に行われたアクセス取り消しは維持されます。このオプションを、パスワード保護された HTTPS プレビューと併用しないでください。

impreza_purge_onion_key では、正確な古い onion アドレスと明示的な確認が必要です。作業がキューに入っただけでは削除の証明になりません。完了した結果を確認してください。有効なアドレスは拒否されます。パージすると、そのサーバー上に保持されたコピーが削除されますが、別の場所にあるエクスポートやバックアップは残ります。未インストールのアプリケーションの予約を解除しても、鍵のマテリアルは削除されません。

権限、顧客向け更新手順、サポートされる制限については、 onion ガイドをご覧ください。

依存関係のバージョン

パッケージマニフェストでは、各直接ランタイム依存関係のバージョンを正確に固定しています：@modelcontextprotocol/sdk 1.29.0、 tar 7.5.22、zod 3.25.76。ソースからのビルドでは、テスト済みの依存関係ツリーに package-lock.json を使用します。利用者が新規インストールする際には、推移的依存関係が変わる可能性があります。依存関係を更新する場合は、リリース前にパッケージを再ビルドし、クリーンインストールをテストして、インストールされた依存関係ツリーを確認する必要があります。