Using WPCLOUDDEPLOY to deploy WordPress Servers and Sites requires an existing WordPress site where you can install the plugin. That site needs to meet the following requirements:
The PHP configuration for the server on which WPCloudDeploy is installed will need some tweaks to handle long running PHP processes:
You will NOT be able to deploy a server unless this task is completed!
The webserver on which WPCloud Deploy is installed might need some tweaks to handle long running processes. If you are seeing strange behavior then you will need to adjust the following settings:
Set your fastcgi_read_timeout, client_header_timeout and client_body_timeout values in your nginx configuration file to 600 seconds or more.
FOR NGINX used as a proxy in front of an APACHE server:
Set your proxy_read_timeout value in your nginx configuration file to 600 seconds or more.
FOR APACHE Servers:
Set your TimeOut value in your .htaccess file to 600 seconds or more.
For certain operations such as copying a website to another server, you might need additional php buffers.
For FASTCGI under NGINX
You’ll need to add the following directives to the fastcgi configuration after the fastcgi_pass directive:
fastcgi_buffers 16 32k;
You can, of course, increase these values as needed.
You will know if you need these directives if you see something similar to the following in your web server error logs:
29579#29579: *48380 upstream sent too big header while reading response header from upstream
Some configurations that pass data to the PHP process differently might need the following added to the NGINX server or location blocks instead:
proxy_buffers 4 256k;
If you’re unsure, it does not hurt if you add both sets of directives to the NGINX configuration(s).
Finally please verify that the LibSodium library is installed on the linux server. Most Ubuntu installations already have this library installed but some servers might not have it. LibSodium is used by the PHP process that securely connects to your server over SSH.
You cannot use a WordPress installation that is on your personal computer. This is because servers need to call back into the plugin in order to update it of the status of operations. Most local installations are not accessible from the internet, are behind firewalls or do not have public DNS records.
We strongly suggest that you use a LINUX cron and disable WP CRON. This is because WP CRON only fires if the site has traffic and chances are, the site you’re running this on will not have a lot of traffic. Set your LINUX CRON to a 1 minute interval.
If you do decide to use the native WP CRON process, it is very important that you make sure it is working and firing every 1 minute. This is because we use the CRON process to poll the server in order to figure out the status of operations and when operations are completed as well as to pull log files and submit new commands as needed.
You will get some very very strange behavior and long delays if your WP CRON process isn’t firing very often!
If WP-CLI is installed on your server we recommend you go one step further and use it to activate our better cron process.
If you place your WPCD server behind a firewall or proxy such as CloudFlare then there are certain things you need to enable or double-check:
1. Please make sure that the following folder is whitelisted so that your new servers can access it:
But it’s probably easier to just allow all-access to it – it’s just text files in there that happen to contain our bash scripts. These scripts are part of what makes stuff happen – such as installing WordPress on your server.
2. You will also need to white-list the call-back endpoints or enable all REST API access (if they’re disabled.) Our REST API endpoints all start with or contain /wp-json/wordpress-app. If these endpoints are blocked then your new servers will not be able to communicate with WPCD.
3. You should also make sure that following folder is always available to every server IP you’re managing: