PHP API

Rudel\Rudel is the public PHP surface for runtime context and lifecycle operations.

The public API is intentionally narrower than the internal codebase. Rudel has repositories, managers, and services under the hood, but consumers should not need to learn those details just to answer the common questions:

what Rudel environment is active on this request?
how do I create, update, or destroy an environment?
how do I manage app backups, deploys, and rollback from PHP?

If you are embedding Rudel into another product or building an operator interface, start with Rudel\Rudel before reaching for lower-level services.

Standalone core access

Rudel's DB-backed registry can also be initialized outside WordPress.

That standalone path is for the core metadata layer:

listing apps and environments
reading domains, worktrees, deployments, and policy metadata
updating DB-backed metadata

It is not a replacement for WordPress multisite itself. Site lifecycle operations such as creating, destroying, or rewiring multisite subsites still require a live WordPress runtime.

`Rudel::init( Connection $conn, array $context = [] )`

Initialize Rudel with a standalone DB connection.

The optional $context array currently supports:

environments_dir
apps_dir

Those paths let operator-facing APIs keep reporting the same filesystem context outside WordPress that they would use inside WordPress.

use Rudel\Connection;
use Rudel\Rudel;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Rudel::init(
    $conn,
    [
        'environments_dir' => '/var/www/html/wp-content/rudel-environments',
        'apps_dir' => '/var/www/html/wp-content/rudel-apps',
    ]
);

`Rudel::ensure_schema()`

Ensure the Rudel runtime tables exist for the active store.

That is the standalone equivalent of letting the WordPress plugin bootstrap create the tables during normal install/runtime setup.

For the full model and boundaries, see Standalone Use.

Runtime context

These methods are safe to call from any request. They tell you whether the current request belongs to a Rudel environment and, if so, what that environment looks like.

`Rudel::is_sandbox()`

Returns true when the current request is a Rudel sandbox.

`Rudel::is_app()`

Returns true when the current request is a Rudel app.

`Rudel::id()`

Returns the current sandbox ID or null.

`Rudel::app_id()`

Returns the current app ID or null.

`Rudel::path()`

Returns the current environment directory path or null.

That directory contains the environment's local wp-content, which is the canonical file and code tree for the active app or sandbox.

`Rudel::engine()`

Returns subsite for active Rudel environments or null outside Rudel.

`Rudel::table_prefix()`

Returns the active environment table prefix or null.

In live requests Rudel resolves this from the active runtime context, not from hand-authored config. For subsite-backed environments that means the real multisite prefix for the current blog_id.

`Rudel::url()`

Returns the active environment's canonical site URL.

For sandboxes that is normally the multisite subdomain URL. For apps it is the primary mapped app domain when one is configured.

`Rudel::exit_url()`

Returns the network host root URL.

`Rudel::is_email_disabled()`

Returns whether outbound email is blocked for the active environment.

`Rudel::log_path()`

Returns the active environment debug log path, if any.

`Rudel::version()`

Returns the installed Rudel version.

`Rudel::cli_command()`

Returns the configured WP-CLI root command.

`Rudel::context()`

Returns the bundled runtime context in one array:

[
    'is_sandbox'     => true,
    'is_app'         => false,
    'id'             => 'alpha-1234',
    'app_id'         => null,
    'path'           => '/var/www/html/wp-content/rudel-environments/alpha-1234',
    'engine'         => 'subsite',
    'table_prefix'   => 'wp_2_',
    'url'            => 'http://alpha.localhost/',
    'exit_url'       => 'http://localhost/',
    'email_disabled' => true,
    'log_path'       => '/var/www/html/wp-content/rudel-environments/alpha-1234/wp-content/debug.log',
    'version'        => '...',
    'cli_command'    => 'rudel',
]

In practice, Rudel::context() is the easiest thing to hand to templates, custom admin screens, or API responses when you want one consistent runtime payload instead of a dozen point lookups.

