Deploy To Hosting

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.

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.

1. Pick the target website

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

2. Choose the deploy

Wrong method is the most common failure. Decide from the project on disk:

On 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. WordPress plugins and themes on Agency sites are installed from wp-admin.

Archive rules (name archives name_YYYYMMDD_HHMMSS.zip):

• 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.
• Agency deploys are synchronous: the site is live when the call returns.

The operations in the table read the archive from this machine, so only the local hostinger-api-mcp server has them. On the hosted server (mcp.hostinger.com) search does not find them — upload the files yourself as below.

Without the local deploy operations

1. 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.
2. Upload each file with TUS, where DEST is its path in the website's storage:

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 201, the second 204 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)):