Create a server (following the usual process).

Configure the Salt pillar (see existing WordPress sites for an example).


If you are using the www subdomain, then don’t forget to add a redirect e.g. redirect: hatherleigh.info.

Add swap space to a server

Create a MySQL database using fabric, Database.

To view the database on the server:

mysql --user=www_hatherleigh_info --password=MyPassword www_hatherleigh_info


SSL Certificate

Check that a DNS record exists for the domain, then create an SSL certificate:

init-letsencrypt www.hatherleigh.info - /home/web/repo/project/www.hatherleigh.info/live/


The above command has worked perfectly, but if you need to use a DNS challenge, see LetsEncrypt - DNS



wp-config.php is found in the live folder e.g. ~/repo/project/www.hatherleigh.info/live/wp-config.php.

Update wp-config.php:

# update the database details
define('DB_NAME', 'www_hatherleigh_info');
define('DB_USER', 'www_hatherleigh_info');
define('DB_PASSWORD', 'MyPassword');

To override the domain name (for test sites etc), try setting:

define( 'WP_HOME', 'https://www.hatherleigh.info' );
define( 'WP_SITEURL', 'https://www.hatherleigh.info' );


Use the following in wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
// define( 'SCRIPT_DEBUG', true );


define('WP_DEBUG', true); sends debug output to the log files (which is what we want)…


The important thing is to set @ini_set('display_errors', 0);, so the user doesn’t see errors on the screen.


It would be a security issue to log to the wp-content folder. To avoid this issue, our Salt states configure the PHP pool (see php/fpm.conf).


Check memory usage:

atopsar -m

Check your site health, https://www.hatherleigh.info/wp-admin/site-health.php?tab=debug

Filesystem Permissions shows whether WordPress is able to write to it’s own directories.


Follow instructions in postfix (check existing sites to make sure notes are up to date)!

Media Library

Check the upload_path for the Media Library:

mysql> SELECT * FROM wp_options WHERE option_name = "upload_path";
| option_id | option_name | option_value                                                        | autoload |
|        51 | upload_path | /home/web/repo/project/www.hatherleigh.info/live/wp-content/uploads | yes      |
1 row in set (0.01 sec)

This example uses wp_ as the table prefix. This prefix may vary. To find the prefix for your current database:

cat ~/repo/project/www.hatherleigh.info/live/wp-config.php | grep prefix


UPDATE wp_options SET option_value = "/home/web/repo/project/www.hatherleigh.info/live/wp-content/uploads" WHERE option_name = "upload_path";

Swap Space

You may want to Add swap space to a server

Staging / Test Site

The Salt states create a dump- script for live sites and stage- scripts for test sites. The idea is to only allow dump for live sites, so we don’t accidentally stage to a live site.


  • dump- scripts are created for live sites. They save sql and tar.gz files to the /home/web/repo/dump/ folder.

  • stage- scripts are created for test sites (testing: True in the pillar). (to try and prevent us overwriting live sites).

  • The stage- script will restore the tar.gz archive to the live folder for the test site. If a live folder already exists, it will be renamed e.g. /home/web/repo/project/hatherleigh.kbsoftware.co.uk/live-until-20220408-1152


Unless you create a new database for the staging site, the MySQL restore will merge the tables etc…


The scripts for the salt states are in the php folder (base.py, dump.py, README.rst, stage.py).

Command line (wp)

sudo -i -u web
# list
wp --path=/home/web/repo/project/www.protoolz.co.uk/live plugin list
# status
wp --path=/home/web/repo/project/www.protoolz.co.uk/live plugin status