Self-hosting a WordPress blog gives you the ultimate control over your website and database. However, you may want to utilize cloud IaaS or PaaS offerings to provide the lower-level infrastructure (machines, network, or even the webserver). Google provides resources for running WordPress on Google Cloud Platform, but there is very little upfront information about the costs of the different options. GCP’s complex pricing (with Always Free quota and sustained-use discounts), along with some hidden costs in some configurations, made it difficult to predict the final monthly cost.
Knowing the price of hosting a WordPress blog on Google Cloud Platform is important, because small-time bloggers are going to be comparing these options against options that cost less $5 a month or even nothing (e.g. the WordPress.com personal and free plans, or even jumping blogging platform completely to Medium or similar).
I’ve recently been through the exercise of measuring the costs of running WordPress on GCP with this blog. The summary of the dominant costs is:
|Configuration||Breakdown||Minimum Cost (USD) per month|
|App Engine + Cloud SQL
10GB-months low-cost storage ($1.35)
|App Engine + GCE + VPC
|App Engine + exposed GCE
|free App Engine + free GCE
- $0 prices assume you’re not already consuming your GCP “Always Free” quota.
- There are some additional costs not included in the table (storage and network), but they were < $0.10/month for me.
- I’m not counting Google’s $300 “free trial”, which only lasts 12 months.
When choosing configurations, my requirements were:
- need to securely serve Defective Semantics (a low traffic WordPress blog) and some static assets from a vanity domain
- can tolerate occasional outages or service degradation
- <200ms RTT from Australia (i.e. for me)
- be as cheap as possible!
All but the last of the configurations below used the
asia-east2 region. I chose this because it’s close to me, and the different services (App Engine, Cloud SQL, Compute Engine) were all available there. It’s a relatively expensive region compared to the US, without even taking into account US-only free quota.
App Engine + Cloud SQL
In this configuration, the frontend runs on App Engine while the database runs on Cloud SQL, as described in Google’s tutorial.
I tried to choose the minimum/cheapest options for Cloud SQL (no high-availability, no automated backups). I also had to try a few different region/zone combinations until the instance was created without an error (the list of available regions in Cloud Console is a superset of the regions where creation will succeed).
Fitting within the free quota will also require tuning the automatic_scaling parameters so that App Engine does not use more than 1.2 instances on average (i.e. it should only run 1 instance most of the time).
App Engine + GCE + VPC
In this configuration, I continue to run the frontend on App Engine. However, instead of using Cloud SQL to host the database, I use a minimal (
f1-micro, non-preemptible) GCE instance with Debian and MariaDB installed.
For App Engine to connect to the database privately, I also had to set up Serverless VPC Access. The VPC connector is charged as 1 f1-micro instance per 100Mbps throughput, and the minimum throughput is 200Mbps.
App Engine + exposed GCE
Like the previous configuration, but instead of connecting to the GCE instance privately using VPC, have mysqld listen on an external TCP port on the GCE instance. This leaves the mysqld much more exposed to abuse. There’s some additional setup overhead (reserving a static IP, setting up encryption), maintenance overhead (watching you don’t get pwnd), but it is more than $10/month cheaper.
It’s also an option to run a webserver on a single GCE instance with the database, and not use App Engine at all. The biggest thing I missed from App Engine wasn’t the scaling, but App Engine’s managed SSL certificates.
free App Engine + free GCE
As with the App Engine + exposed GCE configuration, but move everything to a region with App Engine and Always Free GCE availability. Currently only the
us-east1 regions satisfy these constraints simultaneously.
The biggest pain with moving to the US is that it’s impossible to change the region for an existing App Engine project, so it requires a bunch of messing around to recreate configurations in a different project. Therefore, it’s best to decide if you want free hosting before you create the AppEngine project.
Performance and Reliability
The configurations above use
f1-micro instances to minimize costs. These classes are sufficient for most operations, e.g. for serving pages at low (<1) QPS. However, the frontend tends to be memory-constrained for particular operations (e.g. image thumbnailing), where it requires an
F2 instance class (App Engine) or
g1-small (Just GCE configuration) to avoid over-utilization.
While I avoided the US regions in most configurations to keep latency down, SSH from Sydney to
us-central1 actually turned out to be okay. If your readers are far from the US, they’ll incur some additional (order 100ms) latency by serving from the US regions with free quota, compared to the more expensive local regions.
In order to get costs down, some configurations expose the mysqld server on the internet. This will not necessarily give attackers access to the server, but potential vulnerabilities in mysqld itself could allow attackers to access the database or even execute code as the mysqld user. It may also attract DoS attacks.
- While it’s possible to have an almost-free self-hosted WordPress blog on Google Cloud Platform, it’s only possible in
f1-microinstances may be overutilized when processing images, but are otherwise sufficient for posting and reading a low-traffic WordPress blog.
- connecting App Engine to a GCE database via VPC is triple the cost of connecting via the internet!