Run WP-CLI Over SSH

Updated 2 October 2026

WP-CLI is WordPress on the command line. Everything you would click through in the dashboard, and several things you cannot do there at all, run as one line of text. Updating forty plugins takes a second instead of ten minutes of clicking.

WP-CLI can be switched on for any website here, on its SFTP tab. You will need an SSH key first. See add an SSH key.

Step 1: Run Your First Command

Switch WP-CLI on for the website on its SFTP tab, take the host from the same tab, and remember the port. There is no shell to log in to: each command is one SSH call, as the oxywp user, with the wp command after it.

ssh -p 2222 oxywp@HOST wp core version

A version number means you are ready. There is nothing to configure: the command runs inside your own website’s web root with its database credentials already in place, so WP-CLI finds the database by itself.

Every example on this page shows only the wp part. Run each one as ssh -p 2222 oxywp@HOST followed by the command. A command is stopped after ten minutes.

The command runs as your website’s own user inside its container. There is no root, no shell and no access to anything outside your own site, which is what keeps every site on the platform separate from every other. The --path, --ssh, --http and --require options are not available; wp commands do not need them here.

Step 2: Learn The Shape Of A Command

Every command reads the same way: wp, then the thing, then what to do to it.

wp plugin list
wp plugin update --all
wp user list

Add --help to anything to see what it takes:

wp plugin update --help

Step 3: The Commands Worth Knowing

Command	What it does
`wp core version`	Tells you the WordPress version
`wp plugin update --all`	Updates every plugin at once
`wp plugin list`	Shows what is installed, active and out of date
`wp user list`	Lists users with their roles and emails
`wp cache flush`	Empties the object cache
`wp db export`	Writes the whole database to a `.sql` file
`wp search-replace OLD NEW`	Replaces a string across every table

Updating plugins is the one most people use first:

wp plugin update --all

Checking who has an account on the site is the one most people wish they had known about:

wp user list

Step 4: Export The Database Before Anything Risky

wp db export backup.sql

That writes a complete copy into your web root, which you can then pull down over SFTP. Do it before any command that writes to the database.

Oxyforge blocks .sql, .bak, .env and similar files at the web server, so a dump in your web root is not downloadable over the web. It still counts toward your storage, so download it over SFTP and then delete it from the server.

The nightly backups on the Backups tab are your real safety net. An export is for the ten minutes in which you are about to change something. See how backups work.

Step 5: Search And Replace, Carefully

wp search-replace is the most useful and the most dangerous command in the set. It rewrites text across every table, which is how you fix stored URLs after a move.

Always run it with --dry-run first:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run

That changes nothing. It prints a table of how many replacements it would make in which tables. Read it. If the numbers look right, run the same command again without --dry-run.

There is no undo. A search-replace with a typo in it rewrites your content and the only way back is the database export you took first. Take the export, use --dry-run, read the output.

Serialised data is the reason to use this command rather than a SQL query. WordPress stores plugin settings as serialised PHP, where the stored string contains its own length. Editing it with raw SQL breaks it. WP-CLI unpacks and repacks it properly.

Step 6: Clearing Caches

wp cache flush

That clears the Redis object cache, which holds the results of repeated database lookups. It does not clear the platform’s full-page cache, which sits in front of PHP and knows nothing about WP-CLI. For that, use Clear Cache on the site’s Tools tab. See clear the cache.

If you have changed a template and the site still looks old, it is the page cache, not the object cache.

Troubleshooting

“Permission denied (publickey)”. The key is the problem, not WP-CLI. Check the public key is on the SFTP tab, that WP-CLI is switched on there, and that your client is offering the matching private key.

Connection refused or hanging. The port is 2222.

“Error: This does not seem to be a WordPress installation”. Rare here, because every command already runs in your web root. If you see it, WordPress core files have been removed or damaged: restore from the Backups tab.

“Error establishing a database connection”. Unusual here, since the credentials are already in place. Check wp-config.php has not been edited with values from another host, then open a ticket.

A command runs out of time on a big site. Work in smaller pieces. Updating plugins one at a time rather than with --all usually gets a heavy site through, and adding --skip-plugins stops other plugins loading while a command that does not need them runs.

A plugin update broke the site. Roll that plugin back to the previous version, or restore from the Backups tab. See restore a backup.

You want to try something first. Run it on a staging site. That is what staging is for, and it costs you nothing but a minute.

Did this answer it? If not, open a ticket from the members area and someone who runs the platform will pick it up.

Open A Ticket