Platform

Everything Leumas puts on the internet — leumas.tech, every subdomain and every customer site, all of it Imperium output served by a Leumas-run Studio.

Platform

Everything Leumas puts on the internet.

leumas.tech, every *.leumas.tech subdomain, and every customer site — all of it Imperium output, all of it served by a Leumas-run Leumas Studio.

We are customer #1. We host our own platform with the product we sell, which is the only honest test of whether it works.

Companions: CONTROL-PLANE.md · APPLIANCES.md Execution: ops/todos/leumas-consolidation-roadmap.md

The thesis: everything ships twice

Every capability has two destinations from one build:

        shared/packages/<x>              the reusable guts — written once
                 │
                 ▼
 products/standalone/leumas-<x> a thin shell ──build──-> dist/
                 │
     ┌───────────┴───────────────────────────────────┐
     ▼                                               ▼
  a plugin any Studio installs                 an Imperium config
  monetized by the app store                   <x>.leumas.tech
  → APPLIANCES.md                              monetized directly
                                               → THIS DOCUMENT

Same artifact. Two revenue surfaces. Zero duplicated code.

What it is, mechanically

One renderer over a config store. A site is not a codebase — it is a row.

Piece	What it does
`configs` collection	every site: its `mode`, its `data`, its `appearance`, its hosting target
`@leumas/config-registry`	the ~30 modes a config can be — the vocabulary of what a page is
`@leumas/ui` `DynamicPage`	renders `mode + data`; one build serves every subdomain
`@leumas/hosting`	resolves an incoming host to a config, and to one of six targets

target ≠ mode. A target is how a host is served (config · proxy · server · static · bundle · redirect); a mode is what the page is. A host can point at a local app as easily as at a config.

Because a site is a row, adding one is a form — not a deploy.

What it covers

Lane	Examples
Core	`leumas.tech`, `api.`, `admin.`, `docs.`
Product sites	one per capability — the standalone that is also an app-store plugin
Customer sites	anything a Studio operator hosts, on our infrastructure or their own

How it relates to the other two

 APPLIANCES ── Studio hosts sites ──-> PLATFORM ──-> the public internet
                                            │
                                            └── its pages call CONTROL's public API
                                                (identity, membership, the store)

The platform is Imperium output. It is not a separate stack, and there is no "leumas.tech codebase" — there is a Studio with configs in it. That is the point: if the platform needs something Imperium cannot express, Imperium gets it, and every customer gets it too.

The boundary rule

Rendered by the one build, authored in Studio → Platform. The machinery doing the hosting → APPLIANCES.md. Leumas acting on a customer → CONTROL-PLANE.md.

Detail — the site catalog, connect-a-domain, request resolution, the modes, SEO, the cluster: ops/reference/platform-detail.md