Administration & Configuration
Administering System9 happens through two distinct surfaces, each backed by an engine documented elsewhere on this site. This section ties the frontend an operator actually touches to the backend mechanism it drives, one story, not two.
- The operator console, in the product itself, where an operator runs the estate: cells and fleet, worker policy, the unified config-policy surface, deployment presets, and the workspace / clean-room consoles where residency, automations, and the activity ledger live.
- The administrator portal, the org-facing web portal for provisioning deployments, managing licenses and billing, and platform-staff administration.
The rest of the platform docs describe each capability's engine from the inside; this section is the administration view, where the switch is, who may throw it, and what happens when they do.
The two administration surfaces
Figure: the two administration surfaces and the engines they drive. The
operator console authors worker policy and deployment presets (through a
system-token-gated BFF), drives fleet releases, and reaches the workspace /
clean-room services under a membership capability. The administrator portal
provisions cells, licenses, and billing under a layered isSiteAdmin + org-role
gate, with a license-entitlement layer.
Table equivalent
| Surface | Repo home | What an operator does | How it is gated |
|---|---|---|---|
| Core System console | operator app | Worker policy, deployment presets, fleet releases, activity ledger, cells & topology | Per-page self-gate on a capability, or a system-token-gated BFF |
| Workspace / clean-room console | operator app | Residency, automations, activity, and per-scope governance | Membership capability (e.g. workspaces.console.read) |
| Administrator portal | site portal | Provision deployments, licenses, billing, org admin | Auth → org role → isSiteAdmin layers, plus license entitlement |
Two surfaces, two gating models
The two surfaces authorize very differently, and knowing which model applies is half of administering the platform safely.
The operator console gates per surface. Some pages self-gate on a
capability read from the caller's permissions, the Fleet surfaces, for example,
check explicit system.fleet.* capabilities (see
Config deployment), and
the workspace tabs check a membership capability such as workspaces.console.read.
the unified Config Policy
surface self-gates on system.cells.inspect / system.cells.manage (deny by
default, read-only banner without write), and the backend additionally honours a
per-section delegated permission. Others perform no client-side check at all
and rely entirely on the backend: the Worker Policy
console renders unconditionally and is guarded by a system-token-gated BFF plus
the value gate at the control plane. Where a surface has no frontend capability
string, this section says so.
The administrator portal layers three gates: the portal layout requires
authentication; a per-org role (owner / admin / member / billing) gates
org actions like managing deployments or billing; and an isSiteAdmin
platform-staff flag gates everything under the admin area, re-checked against the
database on each sensitive page rather than trusted from the session token alone. A
separate license-entitlement layer maps a license class to feature visibility
(show / tease / hidden).
The portal's capability-manifest (license entitlement → feature visibility) is a
complete, tested mechanism, an org-scoped manifest endpoint, an entitlement hook,
and a gate component, but it is not yet wired into any portal page; today the
live gates are the auth / role / isSiteAdmin layers above. The entitlement layer
is present and ready, not load-bearing.
How configuration deploys
Configuration is declarative desired state. An operator declares intent once, as a Deployment preset or a hand-authored Worker Policy, the platform signs it, and every cell resolves it, reconciles to it, and attests what it ran. The full cycle, and how a preset authors Worker Policy for you, is in Config deployment.
What's covered
| Page | The whole story it tells |
|---|---|
| Access control | The three lenses: edit a securable's grants and denies, explore what a principal holds, and simulate a decision before making it, plus the one-plane model for administrative authority |
| Worker Policy | The console where an operator authors, previews, applies, and break-glasses per-cell worker policy, and the signed engine that resolves, reconciles, and attests it. |
| Config Policy | The one signed, topology-scoped plane where every cell setting: the nine administrative sections plus services such as Flight SQL: is authored, under tiered delegated authz and a tamper-evident config-change audit. |
| Config deployment | The declarative fleet-config cycle: Deployment presets, Fleet Releases, and portal provisioning, with the surfaces that drive each. |
Administration in the rest of the docs
Several administered capabilities are documented with their engine; each now carries an "In the console" section tying the operator surface (route and gating capability) to that engine:
- Roles and permissions, the catalog behind the Access control console: the three permission planes, all 48 built-in roles and what each is for, and the scope a grant attaches at.
- Configurable workers, what a worker is; governed from the Worker Policy console.
- Data residency, the residency tab in the workspace / clean-room console.
- Automations, the reactive-rules tab.
- Activity Ledger, the ledger's node and workspace surfaces.
- The licensing lifecycle, the license apply and enforcement surfaces, in the console and the portal.
- Edge & fleet management, the fleet and topology console surfaces.