dbb-wp-cli

dbb-wp-cli runs one WP-CLI command on a WordPress app that Coolify is already running. It starts the official wordpress:cli-2.12.0-php8.4 image, attaches that app’s files and network, and removes the container when the command exits. It does not listen on a port, and it is not installed on the host.

The script is platform/wordpress/dbb-wp-cli. The runbook, with the same rules in longer form, is platform/wordpress/README.md.

Usage

From the repo root:

platform/wordpress/dbb-wp-cli astrazeneca-cll-website-dev core version
platform/wordpress/dbb-wp-cli astrazeneca-cll-website-dev core is-installed
platform/wordpress/dbb-wp-cli astrazeneca-cll-website-dev option get blog_public
platform/wordpress/dbb-wp-cli --list
platform/wordpress/dbb-wp-cli --all core version
platform/wordpress/dbb-wp-cli --all --env staging core version

The first argument is the Coolify application name or its uuid. --list prints the name, Coolify environment, and uuid. --all runs the same command on every matched app. Each line is prefixed with [<name>]. A command that prints nothing still prints the name. A failure also prints [<name>] exit <status>. If any site fails, the command exits non-zero after the other sites have run.

--env is development, staging, or production. It applies to --list and --all only.

One app, with no --all, prints WP-CLI’s own output and returns WP-CLI’s exit status.

Production writes

A command is a read when, after its global flags, one of its words is get, list, status, is-installed, version, check, check-update, verify-checksums, has-command, help, or info. wp --info and a bare wp are reads.

Anything else is a write. That includes core update, option update, search-replace --dry-run, db query, and eval.

The environment is the Coolify environment name. A write on production does not start Docker unless the command line includes --yes-production. Development and staging do not need that flag. --yes-production on a read changes nothing.

platform/wordpress/dbb-wp-cli-test.sh checks this rule. It does not call Docker or Coolify.

How a site is found

An application is a WordPress app when Coolify has a non-preview environment variable named WORDPRESS_DB_HOST. That is the database host the official WordPress image reads.

The running container is the one labelled coolify.applicationUuid for that app, with coolify.pullRequestId=0. The throwaway container joins that app’s Docker network and mounts its /var/www/html volume. Every WORDPRESS_* variable is copied from the running container, because wp-config.php reads the database settings and the salts from the environment. The Coolify API omits those values. The script does not print them, log them, or write them to a file.

Database backups

The AstraZeneca dev and staging MariaDB databases, and myemissions-db-dev, use the same Coolify schedule as Postgres: 02:00 UTC, dump all, local copies only, seven copies, fourteen days. Off-site S3 is off. The runbook section is Database backups.