Managing Environments
After Rudel is installed, most day-to-day operations are simple operator tasks: inspect what exists, update metadata, check runtime health, clean up what is stale, and destroy environments deliberately when they are no longer needed.
List sandboxes
wp rudel list
wp rudel list --format=jsonwp rudel list is the best high-level view when you care about Rudel metadata such as ownership, protection, or source lineage. If you only care about raw site URLs, use wp site list alongside it.
Inspect a sandbox
wp rudel info alpha-1234Use info when a name alone is no longer enough and you need to see the full environment record.
Update metadata
wp rudel update alpha-1234 --owner=dennis --labels=qa,client-a --protectedApps use the matching app command:
wp rudel app update demo-1234 --owner=dennis --labels=production,client-a --protectedThese updates are not cosmetic. Ownership, labels, purpose, and protection are what make cleanup, automation, and operator reporting practical later.
Read runtime status
wp rudel statusThat shows bootstrap installation, runtime directories, and current counts. It is the first command to run when you need to confirm that Rudel itself is healthy before investigating a specific environment.
Cleanup
Sandboxes are meant to be disposable, so cleanup is part of the normal operating model rather than an emergency command.
wp rudel cleanup --dry-run
wp rudel cleanup --max-age-days=14
wp rudel cleanup --mergedUse --dry-run first whenever you are applying policy broadly. It keeps cleanup predictable and makes it easier to tune expiry or merge-based rules before you remove anything.
Destroy environments
Destroy a sandbox:
wp rudel destroy alpha-1234 --forceDestroy an app:
wp rudel app destroy demo-1234 --forceDestroying an environment removes its Rudel records, multisite site, and the
full environment-local file tree under that generated directory, including the
cloned wp-content. That is why the distinction between sandboxes and apps
matters: sandboxes should be easy to remove, while apps usually deserve a
backup or deploy-aware recovery point before anything destructive happens.