deploy-to-hosting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Deploy to hosting

部署到托管服务

Ship a project that already exists — on disk or in a Git repository — to a Hostinger website. Building a new site from a prompt (design, store, blog) is the

hostinger-headless

skill; this one takes code as it is.

将已经存在的项目——位于磁盘上或 Git 仓库中——发布到 Hostinger 网站。通过提示词（设计、商店、博客）构建新网站应使用

hostinger-headless

skill；本 skill 直接使用现有代码。

Calling the operations

调用操作

Read the
```
inputSchema
```
that
```
search
```
returns before the first call of each operation. If a name below is rejected as unknown,
```
search
```
for what the step does (e.g. "deploy static").
Batch reads with
```
multi-execute
```
; values pass between steps as
```
$steps.<i>.<path>
```
. Batches chain operations from one server only — the Hostinger Connector runs
```
hosting
```
,
```
wordpress
```
and
```
agency-hosting
```
as separate servers.
Every deploy overwrites the website's current contents. Confirm the target domain with the user before the first deploy to a site that already has content.

在首次调用每个操作前，读取
```
search
```
返回的
```
inputSchema
```
。如果下述名称被判定为未知，请使用
```
search
```
搜索该步骤的功能（例如 "deploy static"）。
使用
```
multi-execute
```
批量读取；值通过
```
$steps.<i>.<path>
```
在步骤之间传递。一个批次只能串联来自同一服务器的操作——Hostinger Connector 将
```
hosting
```
、
```
wordpress
```
和
```
agency-hosting
```
作为独立服务器运行。
每次部署都会覆盖网站当前的内容。首次部署到已有内容的网站前，必须向用户确认目标域名。

1. Pick the target website

1. 选择目标网站

.hostinger/site.json

in the project: reuse its

domain

and

username

