WPCloud Deploy Documentation

Requirements

Using WP CLOUD DEPLOY to deploy WordPress Servers and Sites requires the following: An existing WordPress site where you can install the plugin.  That site needs to meet the following requirements:

  • WordPress 5.4 or later
  • PHP 7.4 (PHP 8.0 support coming soon)
  • WP CRON enabled and working
  • Ubuntu 18.04 or later
  • Port 22 must be open (certain existing hosts block port 22 on their WordPress servers)
  • If a firewall is installed it must not block the REST API 
  • If a firewall is installed it must allow connections from IPs from your cloud provider(s)

View more information about requirements


PHP Configuration Tweaks

The PHP configuration for the server on which WPCloud Deploy is installed will need some tweaks to handle long running PHP processes:

  • Increase your php_max_execution_time to at 180 seconds or, better yet, 300 seconds.  Though, if you use a free proxy like Cloudflare, any amount you set over 100 seconds is ignored since Cloudflare’s proxy times you out at 100 seconds.

You will NOT be able to deploy a server unless this task is completed!

Web Server Configuration Tweaks

Timeouts

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:

FOR NGINX:
    Set your fastcgi_read_timeoutclient_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.


PHP Buffers

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;
fastcgi_buffer_size 64k;
fastcgi_busy_buffers_size 64k;

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_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

If you’re unsure, it does not hurt if you add both sets of directives to the NGINX configuration(s).


Other Server Checks.

Finally please verify that the LibSodium library is installed on the linux server.  Most Ubuntu installations already have this library installed but some other servers might not have it.  LibSodium is used by the PHP process that securely connects to your server over SSH.

Local Installations

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.

WP CRON

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!

Firewalls & Proxies

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:

/wp-content/plugins/wp-cloud-deploy/includes/core/apps/wordpress-app/scripts/v1/raw/

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-appIf 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:

/wp-content/plugins/wp-cloud-deploy/includes/core/apps/wordpress-app/scripts/

 

Share: