Files

2.0 KiB

Operations

Routine commands

docker compose up --build -d
docker compose ps
docker compose logs -f proxy wordpress db certbot
./scripts/prepare-host-volumes.sh
docker compose --profile tools run --rm wp-cli -c 'wp core version'
docker compose down

The proxy healthcheck reaches WordPress, and WordPress health reaches its login route. MariaDB uses its official readiness check. WordPress access logs are disabled while PHP warnings/errors remain visible. NGINX is the request audit trail; apply an explicit retention policy because it contains client metadata.

Updates

WordPress, PHP, MariaDB, NGINX, Certbot, and Playwright use explicit image versions. Review security releases routinely, update pins in a task branch, rebuild, run the full test suite, and deploy. Production disables WordPress web-based file modifications, so image rebuilds are the update path.

Backup and restore

Create database and WordPress file backups in one maintenance window. The default host paths are ./runtime/db, ./runtime/wordpress, ./runtime/letsencrypt, and ./runtime/certbot/www, unless overridden in .env. Backups contain credentials, accounts, contact information, and uploaded media; encrypt them, restrict access, set retention, and store copies off-host.

A restore is destructive. Validate it on isolated volumes, then stop WordPress, restore the database and file volume together, restart, and verify the homepage, media, /wp-admin/, and user accounts.

Known risks

  • Local host directories are not backups.
  • A host-based volume may be unreadable by the application if created with the wrong owner or mode; run ./scripts/prepare-host-volumes.sh after changing paths or image user IDs.
  • SMTP is not configured; WordPress password-reset email needs an external mail service.
  • Admin MFA and network allowlisting are deployment concerns and are not bundled.
  • WordPress plugins expand the attack surface; install only reviewed, maintained, necessary plugins.