Deploying a Highly Available WordPress Website on GCP

By Mesue Collins Asibong • Cloud Engineering

Traditional WordPress deployments often rely on a single server, creating a single point of failure. In this tutorial, we will architect and deploy an enterprise-grade, stateless WordPress infrastructure on Google Cloud Platform that can scale to millions of visitors while maintaining 99.9% availability.

Enterprise Stateless WordPress Architecture

graph TD subgraph "Google Cloud Platform" LB[Global External Load Balancer]:::gcp subgraph "Managed Instance Group (MIG)" VM1[WP Node 1]:::vm VM2[WP Node 2]:::vm VM3[WP Node N...]:::vm end subgraph "Managed State Layer" DB[(Cloud SQL MySQL)]:::db Cache[(Cloud Memorystore Redis)]:::db Media[(Cloud Storage Bucket)]:::db end LB --> VM1 LB --> VM2 LB --> VM3 VM1 & VM2 & VM3 -->|JDBC| DB VM1 & VM2 & VM3 -->|Object API| Media VM1 & VM2 & VM3 -->|TCP 6379| Cache end classDef gcp fill:#4285F4,stroke:#fff,stroke-width:2px,color:#fff classDef vm fill:#34a853,stroke:#fff,stroke-width:2px,color:#fff classDef db fill:#f4b400,stroke:#fff,stroke-width:2px,color:#fff

Step 1: Provisioning Managed State (Cloud SQL & Redis)

A stateless architecture requires that no data be stored on the application servers. We first provision our managed database and cache.

# Create Cloud SQL Instance
gcloud sql instances create wp-db-instance \
    --database-version=MYSQL_8_0 \
    --tier=db-f1-micro \
    --region=us-central1

# Create Cloud Memorystore for Redis
gcloud redis instances create wp-cache \
    --size=1 \
    --region=us-central1

Step 2: Externalizing Media to Cloud Storage

WordPress uploads normally go to wp-content/uploads. On GCP, we use the GCS Fuse or a specialized plugin to offload these assets to a bucket, allowing every node in the MIG to see the same media library.

gsutil mb -l us-central1 gs://wp-media-assets-${PROJECT_ID}
gsutil iam ch allUsers:objectViewer gs://wp-media-assets-${PROJECT_ID}

Step 3: Creating the Stateless VM Image

We create a "Golden Image" with Apache, PHP, and WordPress pre-installed, but configured to use environment variables for database credentials. This allows the image to be identical across all scaling nodes.

# Configuration snippet for wp-config.php
define('DB_NAME', getenv('WP_DB_NAME'));
define('DB_USER', getenv('WP_DB_USER'));
define('DB_PASSWORD', getenv('WP_DB_PASS'));
define('DB_HOST', getenv('WP_DB_HOST'));

Step 4: Configuring Autoscaling & Load Balancing

We deploy the image into a Managed Instance Group (MIG). We set an autoscaling policy based on CPU utilization (e.g., scale out when CPU > 60%) and attach a Global HTTP(S) Load Balancer to distribute traffic and handle SSL termination.

gcloud compute instance-groups managed set-autoscaling wp-mig \
    --max-num-replicas=10 \
    --target-cpu-utilization=0.6 \
    --cool-down-period=90

Summary

By decoupling the application (MIG) from the state (SQL, Storage, Redis), we've created a WordPress site that is not only faster but virtually immune to server failures. This architecture is the foundation for any high-traffic enterprise web application on the cloud.