(or

website_uid

Otherwise look the domain up with
```
hosting_websites_list
```
(Shared and Cloud; substring match — take the exact entry) and
```
agency-hosting_websites_list-plan
```
(Agency; keep
```
details.uid
```
).

No website yet:

Shared and Cloud: take a domain (the user's own, or
```
hosting_domains_generate-free-subdomain
```
) and an
```
order_id
```
from
```
hosting_orders_list
```
, then
```
hosting_websites_create
```
.
```
datacenter_code
```
is needed only for the first website on a new plan (first entry of
```
hosting_datacenters_list
```
). Poll
```
hosting_websites_list-setups
```
with
```
domain
```
every 10–15 s until
```
status: completed
```
— uploads and deploys return 404 or 409 before that.

Agency:

agency-hosting_website-setups_create

with

flavor: "php-fpm"

(plus

type: "node-static"

for built frontends),

settings.php.version

from

agency-hosting_php_list-versions-for-order

and

datacenter_code

from

agency-hosting_datacenters_list

. Poll

agency-hosting_website-setups_status

until

completed

; it returns the

website_uid

Node.js apps run on Business and Cloud plans (
```
hostinger_business_*
```
,
```
cloud_*
```
in
```
hosting_orders_list
```
). On other plans, build locally and deploy the output as a static site.

项目中的

.hostinger/site.json

：复用其中的

domain

和

username

（或

website_uid

）。

否则，使用
```
hosting_websites_list
```
（Shared 和 Cloud；子字符串匹配——选择完全匹配的条目）以及
```
agency-hosting_websites_list-plan
```
（Agency；保留
```
details.uid
```
）查找域名。

尚无网站：

Shared 和 Cloud：从
```
hosting_orders_list
```
获取一个域名（用户自有域名，或通过
```
hosting_domains_generate-free-subdomain
```
生成）和一个
```
order_id
```
，然后调用
```
hosting_websites_create
```
。仅当新套餐中的首个网站需要
```
datacenter_code
```
（即
```
hosting_datacenters_list
```
的第一项）。使用
```
domain
```
每 10–15 秒轮询
```
hosting_websites_list-setups
```
，直至
```
status: completed
```
——在此之前，上传和部署操作会返回 404 或 409。

Agency：调用

agency-hosting_website-setups_create

并设置

flavor: "php-fpm"

（对于已构建的前端项目，还需设置

type: "node-static"

），

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
```
中为
```
hosting_business_*
```
、
```
cloud_*
```
）。在其他套餐上，请在本地构建并将产物作为静态站点部署。

2. Choose the deploy

2. 选择部署方式

Shared and Cloud, on the local
hostinger-api-mcp
server: one operation does every deploy —

hosting_deploy

with

domain

and either

path

(a directory on this machine) or

git: { repository: "owner/name", branch }

. Given a directory it detects what the project is, packs it itself (it skips

node_modules

.git

and

.env

files, listing the

.env

ones as

skippedFiles

so you can set their values with

hosting_nodejs_replace-environment-variables

; it does not read

.gitignore

, so keep build output out of the directory) and does the upload, build and Git setup. Do not archive the directory or call upload and build operations by hand.

Project	`hosting_deploy` treats it as
Plain HTML/CSS/JS, or a framework's static build output	`static` — extracts as-is
`package.json` with a build script, a start script or a server dependency (Next.js, Nuxt, Express, Vite…)	`nodejs` — starts a build, returns `buildUuid`
PHP code, no build step	`static`
WordPress plugin folder (a `Plugin Name:` header) or theme folder ( `Theme Name:` in `style.css` )	`wordpress-plugin` / `wordpress-theme` ; `activate: true` activates a theme
A whole WordPress site from elsewhere	`wordpress-site` , with `databaseDump` — see the `migrate-to-hosting` skill

Pass
```
type
```
to override detection. It is required for an archive (an archive cannot be inspected) and when a directory matches more than one WordPress type, which
```
hosting_deploy
```
rejects as ambiguous.
Node.js build settings come from the project; detection covers the framework and the build script. Set
```
appType
```
,
```
outputDirectory
```
,
```
buildScript
```
,
```
entryFile
```
,
```
nodeVersion
```
(default 22),
```
rootDirectory
```
or
```
packageManager
```
when it is wrong. A TypeScript or other compiled server app always needs
```
entryFile
```
set to the built file (for example
```
dist/server.js
```
): detection only guesses a root-level file, and the build fails with "Entry file not found". The entry file is relative to the root directory for express, fastify, hono, react-router and other, and to the output directory for nest, nuxt, nitro, astro and svelte-kit (
```
main.js
```
, not
```
dist/main.js
```
); Next.js ignores it. Per-framework values are in the Hostinger docs under Node.js (Supported Frameworks, Build Settings).
Static, PHP, plugin and theme deploys are live when the call returns. A WordPress site import only starts (
```
status: import_started
```
) and finishes extracting a few minutes later; do not report it complete or verify it before then. Node.js builds run on the server: see step 3.

Agency: the website's type decides (

agency-hosting_websites_get

): sites created as

node-static

take

agency-hosting_deploy-node-static-website

, which runs the build when the project has one; every other site takes

agency-hosting_deploy-php-application

, which extracts the archive as-is. They deploy archives, synchronously: the site is live when the call returns. WordPress plugins and themes on Agency sites are installed from wp-admin.

Archive rules for Agency (name archives

name_YYYYMMDD_HHMMSS.zip

) and for archives you build yourself:

Static: build locally first.
```
index.html
```
must be at the archive root, not inside a folder:
```
cd dist && zip -r ../site_20260101_120000.zip .
```
Node.js source: no
```
node_modules/
```
, no build output (
```
dist/
```
,
```
.next/
```
,
```
build/
```
), no
```
.env*
```
, nothing matched by
```
.gitignore
```
; 50 MB at most.
```
git archive --format=zip -o app_20260101_120000.zip HEAD
```
produces exactly the committed files — mention that uncommitted changes are left out.

hosting_deploy

and the

agency-hosting_deploy-*

operations read files from this machine, so only the local server has them. On the hosted server (

mcp.hostinger.com

)

search

does not find them — upload the files yourself as below.

Shared 和 Cloud，在本地
hostinger-api-mcp
服务器上：一个操作即可完成所有部署——

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 站点	`wordpress-site` ，配合 `databaseDump` ——参见 `migrate-to-hosting` skill

传入
```
type
```
可以覆盖检测结果。对于压缩包（无法检查其内容），以及一个目录同时匹配多种 WordPress 类型的情况，必须传入
```
type
```
；后一种情况会被
```
hosting_deploy
```
判定为歧义并拒绝。
Node.js 构建设置来自项目；检测范围涵盖框架和构建脚本。检测结果不正确时，请设置
```
appType
```
、
```
outputDirectory
```
、
```
buildScript
```
、
```
entryFile
```
、
```
nodeVersion
```
（默认 22）、
```
rootDirectory
```
或
```
packageManager
```
。TypeScript 或其他编译型服务器应用始终需要将
```
entryFile
```
设置为构建后的文件（例如
```
dist/server.js
```
）：检测只会猜测根目录下的文件，且构建会因 "Entry file not found" 而失败。对于 express、fastify、hono、react-router 等，入口文件相对于根目录；对于 nest、nuxt、nitro、astro 和 svelte-kit，则相对于输出目录（
```
main.js
```
，而不是
```
dist/main.js
```
）；Next.js 会忽略该设置。各框架对应的值位于 Hostinger 文档的 Node.js（Supported Frameworks、Build Settings）章节中。
静态、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

）：

静态： 请先在本地构建。
```
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

找不到它们——请按照下文自行上传文件。

Without the local deploy operations (hosted server; on the local server only for Agency)

无本地部署操作时（托管服务器；Agency 则仅在本地服务器上）

Get upload credentials:

hosting_files_generate-upload-url

(

username

domain

); Agency:

agency-hosting_files_generate-upload-url

(

website_uid

). Both return

url

auth_key

and

rest_auth_key

, which authenticate the upload instead of the API token.

Upload each file with TUS, where
```
DEST
```
is its path in the website's storage:

bash

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"

The first call returns

, the second

with an

Upload-Offset

header equal to the file size.

override=true

makes a retry safe. 3. Deploy from the uploaded files (

RANDOM8

is any fresh 8-character string, e.g.

$(LC_ALL=C tr -dc 'a-z0-9' < /dev/urandom | head -c 8)

Project	`DEST`	Then
Static or PHP	`site.zip`	`hosting_websites_deploy-static-site-archive` with `archive_path: "site.zip"`
Node.js	`app.zip`	`hosting_nodejs_build-settings-from-archive` with `archive_path: "app.zip"` , then `hosting_nodejs_start-build` with those settings, `source_type: "archive"` and `source_options.archive_path: "app.zip"`
WordPress plugin	every file, as `wp-content/plugins/SLUG-RANDOM8/<path in the plugin>`	`wordpress_plugins_deploy` with `slug` and `plugin_path: "SLUG-RANDOM8"`
WordPress theme	every file, as `wp-content/themes/SLUG-RANDOM8/<path in the theme>`	`wordpress_themes_deploy` with `slug` , `theme_path: "SLUG-RANDOM8"` and optional `is_activated`
Agency, extracted as-is	`.h5g/site.zip`	`agency-hosting_files_import-website-from-archive` with `archive_name: "site.zip"`
Agency `node-static`	`.h5g/RANDOM8/app.zip`	`agency-hosting_websites_build-nodejs-assets` with `archive_path: ".h5g/RANDOM8"` — the directory, not the file

获取上传凭据：
```
hosting_files_generate-upload-url
```
（
```
username
```
、
```
domain
```
）；Agency：
```
agency-hosting_files_generate-upload-url
```
（
```
website_uid
```
）。两者都会返回
```
url
```
、
```
auth_key
```
和
```
rest_auth_key
```
，这些凭据用于上传认证，而不是 API token。
使用 TUS 上传每个文件，其中
```
DEST
```
是文件在网站存储中的路径：

bash

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"

第一个调用返回

，第二个返回

，且

Upload-Offset

请求头的值等于文件大小。

override=true

可使重试安全。 3. 从已上传的文件进行部署（

RANDOM8

是任意新的 8 字符字符串，例如

$(LC_ALL=C tr -dc 'a-z0-9' < /dev/urandom | head -c 8)

）：

项目	`DEST`	然后
静态或 PHP	`site.zip`	使用 `archive_path: "site.zip"` 调用 `hosting_websites_deploy-static-site-archive`
Node.js	`app.zip`	使用 `archive_path: "app.zip"` 调用 `hosting_nodejs_build-settings-from-archive` ，然后使用这些设置、 `source_type: "archive"` 和 `source_options.archive_path: "app.zip"` 调用 `hosting_nodejs_start-build`
WordPress 插件	每个文件，路径为 `wp-content/plugins/SLUG-RANDOM8/<path in the plugin>`	使用 `slug` 和 `plugin_path: "SLUG-RANDOM8"` 调用 `wordpress_plugins_deploy`
WordPress 主题	每个文件，路径为 `wp-content/themes/SLUG-RANDOM8/<path in the theme>`	使用 `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 builds

3. Node.js 构建

hosting_deploy

returns a

buildUuid

at once; the build runs on the server and takes minutes. Track it with

hosting_get-deployment

(

domain

, optionally

buildUuid

; the latest build by default), polling every 10–20 s until

build.state

completed

failed

. It returns the build, its log and the stored build settings; pass the previous

logs.lines

fromLine

to read only new output.

Failed build: the response already carries
```
analysis
```
(fetched once per build; the API allows 5 a minute).
Wrong detection (framework,
```
output_directory
```
, or an entry file inside the build output, such as
```
dist/server.js
```
for a compiled app): deploy again with
```
appType
```
,
```
outputDirectory
```
,
```
buildScript
```
or
```
entryFile
```
set. An archive deploy sends its settings with the request and leaves the stored ones alone; a Git deploy also stores these values, so later pushes build with them.

On the hosted server, which has no

hosting_deploy

hosting_get-deployment

After the upload steps below, start the build and track it with
```
hosting_nodejs_list-builds
```
and
```
hosting_nodejs_build
```
(by
```
uuid
```
), polling every 10–20 s.
Failed build:
```
hosting_nodejs_analyse-failed-build
```
once per build (5 calls a minute), then
```
hosting_nodejs_build-logs
```
if the analysis is empty.

Wrong detection: run

hosting_nodejs_start-build

with explicit values,

source_type: "archive"

and

source_options.archive_path

set to the archive's file name in the document root (check it is there with

hosting_files_list-website-and-directories

). Store the same values with

hosting_nodejs_update-build-settings

To review detected settings before any build: upload the archive with
```
hosting_files_generate-upload-url
```
(the TUS steps are in its description), then
```
hosting_nodejs_build-settings-from-archive
```
.

hosting_deploy

会立即返回

buildUuid

；构建在服务器上运行，可能需要数分钟。使用

hosting_get-deployment

（

domain

，可选

buildUuid

；默认获取最新构建）跟踪构建，每 10–20 秒轮询一次，直至

build.state

为

completed

或

failed

。它会返回构建信息、日志和已保存的构建设置；传入上一次的

logs.lines

作为

fromLine

，即可仅读取新输出。

构建失败：响应中已经包含
```
analysis
```
（每次构建只获取一次；API 允许每分钟调用 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 秒轮询一次。
构建失败：每次构建调用一次
```
hosting_nodejs_analyse-failed-build
```
（每分钟 5 次），如果分析结果为空，再调用
```
hosting_nodejs_build-logs
```
。

检测错误：使用显式值、

source_type: "archive"

和

source_options.archive_path

调用

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. Auto-deploy from Git

4. 从 Git 自动部署

On the local server,

hosting_deploy

with

git: { repository: "owner/name", branch }

does all of it: it finds the Git installation that can reach the repository and deploys it as the

type

you give. Always pass

type: "static"

"nodejs"

unless the site already runs a Node.js app (or you pass Node.js settings such as

appType

): a new site is not detected as Node.js, and a Node.js repository deployed as static would publish its source. Then:

PHP and static sites: saves the auto-deployment settings, which deploys the branch immediately and again on every push;
Node.js sites: starts a build of the branch with the stored build settings; later pushes build the same way. A Git deploy has nothing to detect from, so when none are stored pass
```
appType
```
and
```
nodeVersion
```
(from
```
engines
```
in
```
package.json
```
), plus
```
outputDirectory
```
and
```
buildScript
```
if the app has a build step; they are stored for those pushes.

With no active installation it stops and says so: the user connects GitHub or GitLab once in hPanel under Websites → Manage → Advanced → Git; there is no API for that step. Confirm with

hosting_get-deployment

, which returns the stored

gitAutoDeployment

On the hosted server, by hand:

```
hosting_git_list-installations
```
. With no
```
active
```
installation (check
```
status: "pending"
```
and
```
"suspended"
```
too), the user connects GitHub or GitLab once in hPanel, as above.

hosting_git_list-installation-repositories

with the installation

uuid

gives

owner

name

and

default_branch

(10 calls a minute).

```
hosting_git_update-auto-deployment-settings
```
with
```
installation_uuid
```
,
```
owner
```
,
```
repository
```
,
```
branch
```
and optional
```
directory
```
.
- PHP and static sites deploy the branch immediately and again on every push.
- Node.js sites clone nothing on save: start the first build with
```
hosting_nodejs_start-build
```
  ,
```
source_type: "git"
```
  and the same
```
source_options
```
  . Later pushes build with the stored settings, so keep
```
hosting_nodejs_update-build-settings
```
  correct.
Confirm with
```
hosting_git_auto-deployment-settings
```
.

Agency Plan sites have no Git operations; deploy archives.

在本地服务器上，

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 部署没有可供检测的内容，因此如果尚未保存任何设置，请传入
```
appType
```
和
```
nodeVersion
```
（取自
```
package.json
```
的
```
engines
```
），并在应用有构建步骤时传入
```
outputDirectory
```
和
```
buildScript
```
；这些设置会被保存并用于后续推送。

如果没有有效的安装，该操作会停止并给出提示：用户需要在 hPanel 的 Websites → Manage → Advanced → Git 中一次性连接 GitHub 或 GitLab；此步骤没有对应的 API。使用

hosting_get-deployment

进行确认，它会返回已保存的

gitAutoDeployment

。

在托管服务器上手动操作：

```
hosting_git_list-installations
```
。如果没有
```
active
```
安装（也要检查
```
status: "pending"
```
和
```
"suspended"
```
），用户需要按上述方式在 hPanel 中一次性连接 GitHub 或 GitLab。

使用安装的

uuid

调用

hosting_git_list-installation-repositories

，获取

owner

、

name

和

default_branch

（每分钟 10 次调用）。

使用
```
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
```
  中的设置正确。
使用
```
hosting_git_auto-deployment-settings
```
进行确认。

Agency Plan 站点不支持 Git 操作；请部署归档。

5. Environment variables (Node.js)

5. 环境变量（Node.js）

hosting_nodejs_replace-environment-variables

replaces the whole set — anything not sent is deleted.

```
hosting_nodejs_list-environment-variables
```
for the current keys. Values come back as
```
********
```
; never send those back.
Build the full set: every current key plus the new ones, with real values from the project's
```
.env
```
or the user. When the real value of an existing key is unknown, ask — do not drop it.
Send it once; the app restarts. Values baked in at build time (Next.js
```
NEXT_PUBLIC_*
```
, Vite
```
VITE_*
```
) need a new
```
hosting_nodejs_start-build
```
.

Keys use uppercase letters, digits and underscores. Never commit

.env

files or repeat secret values back to the user.

hosting_nodejs_replace-environment-variables

会替换整个变量集合——未发送的任何变量都会被删除。

使用
```
hosting_nodejs_list-environment-variables
```
获取当前变量名。值以
```
********
```
返回；切勿将这些值发回。
构建完整集合：保留所有当前变量名并添加新变量名，值取自项目的
```
.env
```
或由用户提供。当某个现有变量的真实值未知时，应询问用户——切勿将其丢弃。
一次性发送完整集合；应用随即重启。在构建时固化到产物中的值（Next.js
```
NEXT_PUBLIC_*
```
、Vite
```
VITE_*
```
）需要重新调用
```
hosting_nodejs_start-build
```
。

变量名使用大写字母、数字和下划线。切勿提交

.env

文件，也不要向用户重复返回密钥值。

6. Database

6. 数据库

Node.js:
```
hosting_databases_setup-website
```
creates a MySQL database and writes
```
DB_HOST
```
,
```
DB_PORT
```
,
```
DB_NAME
```
,
```
DB_USER
```
,
```
DB_PASSWORD
```
and
```
DATABASE_URL
```
into the environment, then restarts the app. The password is generated and never returned. It fails with 422 when any of those keys exists — remove them first with the step 5 replace.
PHP:
```
hosting_databases_create
```
with
```
name
```
,
```
user
```
, a strong generated
```
password
```
and
```
website_domain
```
; read the prefixed full name back from
```
hosting_databases_list
```
. The app reads credentials from a config file on the server that stays out of Git, and connects to
```
localhost
```
or
```
127.0.0.1
```
.

Agency:

agency-hosting_databases_create-website

; the app connects to

localhost

The
```
srvNNNN.hstgr.io
```
host from
```
hosting_databases_list
```
is only for connections from outside Hostinger — never put it in the deployed app.

Node.js：
```
hosting_databases_setup-website
```
创建 MySQL 数据库，并将
```
DB_HOST
```
、
```
DB_PORT
```
、
```
DB_NAME
```
、
```
DB_USER
```
、
```
DB_PASSWORD
```
和
```
DATABASE_URL
```
写入环境变量，然后重启应用。密码由系统生成，且不会返回。当其中任一变量已存在时，该操作会返回 422——先使用步骤 5 的替换操作将其移除。
PHP： 使用
```
name
```
、
```
user
```
、系统生成的强密码和
```
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. Verify and record

7. 验证并记录

bash

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

alone can be a placeholder page; match real copy. A new site may serve a default page briefly — clear it with

hosting_cache_clear-website

and retry before calling the deploy failed.

Write

.hostinger/site.json

in the project so later runs reuse the target:

{ "domain", "username" or "website_uid", "type": "static" | "nodejs" | "php" }

, keeping any fields already there.

bash

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

仅有

可能说明返回的只是占位页面；应匹配真实文案。新网站可能短暂提供默认页面——先使用

hosting_cache_clear-website

清除缓存并重试，再判定部署失败。

在项目中写入

.hostinger/site.json

，以便后续运行复用目标：

{ "domain", "username" or "website_uid", "type": "static" | "nodejs" | "php" }

，并保留其中已有的所有字段。