The factory

Run many clones from one database, isolated per tenant by row-level security.

One database, many sites

A studio running twenty clones does not want twenty databases. In shared mode every clone is a tenant in one Postgres, identified by a site key and isolated by row-level security.

xray https://example.com --site example --shared

How isolation works

Core tables carry a site column, and natural-key tables use composite keys so slugs can repeat across tenants.
Policies scope every authenticated read and write to the tenant the signed-in admin belongs to.
Public content is readable anonymously; anything a visitor submits is insert-only and readable by admins alone.

Policies combine with OR. One leftover permissive policy defeats every scoped one, and the symptom — an admin seeing another tenant's content — looks like a bug in the application. Audit the policy list after any change to the schema, not just the one you edited.

One admin per tenant

Each tenant gets its own admin login. Giving several tenants the same login collapses them onto one profile, and whichever was wired last wins — so admin accounts are per site, not per person.

Managing the fleet

xray factory list
xray factory status <site>
xray factory redeploy <site>

Every deploy records the tenant and its URLs, so the registry stays current without a separate step.

When to keep a clone separate

Shared mode suits marketing sites. Give a clone its own database when it carries meaningful personal data, when a client requires their data to be physically separate, or when it runs a shop — commerce tables are wide enough that sharing them is not worth the coupling.