Deploying WordPress to DigitalOcean with Sail CLI


If you’re looking for hands-off fully managed WordPress hosting with support and hand-holding, then Sail is not for you. However, if you’re a DIY type of person, like to tinker with servers, and don’t mind getting your hands dirty with the command line, then you will absolutely love Sail CLI.

Sail is a free and open source command line tool, which allows you to provision, deploy and manage WordPress applications in the DigitalOcean cloud. It’s a collection of essential scripts and commands to help you launch servers, add domains and DNS records, deploy your code, create and restore backups, configure mail relay and much more.

In this tutorial you’ll learn how to provision your first vanilla WordPress application on DigitalOcean with Sail, add a primary domain name, secure it with a free SSL certificate, install some plugins and themes, work with backups, deploy and roll back you application code.

We’ll also cover some more advanced topics, like working with blueprints in Sail and setting up an SMTP relay service using a Sail blueprint.

LMS created by e-learning experts

Getting Started

Before diving into the command line, you will need a DigitalOcean account. If you already have one, that’s great! If you don’t, then head over to DigitalOcean and sign up, it’ll only take a few seconds.

The Sail CLI needs an API token to work with your DigitalOcean account. So once you’re in your DigitalOcean control panel, head over to the API – Tokens/Keys section, and hit the Generate New Token button. Make sure you’re granting both Read and Write scopes.

Once the token is generated, make sure you copy it and store it in a safe place. We’ll need it later when setting up your Sail project.

Installing Sail CLI

The easiest way to install Sail is through the Homebrew package manager. If you haven’t used Homebrew before, I highly recommend it — it gives you easy access to a lot of great software, without having to deal with dependencies or isolation. It works on Linux, macOS and Windows (via WSL).

Once you get Homebrew, it’s really easy to install Sail CLI:

$ brew install sail

After installing Sail, you can configure your DigitalOcean API token and e-mail address (used for the WordPress admin user):

$ sail config provider-token YOUR_API_TOKEN
$ sail config email YOUR_EMAIL

Next, let’s launch your first project.

Your First Sail Project

Create a new directory and run:

$ sail init

This will take a couple of minutes to provision and configure a new server on your DigitalOcean account, and install a fresh copy of WordPress, using the admin e-mail you provided earlier. A temporary domain and a randomly generated password will be visible on screen after provisioning is complete:

# Success. The ship has sailed!

- URL:
- Login:
- Username:
- Password: FDiD949fPDAzeSiChOYD8TOuze1rQOby (change me!)

Init will also pull down all the WordPress core files from your production server, to the local working directory, as well as create a hidden .sail folder, which contains your configuration, as well as the SSH key to access your server. Make sure these are kept safe.

Working with Domains and SSL

If you don’t have a domain yet that’s fine, you can use the temporary domain provided by Sail for as long as you like, which will also be secured by default with an SSL certificate.

However, if you do have a domain that you would like to use, make sure you first point it to the DigitalOcean name servers:

This is done at your domain registrar, and DigitalOcean has some guides on how to do that for some common ones.

Once the domain has been pointed to DigitalOcean, you can add it to your Sail project:

$ sail domain add

This will add a DNS zone, as well as all the necessary records to point these domains to the server you created earlier. After adding these domains, you can request a free SSL certificate from Let’s Encrypt using Sail:

$ sail domain make-https

And finally set your primary domain:

$ sail domain make-primary

This will perform a full search and replace through your WordPress database and make sure all the links in posts, pages, settings, etc., are correct. You can change your primary domain at any time in the future too.

Working Locally, Deploying and Rolling Back

After initializing a new project, Sail will download all the application files from your production server to your local copy. Often times this is where the majority of application code changes will occur, so make sure you keep your local copy in sync when something changes on production.

You can do this with:

$ sail download

This will pull any changes from your production server, back to your local working copy. If you’d like to only see what changed in production, without downloading these changes, you can add the --dry-run flag and get a list:

$ sail download --dry-run

Similarly, when you’d like to push application code changes from your local working copy to your production server, you can run:

$ sail deploy

This will upload your local working copy as a new release on your production server, and then switch to that release atomically. Similar to downloading, you can add the --dry-run flag to just look at the changes, which are about to be deployed.

