# 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.


**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](CONTROL-PLANE.md) · [APPLIANCES.md](APPLIANCES.md)
Execution: [ops/todos/leumas-consolidation-roadmap.md](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](APPLIANCES.md)**.
> Leumas acting on a customer → **[CONTROL-PLANE.md](CONTROL-PLANE.md)**.

---

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


---
Source: PLATFORM.md
Canonical: https://docs.leumas.tech/p/architecture/platform