Rudel
Environments

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=json

wp 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-1234

Use 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 --protected

Apps use the matching app command:

wp rudel app update demo-1234 --owner=dennis --labels=production,client-a --protected

These updates are not cosmetic. Ownership, labels, purpose, and protection are what make cleanup, automation, and operator reporting practical later.

Read runtime status

wp rudel status

That 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 --merged

Use --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 --force

Destroy an app:

wp rudel app destroy demo-1234 --force

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

On this page