wp

The wp commands act on the WordPress installation of an environment: run a WP-CLI command, get a one-time login link, and create or look up admin users. For the database, see db.

kinstactl wp run my-site "wp plugin list" --env live --yes
kinstactl wp login my-site --env live --email [email protected]
kinstactl wp user exists my-site [email protected] --env live

Without --env, a site with one environment uses it; a site with several gets a picker on a terminal and fails with ENV_REQUIRED in a script. See Sites and environments.

wp run

Run a WP-CLI command in an environment.

kinstactl wp run my-site "wp core version" --env live --yes

kinstactl wp run <site> <command> [options]

Run a WP-CLI command in an environment

Arguments

Argument	Description
`site`	site name, display name or ID
`command`	the WP-CLI command, starting with "wp "

Options

Option	Description
`--env <environment>`	environment name or ID
`--dry-run`	print the resolved target and request; change nothing
`--no-wait`	return the operation ID instead of waiting
`--timeout <minutes>`	give up waiting after this many minutes (default 30)
`--yes`	skip the confirmation prompt

Global options --profile, --json and --no-input apply too. See scripting and CI.

Kinsta API: GET /sites, POST /sites/environments/{env_id}/run-wp-cli-command

Pass the whole WP-CLI command as one quoted argument, starting with wp . Only letters, digits and the characters -_./:=@' are allowed, so pipes, redirects, ; and $(...) are rejected with a USAGE error before anything is sent.

A WP-CLI command can change anything, so the command asks for confirmation. On a terminal you answer a prompt; in a script pass --yes, otherwise it fails with CONFIRMATION_REQUIRED (exit code 5). --dry-run prints the request and does not ask.

The command waits for Kinsta to finish, and accepts --no-wait and --timeout <minutes>; see operations. The output of the WP-CLI command is the result of the operation and is the only thing printed on stdout. With --json you get one document with operation_id, status, message and data, where data holds the output. With --no-wait the command returns right after the request is accepted: in human mode the operation ID appears only in the Follow with: hint on stderr, and with --json it is operation_id on stdout.

Create a one-time WordPress admin login link.

kinstactl wp login my-site --env live --email [email protected]

kinstactl wp login [site] [options]

Create a one-time WordPress admin login link

Arguments

Argument	Description
`site`	site name, display name or ID

Options

Option	Description
`--env <environment>`	environment name or ID
`--email <email>`	email of the WordPress admin user to log in as
`--dry-run`	print the resolved target and request; change nothing

Global options --profile, --json and --no-input apply too. See scripting and CI.

Kinsta API: GET /sites, POST /sites/environments/{env_id}/wpa-login-url

--email is required and must be the email of an existing WordPress admin user; there is no prompt for it. Check that with wp user exists. The command prints the login link on stdout, and nothing else. Treat the link like a password: anyone who opens it before it is used is logged in. This command has no --no-wait.

wp user create

Create a WordPress admin user.

kinstactl wp user create my-site [email protected] --env live --first-name Ann --last-name Lee

kinstactl wp user create <site> <email> [options]

Create a WordPress admin user

Arguments

Argument	Description
`site`	site name, display name or ID
`email`	email of the new user

Options

Option	Description
`--env <environment>`	environment name or ID
`--first-name <name>`	first name of the user
`--last-name <name>`	last name of the user
`--dry-run`	print the resolved target and request; change nothing

Global options --profile, --json and --no-input apply too. See scripting and CI.

Kinsta API: GET /sites, POST /sites/environments/{env_id}/wpa-create-user

--first-name and --last-name are required; without them the command fails with a USAGE error, there is no prompt. The command takes no password and prints none: on success it prints Created WordPress admin user <email>, and with --json the response from Kinsta. If Kinsta reports that it did not create the user, the command fails with API_ERROR. This command has no --no-wait.

wp user exists

Check whether a WordPress admin user exists.

kinstactl wp user exists my-site [email protected] --env live

kinstactl wp user exists <site> <email> [options]

Check whether a WordPress admin user exists

Arguments

Argument	Description
`site`	site name, display name or ID
`email`	email of the user

Options

Option	Description
`--env <environment>`	environment name or ID

Global options --profile, --json and --no-input apply too. See scripting and CI.

Kinsta API: GET /sites, GET /sites/environments/{env_id}/wpa-user-exists

The command prints yes or no. With --json it prints email and has_wp_admin_user, which is what to read in a script.