deploy-to-hosting

ホスティングへのデプロイ

ディスク上または Git リポジトリにすでに存在するプロジェクトを、Hostinger のウェブサイトにデプロイします。プロンプトから新しいサイト（デザイン、ストア、ブログ）を作成する場合は hostinger-headless スキルを使用します。このスキルでは、コードをそのまま扱います。

操作の呼び出し

• 各操作を初めて呼び出す前に、search が返す inputSchema を読み取ってください。以下の名前が不明な操作として拒否された場合は、その手順で行う内容を search してください（例：「deploy static」）。
• 読み取りは multi-execute でまとめてください。値は $steps.<i>.<path> で手順間を受け渡せます。バッチで連続実行できるのは、同じサーバー上の操作のみです。Hostinger Connector は hosting、wordpress、agency-hosting を個別のサーバーとして実行します。
• デプロイのたびに、ウェブサイトの現在のコンテンツはすべて上書きされます。すでにコンテンツがあるサイトに初めてデプロイする前に、対象ドメインをユーザーに確認してください。

1. 対象のウェブサイトを選択する

• プロジェクト内に .hostinger/site.json がある場合は、そこにある domain と username（または website_uid）を再利用します。
• それ以外の場合は、hosting_websites_list（Shared と Cloud。部分一致で検索し、完全一致する項目を選択）と agency-hosting_websites_list-plan（Agency。details.uid を保持）でドメインを検索します。
• まだウェブサイトがない場合：
  • Shared と Cloud：ドメイン（ユーザー所有のもの、または hosting_domains_generate-free-subdomain で取得したもの）と、hosting_orders_list の order_id を指定して、hosting_websites_create を呼び出します。新しいプランで最初のウェブサイトを作成する場合に限り、datacenter_code が必要です（hosting_datacenters_list の最初の項目を使用）。セットアップが完了するまで、domain を指定して hosting_websites_list-setups を 10～15 秒ごとにポーリングしてください。その前にアップロードやデプロイを行うと、404 または 409 が返されます。
  • Agency：flavor: "php-fpm" を指定して（ビルド済みフロントエンドの場合は type: "node-static" も指定して）、agency-hosting_website-setups_create を呼び出します。settings.php.version には agency-hosting_php_list-versions-for-order の値を、datacenter_code には agency-hosting_datacenters_list の値を指定します。agency-hosting_website-setups_status が completed を返すまでポーリングしてください。戻り値には website_uid が含まれます。
• Node.js アプリは Business および Cloud プランで実行できます（hosting_orders_list の hostinger_business_*、cloud_*）。それ以外のプランでは、ローカルでビルドし、出力を静的サイトとしてデプロイしてください。

2. デプロイ方法を選択する

Shared および Cloud、ローカルの hostinger-api-mcp サーバーの場合： 1 回の操作ですべてをデプロイできます。hosting_deploy に domain と、path（このマシン上のディレクトリ）または git: { repository: "owner/name", branch } のいずれかを指定します。ディレクトリを指定すると、プロジェクトの種類を検出し、自動でパッケージ化します（node_modules、.git、.env ファイルは除外し、.env ファイルは skippedFiles として一覧表示されるため、hosting_nodejs_replace-environment-variables で値を設定できます。.gitignore は読み取らないため、ビルド出力はディレクトリの外に置いてください）。その後、アップロード、ビルド、Git のセットアップを行います。ディレクトリをアーカイブしたり、アップロードやビルドの操作を手動で呼び出したりしないでください。

プロジェクト	hosting_deploy による処理
通常の HTML/CSS/JS、またはフレームワークの静的ビルド出力	static — そのまま展開
ビルドスクリプト、起動スクリプト、またはサーバー依存関係を含む package.json（Next.js、Nuxt、Express、Vite…）	nodejs — ビルドを開始し、buildUuid を返す
ビルド手順のない PHP コード	static
WordPress プラグインフォルダー（Plugin Name: ヘッダーを含む）またはテーマフォルダー（style.css に Theme Name: を含む）	wordpress-plugin / wordpress-theme。activate: true を指定するとテーマが有効になります
別の場所にある WordPress サイト全体	databaseDump を指定した wordpress-site — migrate-to-hosting スキルを参照してください

