Introduction

Rudel manages WordPress sandboxes and apps as real subdomain multisite sites.

Every Rudel environment has a real blog_id, a real URL, normal wp-admin, normal REST requests, normal asset handling, and its own isolated users. Each one also has its own cloned wp-content, which Rudel treats as the canonical file and code tree for that environment. Rudel uses that site identity plus that local content tree as the base for everything else it does: creation, cloning, templates, backups, deploy history, worktrees, and lifecycle policy.

WordPress answers the browser question. Rudel answers the operator question. WordPress knows how the site boots and where it lives. Rudel knows why the site exists, what it belongs to, how it was created, and what should happen to it next.

Two environment types

Rudel has two lifecycle shapes that share the same runtime model.

Sandboxes are short-lived sites for change work, QA, debugging, demos, and agent-driven development. They are where you clone an app, try a change, snapshot state, review a result, and then either destroy the site or fold the work back into a stable app.

Apps are long-lived sites that hold stable runtime state. They are the sites you keep around, attach domain metadata to, back up, deploy into, and restore from over time.

Both are normal multisite sites. The difference is not in how the browser reaches them. The difference is in how Rudel manages their lifecycle.

For apps, Rudel adds one more layer on top: a primary mapped app domain becomes the canonical app URL Rudel reports through its API, CLI, and deploy history. The underlying multisite subsite still exists as the runtime substrate.

Runtime shape

Rudel keeps two layers in sync.

WordPress multisite sites are the routing and site-state truth. Every Rudel environment is backed by a real multisite site with native per-site tables, site options, uploads, admin behavior, browser routing, and its own isolated users.

Environment-local wp-content trees are the file and code truth. Each app and sandbox runs against its own cloned wp-content, and any git worktrees Rudel creates live inside that environment-local tree.

Rudel runtime records are the operational truth. Rudel stores environment metadata, app identity, domain metadata, worktrees, deployment history, and lifecycle policy in WordPress tables so it can reason about environments explicitly rather than inferring state from directories and URLs.

Use WordPress for site truth, the environment directory for file truth, and Rudel runtime tables for lifecycle truth. WordPress answers where a site lives and how it boots. The environment-local wp-content answers which code and uploads belong to that environment. The environment-local db.php answers which isolated user tables belong to that environment. Rudel answers who owns it, what app it came from, which worktree belongs to it, and which backup belongs to which deployment.

What Rudel adds

The runtime is native multisite. The value Rudel adds is everything around the lifecycle:

• environment creation and destruction
• app creation from the same runtime model
• app-derived sandboxes
• snapshots for sandboxes
• backups, deploys, and rollback for apps
• reusable templates
• generic Git remote push workflows and local worktrees
• policy metadata such as owner, labels, protection, and expiry

Rudel gives those sites an explicit operational surface.

Requirements

Rudel requires a subdomain multisite network. That is a hard requirement because the runtime contract depends on WordPress owning the site routing.

In practice that means:

• PHP 8.2 or later
• WordPress 6.4 or later
• a subdomain multisite network
• write access to wp-config.php during initial runtime installation

If that foundation is in place, Getting Started walks through installation and the first sandbox/app creation flow.