Sail Knowledgebase

How to Deploy WordPress with Sail CLI

In this article you will learn about the sail deploy command, and how to use it effectively to push your local changes to production.

If you like Sail, consider sponsoring us via GitHub!

Working copy vs. production

When working with Sail, you will almost always have a local working copy, which is where you ran sail init to start your project. This is a copy of your production application, with a few differences and aspects to keep in mind.

First, any changes you make in production, will not magically appear in your local working copy. This means that if you install a new theme or plugin, update WordPress core, etc., using WP-CLI or wp-admin, these changes will remain on your production server only, until you explicitly pull them to your local working copy.

You can pull changes from production to your local working copy using:

sail download

You can learn more about keeping your local working copy in sync with production in our guide.

Deploying local changes to production

When you've made changes to your local working copy, you can push them to production using:

sail deploy

This will create a new release directory on your production server, send over all your application files to this new directory, and perform an atomic deploy.

View changes before deploying with dry-run

If you're not sure about the state of your local working copy, and whether it is or was in sync with production, you can add the --dry-run flag to only show the changes about to be applied by a deploy:

sail deploy --dry-run

You will see files that will be created, modified or deleted. If the changes look correct, just drop the --dry-run flag to perform a deploy.

Sparse deploys

It is always recommended to perform a full application deploy, however in some situations, you might want to deploy changes only in a specific directory of your WordPress application. You can do so by specifying the path to deploy, for example:

sail deploy wp-content/plugins/my-custom-plugin

This will deploy only changes in the wp-content/plugins/my-custom-plugin directory to production, keeping everything else intact.

Using sparse deploys is a good method to resolve conflicts between production and local working copies, when the two have diverged significantly.

Uploads

By default, sail deploy will ignore everything in the wp-content/uploads directory. This is usually the desired behavior, since you don't really want to be pulling and pushing large files around. However, if you do need to sync your local uploads with the ones in production, you can simply add the --with-uploads flag:

sail deploy --with-uploads

Note that this will overwrite anything you may already have in the wp-content/uploads directory on your production server.

Deploying uploads is usually useful only when migrating an existing WordPress site to a Sail-powered server on DigitalOcean.

Pre-deploy Hooks

Sail CLI supports adding one or more pre-deploy hooks, which are executable scripts that run before deploying changes to production. This is useful for checking PHP syntax, running unit tests or coding standards checks. Here's a quick example.

Undoing changes

If you'd like to undo a deploy, you can use the rollback command.

If you have any questions or feedback about deploying with Sail CLI, check out the getting help section.