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.shafter 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.