Scripting with the CLI

Use the hostinger CLI in scripts and CI — JSON output, jq filters and pagination, exit codes and error output, passing JSON to flags, confirmations and dry runs, deploying with hostinger up, and crede

Practical notes for using hostinger in shell scripts, CI pipelines, and bulk operations. These are the behaviors that aren't obvious from --help.

Machine-readable output

When standard output isn't a terminal — piped, redirected, or captured in a variable — the CLI prints the API response as JSON, unchanged. You don't need --format json in scripts, though passing it makes the intent explicit. If you've changed the default with hostinger config set format, that setting wins, so pass --format json in scripts that must not depend on local settings.

Filter with --jq, which takes a jq expression and doesn't require jq to be installed. Strings print without quotes, like jq -r; every other result prints as compact JSON, one per line:

for id in $(hostinger vps virtual-machines list --jq '.[].id'); do
  hostinger vps virtual-machines get "$id" --jq '.state'
done

List endpoints that return results in pages only give you the first page by default. Add --all to fetch every page; the result keeps the same data and meta shape, with all items in data:

hostinger hosting websites list --all --jq '.data[].domain'

Errors, prompts, progress from --wait, and notices such as deprecation warnings go to standard error, so they never mix into the output you're parsing.

Exit codes and errors

The exit code tells you what kind of failure happened:

Code	Meaning
0	Success.
1	The API failed (other than the cases below), a network error occurred, a --wait action failed, or a confirmation was declined.
2	Invalid input — unknown command or flag, a missing or malformed argument, an invalid flag value, or malformed JSON. Nothing was sent to the API.
3	The API rejected the credentials (401).
4	The resource wasn't found (404).
5	The API rejected the request as invalid (422).

On an API error, the CLI prints the message to standard error, with each invalid field named after the flag that sets it, and the correlation ID to quote to support:

Error: The redirect url field must be a valid URL. (HTTP 422)
  --redirect-url: The redirect url field must be a valid URL.
Correlation ID: 26a91bd9-f8c8-4a83-9df9-83e23d696fe3

Branch on the code rather than parsing the text:

hostinger vps virtual-machines get "$id" >/dev/null 2>&1
case $? in
  0) echo "exists" ;;
  4) echo "no such machine" ;;
  *) echo "lookup failed" >&2; exit 1 ;;
esac

See Errors for the API's error format.

Passing JSON to flags

Some flags take a JSON value rather than a scalar. They're marked (JSON …) in the help output, and the command's help shows an example of the expected shape — for example --zone on dns records update, --setup on vps virtual-machines purchase, and --items on billing orders create-purchase.

The value can be given three ways:

Form	Example
Inline	--zone '[{"name": "@", "type": "A", "ttl": 3600, "records": [{"content": "192.0.2.1"}]}]'
From a file	--zone @zone.json
From standard input	--zone -

The value is parsed before any request is sent, so a quoting mistake or a missing file fails immediately with exit code 2 and costs nothing. Inline, wrap the whole value in single quotes so the shell leaves the double quotes alone. The file and standard-input forms avoid quoting entirely, and are the easiest option in PowerShell:

jq '.zone' desired-state.json | hostinger dns records update example.com --zone -

Confirmations and dry runs

Commands that delete, stop, restart, restore, reset, uninstall, deactivate, or purchase ask for confirmation in a terminal. In a script there's no one to answer, so they refuse to run and exit with code 2 unless you pass --yes:

hostinger vps snapshots delete 1234567 --yes

The CLI also prompts for missing arguments and required flags when it runs in a terminal. In scripts that never happens, because there's no terminal on standard input, but you can make it explicit with --no-input or HOSTINGER_NO_INPUT=true, so a missing value always fails fast.

Before running a loop that changes state, check what it would send with --dry-run. Each request is printed as a curl command, with the token written as $HOSTINGER_API_TOKEN, and nothing is sent:

hostinger dns records update example.com --zone @zone.json --dry-run

Add --verbose to a real run to log each request and its status code to standard error. Headers aren't logged, so tokens never appear.

Commands worth being careful with

Not every command that discards state asks for confirmation. Two in particular don't:

dns records update overwrites by default. --overwrite defaults to true, which deletes records matching a name and type and recreates them. To append and update instead of replacing, set it explicitly:

hostinger dns records update example.com --overwrite=false --zone @zone.json

Take a snapshot first, so you have a rollback:

hostinger dns snapshots list example.com

wordpress litespeed-cache purge-lite-speed runs without asking. It clears the site's LiteSpeed cache straight away.

Read-only verbs — list, get, info, and the various show-* commands — are safe to explore freely.

Waiting for VPS actions

VPS power and maintenance commands return as soon as the action is queued. In a pipeline that needs the machine to be ready before the next step, add --wait:

hostinger vps virtual-machines restart 1234567 --yes --wait --wait-timeout 15m

The command exits 0 once the action succeeds and 1 if it fails or the timeout passes.

Deploying from scripts

hostinger up never prompts without a terminal, or when CI or HOSTINGER_NONINTERACTIVE is set, or with --no-input. Pass what it would otherwise ask for:

• --domain to deploy to an existing website, or --create for a new one. Add --order-id when the account has more than one hosting plan; with only one, it's used automatically.

• --yes to replace a website that already has content, or to accept the detected type.

• For Node.js apps, flags such as --type nodejs, --app-type, --entry-file, and --node-version override the detected build settings.

Don't rely on the .hostinger/site.json link in CI — it's kept out of Git because it names your hosting account. Pass --domain instead.

hostinger up ./dist --domain example.com --yes --format json
hostinger up --create --type nodejs --app-type express --entry-file server.js --format json

With --format json, the command prints one JSON object describing the outcome to standard output, and progress to standard error. A failure exits non-zero — API errors with the exit codes above — and the object carries an error field.

Check the plan first with --dry-run, which prints it as JSON and changes nothing. When the first deploy would replace what the website currently serves, the plan includes "overwritesContent": true, and the real run needs --yes:

hostinger up --dry-run --domain example.com

Node.js builds run on the server, and hostinger up waits for them by default. To return as soon as the build starts, add --no-wait; the output includes the build's buildUuid, which you can poll:

hostinger up --no-wait --domain example.com --format json
hostinger hosting nodejs build example.com <build-uuid>

Credentials for unattended runs

Browser sign-in is convenient on a workstation but useless in CI, because nothing can complete the flow. For automation, set a token instead:

export HOSTINGER_API_TOKEN=<your API token>

A configured token takes precedence over browser sign-in, and no browser will be opened. Generate tokens in hPanel → API and treat them like passwords — see Security & Access.

Interactive sign-in caches its tokens outside the config file, at ~/.config/hostinger/api-cli/credentials.json (%APPDATA%\hostinger\api-cli\credentials.json on Windows), with owner-only permissions. To sign out, or to switch to a different Hostinger account, run hostinger auth logout; the next command starts a fresh sign-in.

---

Last updated: October 27, 2026