sites

The sites commands manage whole sites, that is a site with all its environments. For one environment of a site, see env.

kinstactl sites list
kinstactl sites get my-site
kinstactl sites create "My Site" --region europe-west4 --plain

Creating, cloning, resetting, deleting and changing the PHP allocation of a site are long operations. Each of them waits for Kinsta to finish by default, and accepts --no-wait, --timeout <minutes> and --dry-run; see operations. --dry-run prints the resolved site and the request that would be sent, and changes nothing.

sites list

List the sites of the company.

kinstactl sites list --refresh

kinstactl sites list [options]

List the sites of the company

Options

Option	Description
`--refresh`	bypass the local site cache

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

Kinsta API: GET /sites

kinstactl caches the list of sites for five minutes to resolve site names quickly, see Sites and environments. Use --refresh after you created or removed a site in MyKinsta and the list is out of date.

sites get

Show the details of a site.

kinstactl sites get my-site

kinstactl sites get [site] [options]

Show the details of a site

Arguments

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

Kinsta API: GET /sites, GET /sites/{site_id}

Without <site>, a command on a terminal shows a picker. Add --json for the full API response.

sites create

Create a new site.

kinstactl sites create "My Site" --region europe-west4 --admin-user admin --admin-email [email protected] --admin-password -

kinstactl sites create <display-name> [options]

Create a new site

Arguments

Argument	Description
`display-name`	display name of the new site

Options

Option	Description
`--region <region>`	Kinsta region, see: company regions; omitted on a TTY opens a picker
`--plain`	create an empty environment without WordPress
`--admin-user <name>`	WordPress admin user name
`--admin-email <email>`	WordPress admin email
`--admin-password <password>`	"-" reads it from stdin; omitted on a TTY prompts for it
`--title <title>`	site title (default: the display name)
`--language <code>`	WordPress language
`--multisite`	install WordPress as a multisite
`--subdomain-multisite`	make the multisite use subdomains
`--woocommerce`	install WooCommerce
`--yoast`	install Yoast SEO
`--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)

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

Kinsta API: GET /company/{id}/available-regions, POST /sites, POST /sites/plain

By default the new site gets a WordPress install, which needs the admin user, email and password. Pass --plain for an empty environment without WordPress; the WordPress options (--admin-user, --title, --multisite, --woocommerce, --yoast and so on) are for the default install. --admin-password - reads the password from stdin, so it stays out of your shell history. On a terminal, a missing region or password is asked for interactively.

kinstactl sites create "My Site" --region europe-west4 --plain

Run kinstactl company regions to see the region IDs.

sites clone

Clone an environment of a site into a new site.

kinstactl sites clone my-site "My Other Site" --env live

kinstactl sites clone <site> <display-name> [options]

Clone an environment of a site into a new site

Arguments

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

Options

Option	Description
`--env <environment>`	environment to clone (default: the only one)
`--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)

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

Kinsta API: GET /sites, POST /sites/clone

The new site gets a copy of the chosen environment. Without --env, the site’s only environment is used.

sites delete

Delete a site with all its environments.

kinstactl sites delete my-site --confirm my-site

kinstactl sites delete [site] [options]

Delete a site with all its environments

Arguments

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

Options

Option	Description
`--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)
`--confirm <site-name>`	the site name, to confirm an irreversible action

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

Kinsta API: GET /sites, DELETE /sites/{site_id}

Deleting a site cannot be undone, so --yes is not accepted here. You confirm by typing the site name when prompted, or by passing it as --confirm <site-name>, which is the way to do it in a script. A name that does not match fails with CONFIRMATION_REQUIRED (exit code 5), and so does a script that passes no --confirm. Run it with --dry-run first to see what would be deleted.

sites reset

Reset a site to a fresh WordPress install, in all environments.

kinstactl sites reset my-site --admin-password - --confirm my-site

kinstactl sites reset [site] [options]

Reset a site to a fresh WordPress install (all environments)

Arguments

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

Options

Option	Description
`--admin-password <password>`	"-" reads it from stdin; omitted on a TTY prompts for it
`--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)
`--confirm <site-name>`	the site name, to confirm an irreversible action

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

Kinsta API: GET /sites, POST /sites/{site_id}/reset-site

Everything on the site is replaced by a clean WordPress install, in every environment. This cannot be undone either, so the same --confirm <site-name> rule as for sites delete applies. The admin password for the new install is read from stdin with -, or prompted for on a terminal.

sites php-allocation

Change the PHP allocation of the live and standard staging environments.

kinstactl sites php-allocation my-site --threads 4 --memory 256

kinstactl sites php-allocation [site] [options]

Change the PHP allocation of the live and standard staging environments

Arguments

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

Options

Option	Description
`--threads <n>`	number of PHP threads
`--memory <mb>`	memory per PHP thread in MB
`--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)

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

Kinsta API: GET /sites, POST /sites/{site_id}/change-site-php-allocation

--threads sets the number of PHP threads and --memory the memory per thread in MB. The change applies to the live environment and the standard staging environment of the site. For a premium staging environment, use env php-allocation.

sites usage

Show the visits, bandwidth and CDN bandwidth of a site this month.

kinstactl sites usage my-site

kinstactl sites usage [site] [options]

Visits, bandwidth and CDN bandwidth of a site this month

Arguments

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

Kinsta API: GET /sites, GET /sites/{site_id}/usage/visits/this-month, GET /sites/{site_id}/usage/bandwidth/this-month, GET /sites/{site_id}/usage/cdn-bandwidth/this-month

The numbers are for the current month. Use --json to feed them into a report.