Multisite Without Content Forks
Kugel Platform's multisite model: tenants, the fleet registry on the control plane, canary and stable release channels, genesis for new sites, and what still needs a person.
3 min read By Platform Documentation Guide #Multisite #Architecture
Multisite
Reuse the software, isolate the authority
Kugel Platform runs several websites from one codebase. Every site shares the same renderer, publishing engine, recipe library and agent tools, but each keeps its own objects, credentials, policies, members and deployment.
The result is reuse where it helps and separation where it matters: a fix to the engine can reach every site, while a content change on one site cannot touch another.
The terms
Tenant. One site, with its own object store, its own connection for agents and its own hosting project.
Engine. The shared code every tenant runs.
Control plane. This site. Its store holds the fleet registry, so any tool or agent that manages the fleet reads one place.
Tenant record. One registry entry per site: its class, the release channel it should be on, the engine version it runs and its status. Six sites are active today.
Release channel. Canary receives the newest engine first. Stable receives an engine only after the canary has run it.
How an engine change travels
An engine change lands first on the canary channel. It is promoted to stable only when the canary has run it, its smoke checks are green and no data migration is blocked. Promotion is controlled by a registry setting, can be paused, and can be rolled back with one command.
Each site records which engine version and data migrations it has applied, and keeps its own copy of its registry entry, refreshed hourly. If the registry is briefly unreachable, a site keeps serving on its last copy, while the tools that change the fleet stop rather than guess.
How a new site is born
A new site starts with a genesis request, usually from CMS-Agent, that names the site's class. Genesis reads the registry first and stops if it cannot. It records the new site as minting, scaffolds it from the shared template, creates its hosting project and storage, installs generated secrets, and seeds the starting objects: theme, navigation, taxonomy, editorial voice, the three standard forms and a thank-you page. An hourly sweep then adds the shared recipe library. Once a smoke check passes, the site's domain can be connected automatically, unless the site's class is set to require approval first.
A new site can also start from an existing public website. A capture workflow maps its pages, theme and images, and a clone workflow rebuilds them as governed objects on the new site.
What still needs a person, or proof
Registering a domain at a registrar without an API connection is still a manual step; the platform can generate a filled-in setup prompt for it. Mail and sign-in on a brand-new site are built into genesis but were not verified on a freshly minted site for this article.
The registry holds settings and status, not content. A site's pages and articles stay in that site's own store.