(Full disclosure, I’m employed by Automattic, but I wasn’t paid to write this post).

If you’re looking for a reliable and powerful WordPress hosting solution, one option is Pressable – a managed hosting platform created by Automattic which provides:

  • A managed WordPress installation (core updates and security).
  • SSL certificate provisioning.
  • Automated Content Delivery Network for assets.
  • Page Caching.

A problem with Pressable

Pressable is great in many ways (indeed I use it for this site), but one of the major downsides of the platform is that – as of the time of writing – it does not provide SSH access.

For a developer like me this is a significant barrier, principally because it stops me from using my favourite command line based tools (Deployer, rsync…etc), for deployments.

When I work on a website, however small, I want to be able to run a single command and have my website reliably deployed to my remote host.

Ideally I would also like to be able to:

  • deploy changed files only to minimise deployment time.
  • run build commands – typically npm or composer – to perform post-deploy tasks on the remote destination.
  • have full Atomic deployments with “rollback” capabilities, usually via symlinked release directories.

Regrettably due to Pressable’s lack of SSH support and strict directory structure requirements, little of the above is easily achievable.

This makes Pressable feel outdated and behind the curve when it comes to modern devops tooling.

Pressable and SFTP

Thankfully, despite its limitations on server access, Pressable does provide SFTP access to allow you to upload your files to its servers.

Typically I avoid FTP at all costs. I associate it with the novice deployment practices of my youth, which typically centered around drag and dropping files using GUI interfaces such as Filezilla or Cyberduck.

In my experience trying to handle deployments like this is no fun at all. Humans are simply not good at remembering which files have changed which leads to confusion, missing files and hard to debug deployment errors.

Thankfully there are other ways available to us.

Simple command line deployments to Pressable with rclone

What we need is a command line tool which can automatically detect our latest changes and deploy them to a remote host using SFTP. Whilst it is possible to us SFTP via the command line there are better alternatives. One such is Rclone.

Rclone bills itself as a an “rsync-like” command line program to sync files and directories to and from remote storage locations. Rclone provides a wealth of storage “backends”, one of which is SFTP storage.

Deploying a local WordPress installation to Pressable

For the remainder of this post, I’ll assume you have a local WordPress installation at ~/Sites/yoursite/ with a single Theme and some Plugins which you wish to deploy to Pressable.

Configure Rclone

To get started, install Rclone and configure it using the SFTP “backend” providing your Pressable SFTP credentials.

Note that I named the Rclone remote “pressableremote” but you can name it however you wish so long as you amend the commands below as required.

With Rclone configured, we can now start to deploy our local files to Pressable. Before we begin however, it’s worth recalling some information about Pressable’s servers and filesystem.

Pressable fully manages all WordPress core files (which appear as __wp__ on the server), with only the /wp-content/ directory available to upload user facing content (eg: Themes, Plugins, Uploads…etc).

Therefore for a given site we will typically only need to upload the /themes and /plugins directories to their respective locations on the Pressable server.

With this in mind, we’ll begin with deploying our Theme.

Deploying our Theme

To deploy a Theme residing at /wp-content/themes/sometheme we can use rclone sync which makes files on source and dest identical, modifying destination only.

It has a signature of:

rclone sync localfilepath pressableremote:remotefilepath

In our case this translates into the following command:

rclone sync ~/Sites/yoursite/wp-content/themes/sometheme pressableremote:/htdocs/wp-content/themes/sometheme 

Before we run this blindly however, let’s consider whether there are any files which we don’t want to sync, for example:

  • OS files (eg: .DS_Store and friends!).
  • node_modules directories.
  • Git directories.
  • any unbuilt src files – typically these are assets such as .scss or uncompiled .js.

Luckily Rclone has a --exclude global flag that can be used to exclude files from (almost) any command. Applying these to our example we get:

rclone sync ~/Sites/yoursite/wp-content/themes/sometheme pressableremote:/htdocs/wp-content/themes/sometheme 
    --exclude "**/node_modules/**" 
    --exclude ".DS_Store" 

Note: we’ve also tagged on the --progress flag to give us some visual feedback during the sync process.

Now run this from your local machine and you should see your files transferred to your Pressable server. This may take some time initially as FTP is fairly slow

You can now make changes locally and rerun the command to have the latest files deployed. Best of all, if you remove files locally, then these will also be removed from the corresponding remote location on sync.

Next up, let’s deploy some Plugins.

Deploying our Plugins

Deploying our /plugins directory is largely similar to our Themes.

Running the following command will sync all files with the Plugins directory to the corresponding directory on Pressable:

rclone sync ~/Sites/yoursite/wp-content/plugins/ pressableremote:/htdocs/wp-content/plugins/ 
    --exclude "**/node_modules/**" 
    --exclude "~/Sites/yoursite/wp-content/plugins/jetpack/**"

With this in place we can now install Plugins locally and sync them to Pressable with a single command.

Handling Akismet and Jetpack

You may have noticed the --exclude rules for akismet and jetpack. This is because Pressable includes both Plugins on its platform by default and it is not possible to remove them from the filesystem.

If, like me you have neither Plugin installed locally then the rclone sync command will attempt to delete them from the remote. The resulting error will cause rclone sync to abort any further deletions which may leave unwanted files sitting on the remote file system.

This is explained in the Rclone docs:

Note that files in the destination won’t be deleted if there were any errors at any point.


Therefore (in theory at least) by adding exclude rules to cover Jetpack and Akismet Rclone should ignore these files during the sync thereby avoiding unwanted errors.

Unfortunately however, the above does not seem to work and Rclone still seems to attempt to deploy both Akismet and Jetpack plugins.

I’m currently still trying to find a solution for this. If you are reading this and come up with a fix, please do let me know in the comments.

Putting it all together

Will the above commands you should now be able to deploy your Themes and Plugins to Pressable via the command line. Granted, it’s some way short of being a perfect deployment system but it’s far more robust than drag and drop via Cyberduck!

If you want to take this further and fully automated things, why not create a custom bash script which runs the Rclone commands sequentially. Then you need only run a single command to have all your files deployed – perfect!

I hope in the future Pressable find a way to add SSH support as this would open the door to far better deployment tools. But for now, I hope this helps someone looking to achieve more reliable deployments to Pressable. If that’s you, let me know in the comments.

2 responses to “Deploying WordPress sites to Pressable via the command line

  1. Clever!

    Cyberduck brings back many memories of my start as a web developer 🙂 In the past with hosts who have limited or no SSH support, I remember using services like DeployHQ to do `git` -> FTP deployments.

    I had never heard of Rclone. This seems like a great way to bypass the third-party service and have more fun on the command line. Thanks for the nice write-up!

  2. It’s odd to see a hosting solution that doesn’t allow SSH these days. That said this seems like a nice way of getting around that limitation. I have also used third-party services in the past to deploy over SFTP, but this seems like a much cleaner strategy.

    I agree with the custom bash script that should work nicely. You could even store the config in a YAML file or similar within your git repo.

    Maybe Automattic will develop a tool to help devs deploy via the CLI or add SSH access in the future!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.