The factory - Run every clone you have built from one place 
Each clone is a tenant with its own site_id. They share one Postgres and stay isolated by row-level security, so a studio running twenty sites pays for one database.
The default target. Production alias on every deploy.
Static output, served from the edge.
Run the pipeline and serve the build on your own box.
Policies are checked after every migration — one permissive rule defeats all scoping.
Every deploy upserts the site into the registry, with its URLs.
Each tenant gets its own admin login, scoped to its own content.
Rebuild and re-alias any tenant without leaving the CLI.
Chat, analytics and CMS are wired per tenant from the same codebase.
Every slot edit is timestamped, so you can see what changed and when.
Re-running a tenant reuses its capture and only rebuilds what changed.
Tenants share a single Postgres and stay isolated by row-level security, so the cost of the tenth site is the same as the second.
One project holds every tenant, keyed by site_id.
Natural-key tables are keyed per site, so slugs can repeat across tenants.
Slots, media and theme are rows you own — not a hosted CMS you rent.
Each tenant deploys to its own domain, from one shared codebase.
List, inspect, redeploy and open any tenant you have built.
xray factory status <site>
xray factory redeploy <site>
xray factory open <site>
xray factory dashboard
xray factory list
Every admin sees only its own tenant. Verified after each migration.
Adding a tenant is one command and no new infrastructure.
Every stage is runnable on its own , so a failed capture resumes where it stopped instead of starting over — and every flag has a sane default .
Rebuild, rebrand and ship, and keep the code in one command. Take a site from capture to production in hours, not sprints .