• 検出結果を上書きするには type を指定します。アーカイブの場合（アーカイブの内容は検査できません）と、ディレクトリが複数の WordPress タイプに該当し、hosting_deploy が曖昧として拒否する場合は必須です。
• Node.js のビルド設定はプロジェクトから取得されます。検出ではフレームワークとビルドスクリプトが判断されます。誤っている場合は appType、outputDirectory、buildScript、entryFile、nodeVersion（既定値は 22）、rootDirectory、packageManager を設定してください。TypeScript などのコンパイルが必要なサーバーアプリでは、ビルド後のファイル（例：dist/server.js）を entryFile に必ず設定してください。検出ではルートレベルのファイルしか推測されず、設定しないとビルドは「Entry file not found」で失敗します。エントリーファイルは express、fastify、hono、react-router などではルートディレクトリからの相対パス、nest、nuxt、nitro、astro、svelte-kit では出力ディレクトリからの相対パスです（dist/main.js ではなく main.js）。Next.js では無視されます。フレームワークごとの値は、Hostinger のドキュメントの Node.js（Supported Frameworks、Build Settings）を参照してください。
• Static、PHP、プラグイン、テーマのデプロイは、呼び出しが返るとすぐに公開されます。WordPress サイトのインポートは開始されるだけ（status: import_started）で、数分後に展開が完了します。それまでは完了したと報告したり、検証したりしないでください。Node.js のビルドはサーバー上で実行されます。手順 3 を参照してください。

Agency： サイトのタイプによって決まります（agency-hosting_websites_get）。node-static として作成されたサイトでは agency-hosting_deploy-node-static-website を使用し、プロジェクトにビルドがある場合は実行します。それ以外のサイトでは agency-hosting_deploy-php-application を使用し、アーカイブをそのまま展開します。アーカイブを同期的にデプロイするため、呼び出しが返るとサイトは公開されています。Agency サイトの WordPress プラグインとテーマは、wp-admin からインストールします。

Agency 用のアーカイブ（name_YYYYMMDD_HHMMSS.zip という名前にします）と、自分で作成するアーカイブのルール：

• Static： まずローカルでビルドします。index.html はフォルダー内ではなく、アーカイブのルートに置く必要があります：cd dist && zip -r ../site_20260101_120000.zip .
• Node.js ソース： node_modules/、ビルド出力（dist/、.next/、build/）、.env*、.gitignore に一致するファイルは含めません。最大 50 MB です。git archive --format=zip -o app_20260101_120000.zip HEAD を実行すると、コミット済みのファイルだけが正確に含まれます。未コミットの変更は含まれないことを伝えてください。

hosting_deploy と agency-hosting_deploy-* の操作は、このマシン上のファイルを読み取るため、ファイルがあるのはローカルサーバーだけです。ホストされているサーバー（mcp.hostinger.com）では search でファイルが見つかりません。以下のように、ファイルを自分でアップロードしてください。

ローカルのデプロイ操作を使わない場合（ホスト型サーバー。Agency のみローカルサーバー上）

1. アップロード認証情報を取得します：hosting_files_generate-upload-url（username、domain）、Agency の場合は agency-hosting_files_generate-upload-url（website_uid）。どちらも url、auth_key、rest_auth_key を返します。これらは API トークンの代わりにアップロードの認証に使用します。
2. TUS を使って各ファイルをアップロードします。DEST はウェブサイトのストレージ内でのパスです：

SIZE=$(wc -c < "$FILE" | tr -d ' ')
curl -sS -X POST "$URL/$DEST?override=true" -H "X-Auth: $AUTH_KEY" -H "X-Auth-Rest: $REST_AUTH_KEY" -H "Tus-Resumable: 1.0.0" -H "Upload-Length: $SIZE" -H "Upload-Offset: 0"
curl -sS -X PATCH "$URL/$DEST?override=true" -H "X-Auth: $AUTH_KEY" -H "X-Auth-Rest: $REST_AUTH_KEY" -H "Tus-Resumable: 1.0.0" -H "Content-Type: application/offset+octet-stream" -H "Upload-Offset: 0" --data-binary "@$FILE"

最初の呼び出しは 201 を返し、2 回目はファイルサイズと等しい Upload-Offset ヘッダーとともに 204 を返します。override=true を指定すると、安全に再試行できます。 3. アップロードしたファイルからデプロイします（RANDOM8 は新しい 8 文字の文字列です。例：$(LC_ALL=C tr -dc 'a-z0-9' < /dev/urandom | head -c 8)）：

