content site workload baseline

WordPress public-site baseline

Keep the database and site files in one recoverable update point, then verify publishing, media, plugins, and public routing after change.

Runtime boundary

Know which services participate before mapping their state.

  1. 01

    WordPress application service

  2. 02

    Database service on a private network

  3. 03

    HTTPS reverse proxy as the public entry point

Persistent-state map

Every state boundary needs a Compose address, a backup rule, and a restore proof.

State 01 · database

Posts, users, settings, and plugin data

Compose evidence
A private database service with an explicit persistent mount and a named export destination.
Backup boundary
Create a database-consistent export at the same recovery point as the site files.
Restore proof
The restored site exposes the expected posts, users, settings, and plugin-owned records.

State 02 · site files

Uploads, themes, plugins, and custom files

Compose evidence
An explicit mount covering the chosen WordPress file boundary; record whether it is wp-content or the full image data path.
Backup boundary
Keep uploads, themes, plugins, configuration files, and custom code paired with the matching database export.
Restore proof
A representative media item loads and the active theme and required plugins operate from the restored files.

State 03 · configuration

Compose, WordPress, proxy, and secret references

Compose evidence
The rendered Compose model identifies configuration and secret inputs without embedding their values.
Backup boundary
Record the rendered model, image references, hostname routing, and access path to required secret material.
Restore proof
The restored site reaches its database, serves the intended hostname over HTTPS, and preserves canonical URL behavior.

Update sequence

Treat an application update as a reversible state transition.

01 · capture

Capture the rollback point

Record the rendered Compose model and current image references, then create one matched database-and-files backup set.

Complete when

The current site can be associated with one dated configuration and recovery set.

02 · quiesce

Control writes

Choose a low-write window and account for publishing, comments, orders, forms, and background activity that can diverge during the change.

Complete when

The acceptable write-loss boundary and update window are explicit.

03 · apply

Apply one bounded change

Review WordPress, plugin, and theme compatibility, change the intended image or configuration boundary, and complete any required database update.

Complete when

The new application and database state start without replacing the rollback set.

04 · verify

Prove the public workflow

Check the public page, administration login, publishing or form path, media upload, permalink behavior, scheduled work, and HTTPS route.

Complete when

The user-facing write and read paths pass before the rollback point expires.

Rollback boundary

Rollback means restoring the previous application model together with its matched database and site-file recovery set; changing only the container image is not a complete state rollback.

Recovery acceptance

A restored container is only the start of the test.

PROOF 01

Content and identity

Open representative posts and confirm an expected administrator or editor can authenticate.

PROOF 02

Write path

Create a disposable draft or exercise the site’s real form or transaction path, then remove the test record.

PROOF 03

Media and extensions

Load existing media, upload one disposable item, and exercise the plugin or theme feature the site depends on.

PROOF 04

Public boundary

Confirm the canonical hostname, HTTPS redirect, permalink route, and background task behavior.

Continue planning

Carry this state and recovery contract into the deployment.

Define the host, exposure, storage, and recovery priority first; then inspect the rendered Compose model and compare every later change against its deployed baseline.

Build this deployment blueprintInspect a Compose model

Existing deployment

Compare the next Compose change before applying it

Editorial record

Maintained by Make Your Own Tools to turn “Validate a deployment” into a defined host, state, exposure, and recovery boundary. The references below provide the technical context for this planning path. Its calculation rules and planning assumptions are documented in the methodology, and affected calculations pass regression checks before the review date advances.

Last reviewed
Evidence set
6 primary references
Read methodology →
Planning scope
Single-host Docker Compose planning for the wordpress public-site baseline, including state inventory, update control, rollback preparation, and restore acceptance.
Next check
Before execution, match the selected application and database release transition against the linked current upstream release instructions.
Docker Compose production guidanceProduction-specific Compose configuration, restarts, ports, logging, and deployment changes.Open source ↗Docker Compose secrets guidanceExplicit secret access and file-backed secret patterns for Compose services.Open source ↗Docker Compose volumes reference sourceMaintainer documentation source for service volume grants and a named-volume backup-access example.Open source ↗WordPress Docker Official Image documentationImage-specific environment, volume, and configuration information for the WordPress Docker Official Image.Open source ↗WordPress backup handbookOfficial WordPress state map for a matched database-and-files backup and restore set.Open source ↗WordPress update guidanceOfficial update workflow covering pre-update backup, file changes, database update, plugins, and post-update checks.Open source ↗