There are three real ways to run WordPress on Google Cloud: a Compute Engine virtual machine, often started from a Marketplace image, a containerized WordPress on Cloud Run sitting in front of a separate Cloud SQL database, or a full deployment on Google Kubernetes Engine. None of them are click and it is hosted the way a managed WordPress plan is; each trades a different amount of your own ongoing time for control, and the honest way to choose is to price that time against what you are actually trying to build, not against a marketing page that lists all three as equally simple.
Google’s own product page lists the three paths side by side as though they are interchangeable. They are not, and the difference shows up the first time a plugin needs to write a file to disk on a platform that was designed to be stateless. This post walks through what each path actually involves, where the ops time really goes, and where managed WordPress removes the need to solve the same infrastructure problem three different ways, without inventing any prices for Google’s own services. The goal is picking the right path before building it, not after the file uploads start disappearing.
Table of contents
- Path one: a VM on Compute Engine
- Path two: Cloud Run in front of Cloud SQL
- Path three: GKE
- The part every path shares: the file problem
- What the ops time actually buys you
- Weighing the three paths against a managed plan
- A quick decision list
- How this fits the rest of the stack
- FAQ
Path one: a VM on Compute Engine
The Marketplace image gets a working LAMP-style stack running quickly, WordPress, PHP, and MySQL on a single virtual machine, which is why it is the most commonly tried path. But from that point on, you own a server: operating system patches, PHP and MySQL version upgrades, a firewall configuration, TLS certificate renewal, and backups of both the filesystem and the database, the same recurring list that applies to any self-managed server, WordPress or otherwise. It is the fastest path to something running and the slowest path to something you can stop thinking about.
The recurring VM maintenance is concrete, not abstract: unattended-upgrades or an equivalent needs configuring so security patches land automatically instead of piling up, PHP’s own end-of-life schedule eventually forces a version bump that can break older plugins with no warning beyond a changelog, and a certificate renewal job, typically certbot on a cron schedule, has to keep working silently or the site starts serving a browser warning instead of a page. Disk snapshots, taken on a schedule and tested with an occasional restore, are usually the backup strategy for the whole filesystem and database sitting together on one machine.
Path two: Cloud Run in front of Cloud SQL
This path containerizes WordPress and runs it on Cloud Run, with the database split out into a separate Cloud SQL instance. It scales well for spiky traffic and removes server patching from your list, but WordPress was never designed to be stateless, and that assumption breaks almost immediately: media uploads, and often theme or plugin files, expect to persist on local disk between requests, which a serverless container does not guarantee across restarts or scale-out events. Making this work means redirecting uploads to object storage with a plugin or custom code, on top of wiring up Cloud SQL’s own connection and networking configuration. It is a real integration project, not a deployment.
Concretely, the persistence problem shows up in two separate places that need two separate fixes. Media the visitor sees, images and files uploaded through the WordPress admin, is usually solved by mounting a Cloud Storage bucket into the container as a volume through Cloud Storage FUSE, so wp-content/uploads writes end up in the bucket instead of the container’s own ephemeral disk, or by installing a plugin that rewrites the uploads path to write directly to object storage over its API instead of the local filesystem. Plugins and themes installed or updated through the WordPress admin are the second, less obvious problem: an install triggered through the dashboard writes to wp-content/plugins on whichever container instance served that request, and the next request can land on a different instance that never received the write. Most Cloud Run WordPress setups solve this by baking plugins and themes into the container image at build time and treating the WordPress admin’s own installer as read-only in production, reserving the mounted bucket for user-uploaded media only.
The Cloud SQL side alone adds its own decisions: whether to connect over the Cloud SQL Auth Proxy or a private IP, how connection pooling behaves when Cloud Run scales a container up and down in response to traffic, and how many concurrent database connections a burst of new container instances might open at once. None of this is unsolvable, but it is infrastructure work specific to this path, not something WordPress handles for you the way a single-VM setup implicitly does by keeping everything on one machine.
Path three: GKE
Running WordPress on Google Kubernetes Engine means WordPress pods, persistent volumes to solve the same file problem as Cloud Run, and ingress with TLS termination configured either by hand or through a controller. This is the most capable of the three paths and also the most operationally heavy; it makes sense when WordPress is one workload joining a cluster that already exists for other services, with a team that already operates Kubernetes day to day. It is rarely the right first choice for standing up a single WordPress site from nothing.
The honest test for whether GKE is the right call is whether the cluster would exist regardless of WordPress. If a platform team is already running other services on GKE and WordPress is one more deployment to add, the marginal cost is reasonable. If a cluster would need to be created specifically to host a single WordPress site, the Kubernetes expertise required to operate it safely is a much larger investment than the site itself usually justifies.
The part every path shares: the file problem
Every one of the three paths eventually runs into the same issue: WordPress plugins and core media handling assume a writable, persistent filesystem sitting right next to the application code, and cloud-native compute increasingly does not guarantee that. A VM has it by default until the disk needs resizing or the machine is replaced; Cloud Run and GKE need an explicit answer, whether that is a persistent volume or a redirect to object storage. Teams that skip this step tend to discover it the way described in why uploaded images disappear after a deploy, which covers the same failure mode from the deploy side.
What the ops time actually buys you
The flexibility of running WordPress directly on Google Cloud genuinely matters in specific situations: an infrastructure team that already operates heavily on GCP and wants WordPress sitting beside other GCP-native workloads, unusual scaling or compliance requirements that a generic managed WordPress plan cannot accommodate, or a deliberate choice to own every layer. Outside of those situations, the same ops time is being spent solving problems, the file storage question, the database networking, the certificate renewal, that a managed WordPress plan has already solved once, for every customer, rather than once per project.
Weighing the three paths against a managed plan
Comparing the three Google Cloud paths to each other is the wrong first question for most people; the right first question is whether the reason for choosing Google Cloud specifically is strong enough to justify solving the file-storage and database-networking problems from scratch. For a marketing site, a small business, or a blog, it usually is not, and the honest read of managed WordPress hosting or a cloud WordPress hosting overview makes that comparison concrete rather than abstract.
A quick decision list
- Pick a Compute Engine VM if you want full server control and already operate VMs elsewhere
- Pick Cloud Run plus Cloud SQL if traffic is spiky and you are prepared to solve the media-storage problem properly
- Pick GKE if WordPress is joining a Kubernetes cluster that already exists for other workloads
- Pick managed WordPress if the goal is a working site, not an infrastructure project with WordPress as its subject
How this fits the rest of the stack
Most of the ops time in every Google Cloud path goes toward problems a managed WordPress plan has already solved: file uploads that survive a deploy, a database that is backed up and patched, and TLS handled without a certificate renewal script written by hand. RunxBuild’s managed WordPress adds a file manager for browsing, editing, and uploading without SFTP, and a database browser for tables, rows, and SQL without phpMyAdmin, starting at $3 a month on the Starter plan. The RunxBuild hosting calculator is the fastest way to see what that looks like against a Google Cloud path you would otherwise have to build and maintain yourself.
Useful related references:
- Cloud Run Deploy Basics
- Cloud WordPress Hosting Overview
- Managed WordPress
- The WordPress file manager on RunxBuild
FAQ
Can I host WordPress on Google Cloud for free?
There is an Always Free Compute Engine tier that can run a small WordPress VM within its usage limits, though you still own all the server maintenance, patching, and backup work described above. Cloud Run and GKE do not have an equivalent always-free path for a full WordPress setup.
Is Cloud Run good for WordPress?
It handles spiky traffic well and removes server patching, but WordPress’s assumption of a persistent local filesystem does not match Cloud Run’s stateless containers, so media uploads need to be redirected to object storage separately, which is real integration work rather than a deployment setting.
What is the hardest part of running WordPress on GKE?
Solving the same persistent-storage problem as Cloud Run, but with Kubernetes persistent volumes, plus configuring ingress and TLS termination by hand or through a controller. It is the most capable path and the most operationally heavy of the three.
How much does WordPress on Google Cloud actually cost?
Compute costs vary by path and usage, and this post does not quote Google’s own pricing since it changes and is best checked directly on Google Cloud’s pricing pages. The bigger cost for most teams is the ongoing engineering time, not the infrastructure bill itself.
What is the easiest way to run WordPress without managing servers?
A managed WordPress plan that includes hosting, backups, and a dashboard-based file manager and database browser removes the server, patching, and file-persistence questions entirely, which is the main appeal compared to any of the three Google Cloud paths.