Domain Configuration Apps

Configuration and secrets live in the app that owns their domain (policy domain-config-apps). There is one app for AI providers and their keys, one for databases, one for sign-in, and so on. A person who wants to change the AI setup of a deployment opens the AI app, not the deployment's record page, and finds every AI setting and every AI key there.

This page is the design: the inventory of what exists today, the app map, and what each app reads, writes and gates. It builds on three existing pieces and invents none of their parts:

• The Admin App: /Admin on every instance, the home of instance-level admin settings;
• Secrets: Write-Only Entry, Split Identities: every secret is entered through a write-only control and written by the governed writer identity, never by hand;
• Instance Secrets: the platform's WriteOnlySecretSection / SecretInventorySection controls and the instance's own encrypted store.

Why: the record page became a junk drawer

Every new need for a config value or a secret on a live deployment landed as another button, dialog or panel on the control instance's Deployments/<id> page: Set Key Vault secrets… (a paste dialog over every vault object the record names), a vault-secrets inventory, an announcement-key panel. Each was reasonable alone. Together they made the record page the one place where everything is typed, with no grouping by what the value is FOR. Someone rotating an OpenRouter key had to know which vault object name the chart maps to OpenRouter__ApiKey. Someone checking a deployment's EU residency had to read JSON.

The domain is the unit people think in. The apps group by domain, and the record page goes back to being the record: identity, status, fields, and links to the apps.

Two scopes, one set of domain names

A setting belongs to exactly one of two scopes, and the scope decides where its app lives:

Both scopes use the same six domain names, so a person finds the same word in both places: AI, Databases, Sign-in, Email, Payments, Integrations.

Why the fleet apps are separate apps and not Admin-app tabs

The Admin app exists on every instance and administers THAT instance. A fleet domain app administers OTHER instances, one deployment at a time. It exists only where the Hosting package is installed (the control instance), and every page carries a deployment. Putting it inside /Admin/Settings would mix "this instance" and "that deployment" on one page, which is the same confusion the record page had. So the control instance's Admin app LINKS to the six fleet apps; it does not host them.

The app map

Fleet apps — control instance, Hosting package

Each app is one node in the Hosting package: the NodeType Hosting/{X}App (sources Hosting/{X}App/Source/) and the app node Hosting/{X} of that type. All six share one shell, Hosting/DomainApp/Source (the picker, the record resolution, the admin gate, Apply). The default area Deployments is a deployment picker (every Hosting/Deployment record the viewer may read). The per-deployment page is the area Deployment with the deployment id as area id, so every page is deep-linkable.

Instance scope — each instance's Admin app

These are tabs of /Admin (see The Admin App), grouped under the same domain names:

A person's own AI keys are neither. They belong to the person, not to an admin, and stay in the person's providers app (Providers/ProvidersApp, the ProviderSetup view: enc: in the mesh, write-only).

The announcement key: generated on the target, registered on the control instance

Target design, not yet the procedure. Until MeshWeaver.Plugins#2435 lands, the shipped procedure is the one in Self-Update Announcement Key: the control instance ISSUES the key and the target's administrator enters it. Follow that page to operate today. The change set that moves the flow here also rewrites that page and the Instance Secrets summary.

The key that signs a deployment's self-update hand-over is generated where it is used: on the target instance, in its Admin app's Control lane tab (InstanceSecrets Hosting:ControlInbox:Secret, live, no restart). The control instance only has to VERIFY signatures, so it holds the same value under the per-sender slot Hosting:PlatformWebhookSecret:{id}. The Integrations app's Announcement key section is a WriteOnlySecretSection over that slot: an admin pastes the key the target generated, and the page shows both fingerprints side by side, so a match is visible without either value being shown. The deployment record keeps only the vault object's NAME (announcementKeySecret) for the case where the key is mounted rather than entered.

What every fleet app page is made of

Every per-deployment page is the same three pieces, and none of them is new:

1. The record's block, bound to the record. The form is the framework's form generator over the block's type (ModelProvider, ModelTiers, SignInSpec, EmailSpec, …) with a node-bound data context pointing INTO the record: LayoutAreaReference.GetMeshNodeDataContext(recordPath, bindContent: false, subPath: "content/ai/openRouter"). Every field reads from the record's node stream and writes one field back through GetMeshNodeStream(recordPath).Update(...). There is no /data copy and no Save button (see Data Binding). A viewer without Update on the record gets the same form read-only.
2. The domain's vault objects, write-only. A SecretInventorySection over the record's declared vault objects whose config key belongs to the domain (the AI app claims *__ApiKey of the AI sections, the Sign-in app Authentication__*__ClientSecret, …). Save and Generate file a governed SetSecrets action; Disable/Enable/Delete/Recover file a SecretLifecycle action; the status list is the operator's hosting-kv-status reading (names, states, fingerprints; never a value). A domain claims config keys by prefix (VaultSecretDomains, next to the Plugins VaultSecretSteward that files the actions), so a module that adds a provider adds its key to the AI app by naming it, with no change to the app. An object no domain claims is counted on the picker, never dropped silently. 🚨 Ai__KeyProtection__MasterKey belongs to NO domain, although its name starts with Ai__: it encrypts every enc: value on the instance (instance secrets, every person's provider keys), and replacing it makes all of them unreadable. It is a platform root key, changed only as break-glass, and no app lists it.
3. Apply. A button that files a governed Reconcile for this deployment. The record edit alone changes nothing on the running portal: a pod reads its configuration at start. Reconcile renders the record into helm values, runs the upgrade, and restarts when a secret class changed. It needs approval like every other non-read action, so the page shows the action it filed and links to it rather than a success message.

Everything on the page is platform controls in a real layout (Stack, DataGrid, the form generator, WriteOnlySecretSection); no page builds its own form or markup.

Who may use which app

A global admin of a customer instance is not a global admin of the control instance, so a customer can never change its own recorded shape through a fleet app. That is intentional: the record is the operator's contract.

How a change reaches the running portal

The record is git-synced to Systemorph/Memex, so every fleet edit is also a commit, and the history of a deployment's AI setup is that file's history.

What the Deployment record page keeps

Identity, purpose, status and audit strips, the field table, the outbound links, and ONE link row to the six domain apps for this deployment. It carries no secret entry of its own: the Set Key Vault secrets… dialog, the vault-secrets inventory button and the announcement-key panel move to the apps above.

Inventory: every entry point today, and where it moves

Build order

1. AI app — the most-edited block, and the one the EU residency work already reshaped. First, end to end: picker, bound ai form with the badges, the AI vault section, Apply.
2. Integrations — it unblocks MeshWeaver.Plugins#2435 (the announcement key), which is held for exactly this.
3. Sign-in, then Email — small bound blocks and one or two secrets each.
4. Databases — the widest: fields, three secrets, migration status and backups.
5. Payments — needs a payments block on the record first, so it is last.

After each app lands, the Deployment page loses the matching surface. The dialog goes when the last domain claims its last key.

Related

• The Admin App — the instance-scope home
• Secrets: Write-Only Entry, Split Identities — the vault half
• Instance Secrets — the instance's own store and the write-only controls
• Self-Update Announcement Key — the key the Integrations app registers
• Deployment on AKS — how the record renders into the chart
• Data Binding — the node-bound form every app page uses