Separated control, storage, and transport boundaries.

1. Architecture principles

The architecture favors small, inspectable components over an expanded service mesh for the current control-plane scope. Each additional runtime dependency must justify its operational and security cost.

2. Logical components

The console presents the current model and accepted requests. It is not the execution engine for regional movement. This prevents a browser session from becoming a bulk-data transport channel.

3. Authenticated request flow

Browser
  │  HTTPS request
  ▼
Public gateway :443
  │  ordinary web traffic
  ▼
Nginx origin 127.0.0.1:8443
  ├── /assets, /docs, /security ... → static files
  └── /api/* → Control API 127.0.0.1:8090
                  │
                  ├── validate origin and JSON body
                  ├── resolve session and role
                  ├── verify CSRF for mutation
                  ├── persist requested state
                  └── append audit event + request ID

Authentication

The password endpoint verifies the assigned digest. A privileged identity receives a short-lived MFA challenge. Only after verification does the server issue the opaque session cookie and CSRF secret.

Read path

Static documentation is served directly by Nginx. Authenticated API reads resolve the session, read the bounded control record set, and return JSON with a request identifier. The audit endpoint returns at most the most recent one hundred events per request.

Mutation path

A mutation must pass origin, session, CSRF, role, schema, and domain validation. The operation is persisted before the response is returned. Accepted actions receive a generated resource or request identifier; denied operations do not alter requested state.

4. Persistence model

The control database uses SQLite in write-ahead logging mode. This is appropriate for the current single-node control API because it provides transactional state, durable audit records, consistent backup, and a limited operational footprint without an additional public database service.

Backups use the SQLite backup interface to produce a consistent database copy before release publication. Application files and origin configuration are preserved in the same versioned recovery package.

5. Deployment topology

The application runs as a dedicated system service under a non-login service account. Static assets are owned by root and served read-only. The database directory is restricted to the application identity. Nginx forwards only the API prefix to the application and serves known public paths from the static release directory.

6. Failure isolation

Control API unavailable

Static documentation and origin health can remain available while authenticated operations return a service error. Regional data movement continues according to previously accepted state; the UI does not claim that a failed submission was accepted.

Database unavailable

Session creation, recovery tracking, resource mutation, and audit reads fail closed. The service does not fall back to browser-only identity or unrecorded change execution.

Regional impairment

A regional storage or transfer condition is represented through health, alerts, incidents, and changes. It does not invalidate the identity boundary or grant direct access to regional payloads.

Origin failure

The gateway cannot complete ordinary HTTPS forwarding when the local origin is unavailable. Recovery uses the pre-release application and origin backup, followed by the same listener and firewall invariants.

Client interruption

Closing or refreshing the browser does not delete an accepted resource request. Persisted resources and user settings are loaded again after session restoration.

7. Dependency registry

The Integrations page is a registry of connector aliases and operating metadata. It is designed to expose enough information for operators to identify a dependency without publishing secret material. Provider documentation links are external technical references.

A registry state is not third-party assurance. Assurance claims and limitations are documented in the Trust Center.

8. Capacity and service objectives

Control-plane views distinguish an objective from a measurement. The published service objective for the interactive control plane is 99.95% monthly availability. Regional storage, replication, and worker objectives are displayed in operating views with their own scopes.

Capacity forecasts use current allocation and observed growth to estimate headroom. Forecasts are planning signals, not guaranteed exhaustion dates. Operators should investigate growth-rate changes, protection overhead, maintenance reserve, and regional imbalance before scheduling capacity work.

9. Architecture decisions