Getting Started

Getting Rudel running is straightforward once the network shape is correct. The main requirement is a WordPress multisite network that runs on subdomains. From there, Rudel installs its runtime bootstrap, creates real sites for sandboxes and apps, gives each one its own cloned wp-content, and stores its operational metadata in WordPress tables.

Prerequisites

Before installing the plugin, make sure the host WordPress instance can support the kind of sites Rudel is going to create:

• WordPress multisite is enabled
• the network uses subdomains, not subdirectories
• you can write to wp-config.php

Rudel expects that foundation to be in place before installation. The sites it creates use the same URL contract as the rest of the network, so once Rudel is installed you are working with normal multisite sites directly through their own site URLs.

Install Rudel

Via Composer

composer require rudel/rudel
wp plugin activate rudel

Via zip

wp plugin install rudel.zip --activate

Verify the runtime install

On activation, Rudel installs an early runtime bootstrap into wp-config.php. That gives it one guaranteed place to wire itself in before WordPress finishes booting.

wp rudel status

If status is clean, the bootstrap is in place, the runtime tables are available, and Rudel can manage the network normally.

Create a sandbox

Sandboxes are the disposable side of Rudel. Use them for feature work, QA, debugging, demos, migrations, and any workflow where you want to change site state freely and throw it away later if needed.

wp rudel create --name=alpha

That command creates three things together:

1. a real multisite site
2. a Rudel environment record
3. a generated environment directory with scoped tooling, a cloned wp-content, and other environment-owned files

To see the browser URL WordPress assigned, ask WordPress directly:

wp site list --fields=blog_id,url

You can then run commands directly against that site:

wp --url=http://alpha.localhost option get siteurl

Or work from the generated environment directory, which gives you a scoped wp-cli.yml plus the environment-local files Rudel manages directly for that site, including the cloned wp-content, bootstrap files, logs, snapshots, backups, and workspace artifacts:

cd /path/to/wp-content/rudel-environments/alpha-1234
wp option get siteurl

Create an app

Apps are the stable side of the lifecycle. They are also real multisite sites, but Rudel treats them as long-lived runtime targets that can accumulate backups, domain metadata, and deployment history over time.

wp rudel app create --name=demo --domain=demo.example.test

The --domain value becomes part of the Rudel app metadata. The runtime site also shows up through normal multisite tools such as wp site list. WordPress owns the site itself, the app keeps its own environment-local wp-content, and Rudel owns the lifecycle around both.

If the app should also carry one tracked Git code source, add it at creation time:

wp rudel app create --name=demo --domain=demo.example.test --git=https://example.test/demo-theme.git --branch=main --dir=themes/demo-theme

That tracked remote, branch, and directory are then inherited automatically when you create sandboxes from the app.

Next steps

From here, the next useful pages are:

• Creating Environments for clone options, templates, and Git seeding
• Apps for the long-lived site lifecycle
• Snapshots for the recovery model
• Runtime State for where Rudel stores operational data
• CLI for the full command surface