Skip to main content
WordPress does not define its own lifecycle commands. Like every application plugin, a WordPress stack is built, started, stopped, inspected, and rolled out with the core sitectl commands, which operate on whichever context is active:
The WordPress application tree is Composer-owned by the downstream checkout. Commit composer.json, composer.lock, and any intentional custom code together; the published libops/wp image supplies the runtime rather than a second authoritative WordPress checkout. sitectl deploy rebuilds from that lockfile while the current stack is still online. After stopping it, deploy starts only WordPress and its required Compose dependencies, waits up to 5 minutes for installation, and runs wp core update-db followed by a cache flush. A database-update or cache failure stops the deploy; only a successful migration is followed by the full-stack start and bounded 10-minute health wait. Before changing WordPress core, plugins, or themes, back up MariaDB and the wordpress-uploads volume and test their restore. A successful image build does not prove that the database update or site behavior succeeded. sitectl wp ... is reserved for WordPress-specific operations. Use WP-CLI, Composer, plugin and theme maintenance, and core, cache, and database helpers. General lifecycle stays in the core CLI so the same operational contract applies to every stack. See sitectl create, sitectl compose, and sitectl deploy for the full lifecycle reference.