WP-CLI is the official command-line tool for WordPress. Once you have it installed on a server with PHP, MySQL, and SSH access, you can deploy a fully configured WordPress site in under a minute – download core, generate
wp-config.php
, create the database, and run the install with the admin account already set up. No
wp-admin/install.php
wizard, no clicking through the five-step web installer, no manually copying database credentials into a config file.
This guide walks through installing WP-CLI itself, then the four commands that get WordPress from “empty directory” to “working site”. It also covers the everyday WP-CLI workflow once the install is done – managing plugins, themes, users, and cache from the command line.
Why use WP-CLI instead of the web installer#
The web installer works fine for a one-off install on shared hosting where you have nothing but FTP and a control panel. As soon as you have SSH access, WP-CLI is faster and more controllable for several reasons:
- Scriptable. The four-command install fits in a shell script. Build a fresh WordPress in seconds, identically every time.
- Idempotent flags. Most commands have
--skip-checkand similar options that let you run them safely in automation. - No browser session needed. You can install WordPress on a server you cannot browse to yet (during DNS propagation, behind a VPN, on a private staging subdomain).
- Bypasses the file upload limit problem. The web installer needs the WordPress zip to be unpacked on the server already. WP-CLI handles the download itself.
- Same tool you use afterwards. Once you learn
wp core install, you also havewp plugin install,wp user create,wp option update, and the rest. There is no second tool to learn.
For migrations, automated deployments, and any environment where you spin up WordPress more than once a year, WP-CLI is the right default.
Installing WP-CLI#
The official install method is the phar (PHP Archive) file. Three commands, run over SSH:
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
Verify it works:
wp --info
You should see version info, the PHP binary it is using, and the configured PHP version. If you see “command not found”,
/usr/local/bin
is not in your
$PATH
– either move the file to a directory that is in your path, or symlink it.
If you do not have
sudo
access (shared hosting), drop the phar in your home directory and call it directly:
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar ~/wp
Then run it as
~/wp
(or add
~
to your
$PATH
).
WP-CLI requires PHP 7.4 or newer. If
wp --info
fails with PHP version errors, check the PHP version available on your server and switch to a supported one before proceeding.
Installing WordPress: the four commands#
Move into the directory where you want WordPress to live (typically the document root for the domain –
/var/www/example.com
,
/home/user/public_html
, or whatever your provider uses). The four commands run from that directory.
Step 1: Download WordPress core
wp core download --locale=en_US
This pulls the latest stable WordPress release into the current directory. Files like
wp-admin/
,
wp-includes/
,
index.php
, and
wp-load.php
appear immediately. There is no
wp-config.php
yet – that comes next.
Useful flags:
-
--locale=en_US– language pack. Usede_DE,fr_FR,es_ES, etc. for non-English installs. -
--version=6.5– pin a specific version instead of latest. -
--skip-content– skip the default themes (Twenty Twenty-Four, etc.) and the default plugins (Akismet, Hello Dolly). Useful if you are about to install your own. -
--force– re-download core if files already exist (use carefully – overwrites changes).
Step 2: Create the database
WP-CLI cannot run
wp db create
until
wp-config.php
exists, but
wp config create
will fail if the database does not exist yet. The cleanest order is to create the database manually first, then generate the config, then let WordPress see them already in place.
If you have MySQL root or admin credentials on the server:
mysql -u root -p -e "CREATE DATABASE wp_example CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'your_password';"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON wp_example.* TO 'wp_user'@'localhost';"
mysql -u root -p -e "FLUSH PRIVILEGES;"
The full breakdown of these commands lives in how to create a database in MySQL and how to show and manage MySQL users.
If your hosting provider gives you a database and credentials but not MySQL root access, skip the SQL above – you already have what you need. Use the credentials they provided in step 3.
Step 3: Generate wp-config.php
wp config create \
--dbname=wp_example \
--dbuser=wp_user \
--dbpass=your_password \
--dbhost=localhost \
--dbprefix=wp_
This generates
wp-config.php
in the current directory with the database credentials, fresh authentication keys and salts (fetched from
api.wordpress.org/secret-key/1.1/salt/
), and the table prefix you specified.
Useful flags:
-
--dbprefix=wp_– default. Use a different prefix (wp_yoursite_) on hardened installs to make blind SQL injection slightly harder. -
--dbcharset=utf8mb4– default and correct for emoji/multi-language support. -
--extra-php– inject extra PHP into the config (debug constants, table prefix overrides, etc.). -
--skip-check– skip the database connection check. Useful if the database server is on a different host that is not reachable yet but will be by install time.
Test that the config can reach the database:
wp db check
If this fails, fix the credentials or host before continuing. Every other step will fail if WordPress cannot reach the database. If the host is right and the credentials are right but you still get connection errors, error establishing a database connection covers the diagnostic path.
The full tour of every option you can drop into
wp-config.php
is in wp-config.php explained: what every setting does.
Step 4: Run the install
wp core install \
--url=https://example.com \
--title="Example Site" \
--admin_user=admin_username \
--admin_password=strong_password_here \
--admin_email=you@example.com
This is the equivalent of completing the web installer. WP-CLI creates the WordPress database tables, sets the site URL and title, creates the admin user, and marks the install as complete.
Required flags:
-
--url– the site URL. Usehttps://if SSL is already configured (otherwise WordPress will mix-content on the dashboard). -
--title– the site name. Show in<title>tags and the WordPress dashboard. -
--admin_user– the admin username. Do not useadmin– it is the first thing every brute-force bot tries. -
--admin_password– the admin password. Generate something long and random; WP-CLI does not enforce complexity. -
--admin_email– the admin’s email. Used for password resets and admin notifications.
Useful flags:
-
--skip-email– do not send the welcome email to the admin user. Useful in automation. -
--locale=en_US– install language. Should match what you downloaded withwp core download.
That is it. WordPress is installed. Visit the URL in a browser and you should see the freshly-installed front page; visit
/wp-admin/
and the login page accepts the credentials you set.
A complete one-liner script#
Putting it all together for a scripted install:
#!/bin/bash
set -e
DOMAIN="example.com"
DBNAME="wp_example"
DBUSER="wp_user"
DBPASS="$(openssl rand -base64 18)"
ADMIN_PASS="$(openssl rand -base64 18)"
cd /var/www/$DOMAIN
mysql -u root -p -e "CREATE DATABASE $DBNAME CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER '$DBUSER'@'localhost' IDENTIFIED BY '$DBPASS';"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON $DBNAME.* TO '$DBUSER'@'localhost';"
wp core download --locale=en_US
wp config create --dbname=$DBNAME --dbuser=$DBUSER --dbpass=$DBPASS --dbprefix=wp_
wp core install --url=https://$DOMAIN --title="$DOMAIN" \
--admin_user=admin_$RANDOM --admin_password=$ADMIN_PASS \
--admin_email=you@$DOMAIN --skip-email
echo "Admin password: $ADMIN_PASS"
echo "DB password: $DBPASS"
This deploys a working WordPress site in about ten seconds. Save the printed credentials somewhere safe before they scroll off the screen.
For repeat use, parameterize the script and store the MySQL root password in a
~/.my.cnf
file so you do not have to type
-p
each time.
Useful WP-CLI commands for everyday work#
Once WordPress is installed, WP-CLI replaces a lot of dashboard clicking. The commands you will use most:
Plugins
wp plugin list # list installed plugins
wp plugin install yoast-seo --activate # install + activate
wp plugin update --all # update everything
wp plugin deactivate woocommerce # deactivate
wp plugin delete hello # remove
wp plugin search "image optimization" # search the .org repo
Themes
wp theme list
wp theme install twentytwentyfour --activate
wp theme update --all
Users
wp user list
wp user create newadmin you@example.com --role=administrator --user_pass=...
wp user update 1 --user_pass=NewPassword # reset by ID
wp user delete 5 --reassign=1 # delete user 5, reassign content to user 1
For a full walkthrough of the password-reset case specifically (including when WP-CLI is not available), see how to reset the WordPress admin password.
Cache and cron
wp cache flush # clear object cache
wp cron event list # see scheduled events
wp cron event run --due-now # run anything overdue
wp transient delete --all # clear all transients
Database
wp db check
wp db optimize
wp db export backup.sql # export to a file
wp db import backup.sql # import from a file
wp search-replace 'http://oldsite.com' 'https://newsite.com' # safe URL replacement
The
search-replace
command in particular is one of WP-CLI’s most useful features for migrations – it understands serialized PHP data, which a raw SQL
UPDATE
does not. This is why a naive find-and-replace breaks WordPress migrations and
wp search-replace
does not.
Updates
wp core check-update # is a new version available?
wp core update # update WordPress core
wp core update-db # run database upgrade routines after a core update
wp core version # see the installed version
The interplay between manual core updates and the WordPress auto-update system is covered in WordPress automatic updates: how to enable, disable, and control them. For just checking the version without running anything, see how to check your WordPress version.
Common installation problems#
“Error: This does not seem to be a WordPress install.”
WP-CLI cannot find WordPress in the current directory. Either you are in the wrong directory, or
wp core download
has not run yet. Move into the WordPress root and try again:
cd /var/www/example.com
wp core is-installed
You can also point WP-CLI at any directory with
--path
:
wp --path=/var/www/example.com core is-installed
“Error: Database connection error”
Check that the credentials in
wp-config.php
are correct, that the database exists, and that the user has privileges on it. Quick check:
wp db check
mysql -u wp_user -p wp_example -e "SELECT 1;"
If
mysql -u ... wp_example
fails, the credentials are wrong or the database does not exist – WP-CLI will fail the same way. If
mysql
works but
wp db check
fails, the credentials in
wp-config.php
do not match what you are typing on the command line.
“Error: The site you have requested is not installed.”
You ran
wp config create
but not
wp core install
. The database is configured but the WordPress tables have not been created. Run
wp core install
with the required flags above.
Permission errors writing files
WP-CLI runs as the user you SSH’d in as. If WordPress files are owned by a different user (
www-data
,
apache
,
nginx
),
wp core download
and
wp plugin install
may fail to write. The standard fix is to run WP-CLI as the file owner:
sudo -u www-data wp core download
Or change file ownership before running WP-CLI. Do not chmod files to 777 to work around this – it works but it is a security mistake.
--allow-root
warning
If you run WP-CLI as root, you get a warning that says it is unsafe. WordPress is designed to run as the web server user, not root. Use
sudo -u www-data
(or whatever your web server user is) instead of running as root, or pass
--allow-root
if you genuinely need to (in containers where root is the only user, for example).
How Hostney handles WP-CLI#
On Hostney, WP-CLI is preinstalled and configured for every WordPress installation. You do not need to download the phar or manage the binary – log in via SSH (key-based auth, set up through the SSH Keys page in the control panel – see how to set up passwordless SSH login),
cd
into your WordPress root, and
wp
is on the path.
You also do not need to follow the four-command install for new WordPress sites. The control panel’s WordPress page has a one-click deployment that does exactly the same thing – downloads core, creates the database and database user, generates wp-config with secure salts, runs the install, and adds the result to the management UI with vulnerability scanning, snapshots, and the auto-update toggles already wired up. WP-CLI is for when you want to do it yourself, automate something the UI does not cover, or run ad-hoc maintenance.
The combination is the useful part: the platform handles the install, you keep WP-CLI for everything afterwards. Need to bulk-install ten plugins on a fresh site?
wp plugin install plugin-1 plugin-2 ... --activate
. Need to update database URLs after a domain change?
wp search-replace
. Need to reset a contributor’s password without going through the wp-admin UI?
wp user update
. The platform deploys, WP-CLI maintains.
Summary#
WP-CLI installs in three commands and turns WordPress installation into a four-command flow:
wp core download
, create the database,
wp config create
,
wp core install
. Every flag you need is on the official command – no web installer, no manual config editing. Once installed, the same tool runs your day-to-day plugin/theme/user/database management.
The web installer is the right tool when you have FTP and a control panel and nothing else. As soon as you have SSH, WP-CLI is the right default.