If you made a mistake and would like to quickly revert to a previous release, then you’ll be happy to know that Sail keeps around five releases by default on your production server, allowing you to roll back to any of them really fast.

You can get a list with:

$ sail rollback

And perform an actual rollback with:

$ sail rollback RELEASE_NAME

Note that after a successful rollback, the production data will most likely differ from your working copy, so make sure you save any local changes you’d like to keep to a source repository, and don’t forget to sail download, to make sure your working copy is in sync before your next deploy.

Working with Backups

Sail allows you to easily (and quickly!) create full site and database backups:

$ sail backup

If you’re just looking for a database backup:

$ sail db export

These commands will create timestamped backup archives in a hidden .backups directory in the root of your Sail project. Make sure these files are kept secure.

You can restore a database dump with:

$ sail db import .backups/filename.sql.gz

The database file could be any local .sql or .sql.gz file, which means you can use it when migrating existing sites to Sail.

Similarly, if things went really wrong, you can restore a full site backup:

$ sail restore .backups/backup-timestamp.tar.gz

Just like with rollbacks, after a successful restore, it is recommended to run sail download to make sure your local working copy is in sync with production.

WP-CLI, SSH and Server Logs

Sail allows you to invoke WP-CLI on your production server with:

$ sail wp

This means that you can quickly install or update plugins, themes and everything else with WP-CLI:

$ sail wp plugin install woocommerce --activate
$ sail wp theme install storefront --activate

If you need more than WP-CLI, you can get full SSH access to your server with:

$ sail wp ssh

By default this will open a non-root shell to your production server. If you do actually need root access, just add the --root flag and be careful.

With Sail it is also easy to query or follow your various server log entries, which may be very useful for debugging:

$ sail logs
$ sail logs -f --nginx
$ sail logs -f --php


If you find yourself running the same Sail commands over and over again, you’ll be tempted to create some shell scripts to automate some of that stuff. But before you do, check out blueprints in Sail.

Blueprints are YAML files, which define the environment and configuration, where your WordPress application is going to be deployed. They allow you to specify plugins, themes, options, wp-config.php constants and much more.

Here’s a quick self-explanatory example:

  woocommerce: latest
  wordpress-seo: latest

  blogname: ${{ blogname }}
  blogdescription: ${{ tagline }}

  WP_DEBUG: true

- name: blogname
  prompt: Enter a site title

- name: tagline
  prompt: Enter a tagline
  default: Just another WordPress site

This blueprint file can then be applied with:

$ sail blueprint path/to/blueprint.yaml

And this is just scratching the surface. There’s so much cool stuff you can do with blueprints in Sail, in addition to some of the stuff that’s already been done and available as default blueprints.

Default Blueprints

If you’re going to run a production site, you’ll want to make sure it’s secure:

$ sail blueprint fail2ban.yaml

This will install and configure a utility called fail2ban on your production server. This utility will watch your server logs for WordPress login bruteforce attempts, pingback flood attempts, etc., and block them when necessary.

If you’re looking to send e-mail from your server, make sure you setup Postfix:

$ sail blueprint postfix.yaml
> SMTP host:
> SMTP port [587]: 587
> SMTP username:
> SMTP password:
# Applying blueprint: postfix.yaml

This will configure a local SMTP relay for all your outgoing e-mail via wp_mail(), so you don’t need any additional plugins and bloat to deliver your mail effectively. This configuration will work with all major SMTP providers, including Mailgun.

If you’d like to learn more about blueprints and explore default blueprint shipped with Sail, take a look at the blueprints directory in the project’s GitHub repository. The one called sample.yaml is a great start.

LMS created by e-learning experts

What’s Next?

There’s more to Sail than I could cover in this tutorial, but by now you should have a pretty good idea of what it is and how it works. If you’re interested to learn more, feel free to stop by our GitHub repository.

If you have any feedback or suggestions on how to make Sail more useful for you and your workflow, please don’t hesitate to post a comment here or open an issue on GitHub, we’ll be happy to chat about it!

While core features will always be free in Sail, we’re also planning some cool premium features later down the road. Make sure you subscribe on the Sail website if you’d like early access.

If you like this article, don't forget to share it.