プロジェクト	DEST	次の操作
静的サイトまたは PHP	site.zip	hosting_websites_deploy-static-site-archive を archive_path: "site.zip" で実行
Node.js	app.zip	hosting_nodejs_build-settings-from-archive を archive_path: "app.zip" で実行し、その後、それらの設定と source_type: "archive"、source_options.archive_path: "app.zip" を指定して hosting_nodejs_start-build を実行
WordPress プラグイン	各ファイルを wp-content/plugins/SLUG-RANDOM8/<プラグイン内のパス> として配置	slug と plugin_path: "SLUG-RANDOM8" を指定して wordpress_plugins_deploy を実行
WordPress テーマ	各ファイルを wp-content/themes/SLUG-RANDOM8/<テーマ内のパス> として配置	slug、theme_path: "SLUG-RANDOM8"、任意の is_activated を指定して wordpress_themes_deploy を実行
Agency、そのまま展開	.h5g/site.zip	archive_name: "site.zip" を指定して agency-hosting_files_import-website-from-archive を実行
Agency の node-static	.h5g/RANDOM8/app.zip	ファイルではなくディレクトリを指定する archive_path: ".h5g/RANDOM8" で agency-hosting_websites_build-nodejs-assets を実行

3. Node.js ビルド

hosting_deploy はすぐに buildUuid を返します。ビルドはサーバー上で実行され、完了まで数分かかります。hosting_get-deployment（domain、任意で buildUuid。デフォルトでは最新のビルド）で追跡し、build.state が completed または failed になるまで 10～20 秒ごとにポーリングします。ビルド、そのログ、保存済みのビルド設定が返されます。新しい出力のみを読み取るには、前回の logs.lines を fromLine として渡します。

• ビルド失敗：レスポンスにはすでに analysis が含まれています（ビルドごとに 1 回取得されます。API の呼び出し上限は 1 分あたり 5 回です）。
• 検出が正しくない場合（フレームワーク、output_directory、またはコンパイル済みアプリの dist/server.js のようなビルド出力内のエントリーファイル）：appType、outputDirectory、buildScript、または entryFile を設定して再度デプロイします。アーカイブのデプロイでは設定をリクエストとともに送信し、保存済みの設定は変更しません。Git のデプロイではこれらの値も保存されるため、以降のプッシュでは保存済みの値を使ってビルドされます。

hosting_deploy または hosting_get-deployment がないホスト型サーバーでは：

• 以下のアップロード手順の後、ビルドを開始し、hosting_nodejs_list-builds と hosting_nodejs_build（uuid で指定）で追跡します。10～20 秒ごとにポーリングします。
• ビルド失敗：ビルドごとに 1 回 hosting_nodejs_analyse-failed-build を実行し（1 分あたり 5 回）、分析結果が空の場合は hosting_nodejs_build-logs を実行します。
• 検出が正しくない場合：明示的な値と source_type: "archive" を指定して hosting_nodejs_start-build を実行し、source_options.archive_path にはドキュメントルート内のアーカイブのファイル名を設定します（hosting_files_list-website-and-directories でファイルの存在を確認してください）。hosting_nodejs_update-build-settings で同じ値を保存します。
• ビルドを開始する前に検出された設定を確認するには、hosting_files_generate-upload-url でアーカイブをアップロードします（TUS の手順は説明に記載されています）。その後、hosting_nodejs_build-settings-from-archive を実行します。

4. Git からの自動デプロイ

ローカルサーバーでは、hosting_deploy に git: { repository: "owner/name", branch } を指定すると、すべて実行されます。リポジトリにアクセスできる Git のインストールを検出し、指定した type としてデプロイします。サイトですでに Node.js アプリが実行されている場合（または appType などの Node.js 設定を指定する場合）を除き、必ず type: "static" または "nodejs" を指定してください。新しいサイトは Node.js として検出されず、Node.js リポジトリを静的サイトとしてデプロイすると、ソースが公開されます。その後の動作は次のとおりです。

• PHP および静的サイト： 自動デプロイ設定を保存し、ブランチをすぐにデプロイします。その後はプッシュのたびに再度デプロイします。
• Node.js サイト： 保存済みのビルド設定でブランチのビルドを開始します。以降のプッシュでも同じ方法でビルドします。Git デプロイでは検出できる情報がないため、設定が保存されていない場合は package.json の engines にある appType と nodeVersion に加え、アプリにビルド手順がある場合は outputDirectory と buildScript を指定してください。これらは以降のプッシュ用に保存されます。

