Hosting WordPress on Google App Engine Standard has four big advantages. Google infrastructure is top notch, scaling from zero to anything, increased security and minimal server administration.
Being the world’s most popular content management system, WordPress has no shortage of options for hosting. Popular options range from managed web hosts (cpanel), to dedicated WordPress hosting shops (Kinsta / WPEngine) to a $5 VPS in the Linode or Digital Ocean Cloud.
Running WordPress on Google App Engine while having some big advantages also comes with some serious caveats to consider. Primarily the filesystem that PHP will be running on is read only – this will cause issues with caching plugins and potentially others that need to write to the filesystem. However, the read only aspect is also a security plus as exploits are not be able to write and leave backdoors.
Logical Overview of WordPress on App Engine
As the hosting is going to be more serverless orientated than your typical LAMP stack; I have outlined the logical components for better understanding.
With the configuration shown above you will need to run a local web server for serving the WordPress PHP files to the browser. The SQL connection is made via the Google SQL Proxy to the live MySQL in the Google Cloud SQL instance.
Deployment & Development Workflow
Rather than configuring Apache or nginx you can run a development php server with the PHP command line client only.
$ php -S 0.0.0.0:8080
Run the above from the WordPress installation directory on your development system. sudo is required to use the privileged port 80 otherwise use a high port (8080).
App Engine Standard has a Free Tier (web server & 1GB of traffic, storage). However, note that Google Cloud SQL does not. So there will be minimum charge of about $7 for a micro SQL instance (not recommended for production).
In this configuration it is possible to add content (pages / posts) from the WordPress administration area on the live site. The additional content will update the database and any images can be uploaded through WordPress by using the Google Plugin for Media (saves media in a Cloud Storage Bucket).
Content can also be added to the local dev version of the site, as it is using the same database via the SQL Proxy.
If any changes are made to the theme, css or functions.php; these would be performed on the development host and pushed to App Engine as part of a deploy operation. In this scenario you are operating with a “live” development site as you are still working from the production MySQL database using Cloud SQL.
Getting Started with a SQL Instance
It does not matter if you are installing a new WordPress installation or migrating an existing site your first step is to create a Google Cloud SQL instance of MySQL.
This can be done via the web console or using the gcloud command line.
Select the appropriate tier for your needs. The selected tier can be changed at any time using “edit”, with minimal down time.
Be sure to deploy the App Engine instance and the SQL instance in the same region to ensure the lowest latency between PHP and MySQL.
Once you have a new MySQL instance, create a WordPress database and user the same way you normally would.
App Engine WordPress Config Command (wp-gae)
Using composer we will install the google/cloud-tools package that includes the App Engine WordPress configuration command (wp-gae). If you are on Ubuntu simply apt install composer.
$ composer require google/cloud-tools
This will install the cloud-tools package, that you comes with the wp-gae tool for configuring WordPress to use App Engine.
The wp-gae command will ask you several question in order to set up your Cloud SQL database connection, and then write the required configuration to your wp-config.php configuration file. It also copies the following files into your project directory to allow WordPress to run on App Engine:
app.yaml: The App Engine configuration file that specifies the runtime and static asset handlers.
cron.yaml: The App Engine configuration file that ensures wp-cron.php is run every 15 minutes.
php.ini: For setting PHP configuration in App Engine specific to WordPress.
gae-app.php: The Front Controller, which is required for all App Engine applications.
Download and install WordPress with App Engine & SQL configuration
Running the following will download the latest version of WordPress and configure it to be able to use Google App Engine.
$ php vendor/bin/wp-gae create
Update an Existing WordPress install
If you have an existing WordPress install, you can run the wp-gae command to configure the installation and update wp-config.php for connecting to Cloud SQL.
$ php vendor/bin/wp-gae update path/to/your-wordpress-site
Note this will make changes to your existing wp-config.php so ensure you have a backup available.
Now Deploy to App Engine
Part of deploying to app engine involves determining the instance class you wish to use. Note the difference between automatic scaling (F series) and manual, basic scaling (B series).
From the WordPress root directory on your local development host (where wp-config.php is), run the following:
$ gcloud app deploy app.yaml cron.yaml
App Engine Configuration (app.yaml / cron.yaml)
The two yaml files can be used to configure some things that would normally be done in the web server configuration or htaccess.
Browse to your WordPress Install
If its a new install you should see the WordPress installation wizard, otherwise you should have a working install. If things are not working, use your normal troubleshooting to determine where the problem is occurring.
Using WordPress should now be possible either via the local server or the remote app engine URL. The location for the App Engine URL will be based on your project name and end with appspot.com
Example:
https://wprec-42341.ue.r.appspot.com/
Note the project name at the start, then the region (ue = usa east).
Your next step will be to configure a custom domain for accessing your WordPress installation. The custom domain can be a root domain or a subdomain.
PHP Debug Errors
In the root folder of your installation you will find the php.ini file that can be used to customise how PHP works with your app when deployed.
An example is the PHP Debug functionality:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Any PHP configuration in this file will be set in your App engine production ; ; instances. ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; This PHP configuration is required by WordPress allow_url_include = "1" ; Configures WordPress to allow sufficiently large file uploads upload_max_filesize = 8M ; for debugging purposes only. Please remove for production instances display_errors=Off
Change the display_errors=Off to On to see PHP errors in your WordPress deployment. An easy way to check is to browse to https://$url/wp-settings.php as this will trigger a PHP include error. If errors are off the response will be a blank page.
WordPress Cache on Google App Engine
Using a standard WordPress caching plugin (hyper cache, w3 total cache, wp-supercache) will not work with Google App Engine due to the fact that the filesystem is not writable. This applies when it comes to caching pages, minified css (autoptimize) or javascript.
It is possible to write to
/tmp, this is a small ramdisk, but not usable for the purposes of WordPress.
One possibility is to you use a WordPress Redis caching plugin. This could be configured to access a Redis (Memorystore) instance within Google Cloud. Providing a fast object cache that will seriously reduce the utilization on your database and speed up your site. Note that Redis (Memorystore) on Google Cloud has no free tier, with the cheapest tier around $25 USD / month.
When it comes to costs with the 1GB in the smallest Redis tier, you would likely be able to run multiple sites off a single Redis instance.
Minified CSS & Javascript
In order to increase page speed scores and speed up site load in general many WordPress users use the excellent Autoptimize plugin. This requires filesystem writes, and the files that are generated are customised depending on the browser (mobile / tablet / desktop). This makes the files quite dynamic and means you cannot easily generate the files before deploying to App Engine.
So far the best method I have found for combing these files is to manually edit your theme, commenting out js / css and loading the assets in a manually generated combined + minified file. Take care using this method as you can easily break things.
Conclusion
Using Google App Engine Standard with WordPress is certainly possible and appears to be very fast being hosted on Google Infrastructure. However, it will not be for everyone due to some of the aforementioned limitations.
Thanks to the excellent tutorial and the other Stackoverflow contributors who have allowed me to piece this high level guide together.