A WordPress site rebuilt to deploy itself on Cloud Run

Confidential · DevOps

The business said

  • “SSH in and copy the new theme files onto the live server again”
  • “Hire someone to babysit the one machine it all runs on”
  • “Keep re-entering every content change by hand in production”
  • “Snapshot the whole box and hope it restores cleanly”
  • “Make every change build itself and ship, and let content be authored once”
A website is not a server you log into and edit in place. It is an image you build once and promote, with content authored once instead of twice.

A containerized WordPress on Cloud Run, shipped by a Google Cloud Build pipeline

This one was pure operations. A busy marketing site ran as a single AWS EC2 instance that held everything at once: the web server, the database, and every uploaded image sitting on the machine's own disk. The entire website platform, core and plugins and all, was checked into one repository, so there was no line between the code the team owned and the software underneath it. There was no real deploy. A script copied freshly built theme files onto the running machine over SSH, and every other change was made by hand on a live server. Worse, the customer kept two environments, staging and production, and because the content lived inside each box, every article and every edit had to be entered twice: once to preview it in staging, and again to publish it in production.

We rebuilt the site as an immutable container with a disposable runtime. Google Cloud Build assembles one image with the platform, the plugins, and the theme all baked in at build time, pushes it to the registry, and rolls it onto Cloud Run, which scales to zero when no one is visiting. Paid plugin license keys are pulled from Secret Manager as build secrets and never written into an image layer. The mutable state moved out of the box: the database onto managed MySQL, the media onto Google Cloud Storage. Adding or updating a plugin stopped being a click on a live server and became a one line change to a manifest, followed by a rebuild and redeploy. Staging redeploys automatically on every push, and production sits behind a manual approval, so nothing reaches the live site until a person clicks Approve.

Then we fixed the double authoring. Structural changes, meaning database schema and theme settings, travel as numbered migrations that every deploy applies automatically and records against a version marker, so the two environments never drift apart. Editorial content is written once, in staging. A promotion step then clones the staging database into production, everything except the user accounts, rewrites the site addresses and media locations so no link breaks, and syncs the media across. Before it touches production it takes a fresh backup as the rollback point. There are two ways to ship: a full code and content release behind the approval gate, or a content only promotion the team runs by hand when they just want the day's edits live. Either way the work is done once in staging and production is replicated from it.

The result is a website that behaves like software instead of a pet server. Shipping a change is a build and a promotion, not an SSH session. Editors author in one place and publish with one action instead of retyping their work into a second environment. The single machine that held the code, the data, and the uploads together, with no way to deploy but to copy files onto it, is gone.

  • One EC2 box held it all, before
  • CI/CD, was manual copy, deploy path
  • Cloud Run, scales to zero, runtime
  • approval gated, prod releases
  • once, not twice, content authored
  • backed up first, every promote