The context payload is about the active site identity. For file and code operations, the important corresponding invariant is that the active environment's local wp-content under Rudel::path() is the canonical content tree for that environment.

Environment lifecycle

The environment lifecycle API is the programmatic counterpart to the wp rudel ... CLI commands.

`Rudel::all()`

List sandboxes.

`Rudel::get( string $id )`

Load one sandbox.

`Rudel::create( string $name, array $options = [] )`

Create a sandbox.

This still requires a live WordPress multisite runtime.

`Rudel::update( string $id, array $changes )`

Update sandbox metadata.

`Rudel::destroy( string $id )`

Destroy a sandbox.

This still requires a live WordPress multisite runtime.

`Rudel::cleanup( array $options = [] )`

Run cleanup policy.

`Rudel::cleanup_merged( array $options = [] )`

Remove sandboxes whose tracked branches have already merged.

`Rudel::snapshot( string $id, string $name )`

Create a sandbox snapshot.

`Rudel::restore( string $id, string $snapshot )`

Restore a sandbox snapshot.

`Rudel::templates()`

List saved templates.

`Rudel::save_template( string $id, string $name, string $description = '' )`

Save a sandbox as a template.

`Rudel::delete_template( string $name )`

Delete a template.

App lifecycle

Apps are the long-lived side of Rudel, so the app API adds backups, deploy planning, deployment history, rollback, and domain metadata on top of the normal environment lifecycle.

`Rudel::apps()`

List apps.

`Rudel::app( string $id )`

Load one app.

`Rudel::create_app( string $name, array $domains, array $options = [] )`

Create an app.

This still requires a live WordPress multisite runtime.

`Rudel::update_app( string $id, array $changes )`

Update app metadata.

`Rudel::destroy_app( string $id )`

Destroy an app.

This still requires a live WordPress multisite runtime.

`Rudel::create_sandbox_from_app( string $app_id, string $name, array $options = [] )`

Create a sandbox cloned from an app.

This still requires a live WordPress multisite runtime.

`Rudel::backup_app( string $app_id, string $name )`

Create an app backup.

`Rudel::app_backups( string $app_id )`

List app backups.

`Rudel::plan_app_deploy( string $app_id, string $sandbox_id, ?string $backup_name = null, array $options = [] )`

Build a dry-run deploy plan.

`Rudel::deploy_sandbox_to_app( string $app_id, string $sandbox_id, ?string $backup_name = null, array $options = [] )`

Deploy a sandbox into an app.

`Rudel::app_deployments( string $app_id )`

List deployment records.

`Rudel::rollback_app_deployment( string $app_id, string $deployment_id, array $options = [] )`

Rollback an app deployment.

`Rudel::restore_app( string $app_id, string $backup_name )`

Restore an app from a named backup.

`Rudel::add_app_domain( string $app_id, string $domain )`

Attach an additional domain to an app record.

This still requires a live WordPress multisite runtime because the underlying multisite subsite domain must stay in sync.

`Rudel::remove_app_domain( string $app_id, string $domain )`

Remove a domain from an app record.

A typical application flow

The methods read more naturally as a lifecycle than as a flat list. A common flow looks like this:

create or load an app
create a sandbox from that app
snapshot the sandbox if the change work is risky
plan the deploy
deploy the sandbox into the app
inspect deployment history or roll back if needed

If the app tracks a Git remote, branch, and directory, Rudel::create_sandbox_from_app() carries that metadata into the new sandbox automatically. That keeps later push and deploy operations aligned with the app's declared code source while still working inside the sandbox's own local wp-content.

The same flow also carries the app's URL contract forward: app-derived sandboxes rewrite from the app's canonical primary domain into the sandbox URL, and deploy-back restores the primary app domain again.

That is the same workflow the CLI exposes. The PHP API exists so higher-level tooling can drive it directly without shelling out to WP-CLI.

On this page