有効なインストールがない場合は処理を停止し、その旨を通知します。ユーザーは hPanel の「Websites → Manage → Advanced → Git」から GitHub または GitLab に一度接続します。この手順に使える API はありません。hosting_get-deployment で確認します。このツールは保存済みの gitAutoDeployment を返します。

ホスティングサーバーでは、手動で次の手順を実行します。

1. hosting_git_list-installations を実行します。有効なインストール（active）がない場合は（status: "pending" と "suspended" も確認してください）、上記のとおりユーザーに hPanel から GitHub または GitLab へ一度接続してもらいます。
2. インストールの uuid を指定して hosting_git_list-installation-repositories を実行すると、owner、name、default_branch が返されます（1 分あたり 10 回まで）。
3. installation_uuid、owner、repository、branch と任意の directory を指定して hosting_git_update-auto-deployment-settings を実行します。
   • PHP および静的サイトはブランチをすぐにデプロイし、その後はプッシュのたびに再度デプロイします。
   • Node.js サイトは保存時にクローンを作成しません。hosting_nodejs_start-build に source_type: "git" と同じ source_options を指定して、最初のビルドを開始します。以降のプッシュでは保存済みの設定でビルドされるため、hosting_nodejs_update-build-settings が正しく設定されていることを確認してください。
4. hosting_git_auto-deployment-settings で確認します。

Agency Plan のサイトでは Git 操作を利用できません。アーカイブをデプロイしてください。

5. 環境変数（Node.js）

hosting_nodejs_replace-environment-variables は環境変数をすべて置き換えます。送信しなかった項目は削除されます。

1. hosting_nodejs_list-environment-variables で現在のキーを確認します。値は ******** として返されます。これらを送り返さないでください。
2. 現在のすべてのキーと新しいキーを含む完全な環境変数セットを作成し、プロジェクトの .env またはユーザーから実際の値を取得します。既存のキーの実際の値が不明な場合は、ユーザーに確認してください。削除してはいけません。
3. まとめて一度に送信します。アプリが再起動します。ビルド時に値が埋め込まれる環境変数（Next.js の NEXT_PUBLIC_*、Vite の VITE_*）には、新たに hosting_nodejs_start-build を実行する必要があります。

キーに使用できるのは大文字、数字、アンダースコアです。.env ファイルをコミットしたり、シークレット値をユーザーに繰り返し伝えたりしないでください。

6. データベース

• Node.js： hosting_databases_setup-website は MySQL データベースを作成し、DB_HOST、DB_PORT、DB_NAME、DB_USER、DB_PASSWORD、DATABASE_URL を環境変数に書き込んだ後、アプリを再起動します。パスワードは自動生成され、返されません。これらのキーがすでに存在する場合は 422 エラーになります。その場合は、先に手順 5 の置き換え操作でキーを削除してください。
• PHP： name、user、強力なパスワードを生成して指定した password、website_domain を使って hosting_databases_create を実行します。接頭辞付きの完全な名前は hosting_databases_list で確認できます。アプリは Git の対象外となるサーバー上の設定ファイルから認証情報を読み込み、localhost または 127.0.0.1 に接続します。
• Agency： agency-hosting_databases_create-website を実行します。アプリは localhost に接続します。
• hosting_databases_list から返される srvNNNN.hstgr.io ホストは、Hostinger の外部からの接続にのみ使用します。デプロイするアプリには決して設定しないでください。

7. 検証して記録する

curl -s -o /dev/null -w "%{http_code}\n" https://DOMAIN/
curl -s https://DOMAIN/ | grep -o "TEXT THE PROJECT RENDERS"

200だけではプレースホルダーページの可能性があります。実際のコピーが表示されることを確認してください。新しいサイトでは、一時的にデフォルトページが表示される場合があります。その場合は、デプロイに失敗したと判断する前に、hosting_cache_clear-websiteでキャッシュをクリアしてから再試行してください。

プロジェクトに.hostinger/site.jsonを書き込み、以降の実行で対象を再利用できるようにします。形式は{ "domain", "username" or "website_uid", "type": "static" | "nodejs" | "php" }とし、すでに存在するフィールドは保持してください。