CLI Reference
Rudel publishes its command surface under wp rudel by default. The easiest way to understand it is to follow the same split Rudel uses everywhere else: sandboxes live at the top level, and long-lived app operations live under app.
That gives you a command tree that feels predictable:
wp rudel ...for sandbox lifecyclewp rudel app ...for app lifecycle
You can rename only the root command with RUDEL_CLI_COMMAND before Rudel boots. That changes the operator-facing WP-CLI namespace, but not the runtime model.
Core commands
wp rudel create
Create a sandbox. This is the command you use when you want a new disposable multisite site for change work.
wp rudel create [--name=<name>] [--git=<remote>] [--template=<template>] [--clone-db] [--clone-themes] [--clone-plugins] [--clone-uploads] [--clone-all] [--clone-from=<id>] [--owner=<owner>] [--labels=<labels>] [--purpose=<purpose>] [--protected] [--ttl-days=<days>] [--expires-at=<timestamp>] [--type=<type>]Rudel creates sandboxes as multisite sites. There is no engine choice anymore, only different ways to seed the initial content and metadata. Each created sandbox also gets its own local wp-content, which becomes the canonical code and file tree for that environment.
wp rudel list
List sandboxes. This is the operator view of the Rudel environment registry rather than WordPress's raw wp site list output.
wp rudel list [--format=<format>]wp rudel info
Show sandbox details, including lifecycle metadata and Rudel-specific context that does not belong in core multisite tables.
wp rudel info <id> [--format=<format>]wp rudel update
Update sandbox metadata and policy. This is where you change ownership, labels, expiry, and protection after creation.
wp rudel update <id> [--owner=<owner>] [--labels=<labels>] [--purpose=<purpose>] [--protected] [--unprotected] [--ttl-days=<days>] [--expires-at=<timestamp>] [--clear-expiry]wp rudel destroy
Destroy a sandbox permanently. Rudel removes the environment record, the generated directory, and the multisite site that backs it.
wp rudel destroy <id> [--force]wp rudel status
Read Rudel runtime status. This is the first command to run when you need to verify installation, bootstrap health, or base directory setup.
wp rudel statuswp rudel cleanup
Clean up sandboxes by policy or merged-branch state. This is the operational counterpart to Rudel's disposable sandbox model.
wp rudel cleanup [--dry-run] [--max-age-days=<days>] [--max-idle-days=<days>] [--merged]wp rudel logs
Read, clear, or follow a sandbox debug log. Sandboxes are expected to be noisy during change work, so Rudel makes log access a first-class command.
wp rudel logs <id> [--lines=<lines>] [--follow] [--clear]Recovery points and templates
Rudel uses different recovery models for disposable and durable environments. Sandboxes get snapshots. Apps get backups and deployment history.
wp rudel snapshot
Create a sandbox snapshot.
wp rudel snapshot <id> --name=<name>wp rudel restore
Restore a sandbox snapshot.
wp rudel restore <id> --snapshot=<name> [--force]wp rudel template save
Save a sandbox as a template.
wp rudel template save <id> --name=<name> [--description=<description>]wp rudel template list
List saved templates.
wp rudel template list [--format=<format>]wp rudel template delete
Delete a template.
wp rudel template delete <name> [--force]Git workflow
Git commands are optional, but they become important once a sandbox is carrying real code changes in worktree-managed themes or plugins.
wp rudel push
Push sandbox changes to a tracked Git remote.
wp rudel push <id> [--git=<remote>] [--message=<message>] [--dir=<dir>]App commands
Everything under wp rudel app ... is about the long-lived side of the system. Apps are still multisite sites, but they accumulate operational metadata that sandboxes usually do not keep for long.
wp rudel app create
Create an app.
wp rudel app create --domain=<domain> [--name=<name>] [--clone-db] [--clone-themes] [--clone-plugins] [--clone-uploads] [--clone-all] [--clone-from=<id>] [--git=<remote>] [--branch=<branch>] [--dir=<dir>] [--owner=<owner>] [--labels=<labels>] [--purpose=<purpose>] [--protected] [--ttl-days=<days>] [--expires-at=<timestamp>]Use --git, --branch, and --dir when the app should carry one tracked code source. That tracked source becomes the default Git context for app-derived sandboxes and deployment history.
The --domain value is also the app's canonical Rudel URL. wp rudel app info and app deploy history report that primary domain even though the backing multisite site still exists underneath. On local networks that run on a non-default port, the rendered canonical URL keeps that port as part of the reported app URL.
wp rudel app list
wp rudel app list [--format=<format>]wp rudel app info
wp rudel app info <id> [--format=<format>]wp rudel app update
wp rudel app update <id> [--owner=<owner>] [--labels=<labels>] [--purpose=<purpose>] [--protected] [--unprotected] [--ttl-days=<days>] [--expires-at=<timestamp>] [--clear-expiry] [--git=<remote>] [--branch=<branch>] [--dir=<dir>] [--clear-git]This is also where you change or clear the app's tracked Git source after creation.
wp rudel app destroy
wp rudel app destroy <id> [--force]wp rudel app create-sandbox
Create a sandbox from an app.
wp rudel app create-sandbox <id> [--name=<name>] [--owner=<owner>] [--labels=<labels>] [--purpose=<purpose>] [--protected] [--ttl-days=<days>] [--expires-at=<timestamp>]If the source app tracks a Git remote, branch, and directory, the derived sandbox inherits that metadata automatically.
If the source app has a primary domain, Rudel also rewrites cloned site state from that app domain into the sandbox URL so local change work stays isolated. The derived sandbox still uses its own local wp-content; deploying back later replaces the app's local state, not some shared network code directory.
wp rudel app backup
wp rudel app backup <id> --name=<name>wp rudel app backups
wp rudel app backups <id> [--format=<format>]wp rudel app deployments
wp rudel app deployments <id> [--format=<format>]wp rudel app restore
wp rudel app restore <id> --backup=<name> [--force]wp rudel app deploy
wp rudel app deploy <id> --from=<sandbox-id> [--backup=<name>] [--label=<label>] [--notes=<notes>] [--dry-run] [--force]wp rudel app rollback
wp rudel app rollback <id> --deployment=<deployment-id> [--force]wp rudel app domain-add
wp rudel app domain-add <id> --domain=<domain>wp rudel app domain-remove
wp rudel app domain-remove <id> --domain=<domain>Removing the current primary domain promotes the next mapped domain and updates the app's canonical URL.
If you are learning the command surface from scratch, the simplest mental model is this:
- create, inspect, and dispose of change environments at
wp rudel ... - create, back up, deploy, and restore long-lived sites at
wp rudel app ... - use snapshots for sandboxes and backups for apps
That model stays consistent across the entire CLI.