Home › How it works
How the platform works
This page is for readers who want to know what runs their site. If you have a question it doesn’t answer, ask me.
The short version
Every site runs on Google Cloud in the London region. Visitors reach it through one global HTTPS load balancer, which serves images from Google’s content delivery network, sends admin pages through Google sign-in and passes everything else to your site’s containers. The platform hosts WordPress sites, static sites and custom apps, and each has its own isolated space and its own certificate.
The whole platform is defined as code in Terraform, so I can review every change before it’s made and rebuild any part of it.
Where sites run
WordPress sites and apps run on Google Kubernetes Engine in Autopilot mode, where Google manages the servers underneath. Each site has its own Kubernetes namespace. Network policies stop a site from reaching other sites or the platform’s internal services. Containers run without root access, and the platform keeps passwords and keys in Google Secret Manager.
Production WordPress sites run as two copies. If one stops or its server is replaced, Kubernetes starts a new copy while the other carries on serving visitors.
The front door
All traffic arrives at a single Google load balancer. It handles HTTPS with Google-managed certificates and accepts TLS 1.2 or newer.
- Requests for the WordPress login and admin pages go through Google’s Identity-Aware Proxy, which asks for a Google sign-in from a listed account before the request reaches WordPress.
- Requests for media go to Google’s content delivery network, which serves cached copies from Cloud Storage.
- Everything else goes to the site’s containers, after Google Cloud Armor has filtered out common attacks.
Who reaches what
Every night: database, files and media backed up, kept 28 days.
Static sites are served straight from Cloud Storage through the content delivery network, with any private sections behind Google sign-in. The load balancer itself answers spare domains that redirect or show a parked page, with no server behind them.
Databases and files
WordPress databases run on MariaDB on a dedicated Google Compute Engine server. Each site has its own database and its own database user, and can’t read any other site’s data. WordPress files live on network storage, so they survive a container restart, and uploads are copied to Cloud Storage for the content delivery network. Databases and files sit on their own disk, separate from the operating system.
Custom apps store their data in Google Firestore.
Caching
Memcached holds WordPress object cache data, which cuts the number of database queries for each page. A page cache serves finished pages without running PHP. Google’s edge locations cache images and downloads.
Hardening
The web server refuses requests for hidden files, readme files and PHP files in the uploads folder, and blocks XML-RPC unless a site needs it. PHP on every WordPress site can only open files inside that site’s own folders, so a flaw in a plugin or in WordPress itself has little else to reach. The platform removes secrets from logs before it stores them.
Backups
Every night the platform writes a database dump, a file archive and a copy of the media library for each site to a versioned Cloud Storage bucket, and keeps them for 28 days. It backs up app data in Firestore daily and keeps that for 14 days.
Staging sites that sleep
Development and staging sites scale to zero with KEDA, a Kubernetes autoscaler. After 5 minutes with no visitors a dev site stops using any resources. The next request wakes it, usually in about 45 seconds. Production sites stay running all the time.
DNS and email
Domains I host live in Google Cloud DNS and are signed with DNSSEC. I keep the records your site and email depend on in code. Everything else you can edit from the dashboard, where each change is stored as a version you can restore. An hourly check compares each editable zone with what it should contain.
Every hosted domain has SPF, DKIM and DMARC records. The platform collects the providers’ DMARC reports every hour, and a daily review decides when a domain is ready to tighten its policy. A separate hourly check confirms the published records still say what they should.
Mail from websites, such as forms and notifications, goes out through a transactional email provider. Sending as a person from your own domain goes through a separate relay with its own DKIM signature and bounce domain, so it passes DMARC.
Monitoring
A checker running in another Google region, on a different continent, loads each site’s health check and home page every 5 minutes, keeps 90 days of results and alerts me after three failures in a row. An external service checks sites from several locations, and public status pages show the results to clients who want them. The platform also alerts me to unhealthy backends, unusual log volume and database or cache problems.
What this means for your site
I designed this platform and I answer the support tickets, so the person who reads your ticket knows every layer of it. If a container fails, a new one starts within seconds. A broken plugin on another site can’t reach your files or your data. Your site, database and backups are held in Google Cloud’s London region.
Get in touch
Tell me what your site does and where it’s hosted now. I’ll reply within 24 hours with what moving it would involve and what it would cost. If you’d rather talk, call 020 3422 9767.
Christian Ashby
Replies within 24 hours