Docs/Understand
Architecture
Independent presentation, policy and persistence services with explicit boundaries for one realm and for Fleet.One realm, three services
The Dioxus dashboard serves the operator and account experiences. It holds no authority of its own. The Rust backend validates every session, origin, role and mutation, then performs atomic identity operations against a private, volume-backed SableDB. Each service can be released and scaled independently.
Fleet is a separate management plane
The central Fleet project repeats the same separation: Dioxus Fleet dashboard, Fleet control-plane API and its own private SableDB. That datastore owns organizations, projects, environments, realm registrations, scoped roles, central audit and aggregated health. It is not a shared authentication database.
Every managed realm keeps its own backend, keys, users, credentials, sessions, SableDB and recovery boundary—even when it runs in another cloud. Fleet reaches a narrow realm management API using scoped credentials. It never accepts a tenant database connection string.
Protocol boundary
Browser WebAuthn ceremonies use HTTP/JSON. Dashboard administration uses binary Protobuf over Connect or gRPC-Web so browser sessions can remain secure HttpOnly cookies. Trusted Rust services use native gRPC over HTTP/2; service-to-service deployments should add TLS, mTLS or workload identity. Protobuf supplies a typed, efficient contract—not authentication or encryption by itself.
Analytics is an optional derived plane
Fleet Analytics projects bounded five-minute snapshots inside each realm, sends full revisions over a realm-initiated authenticated channel and stamps organization, project and environment only at the trusted Fleet gateway. Canonical realm buckets feed environment, project, organization and fleet results; higher-level rates and percentiles are never averaged from child summaries.
The preferred GreptimeDB store is private behind the Fleet API. S3-compatible Parquet is an approved archive and repair path, not a dashboard query path. Analytics outages change freshness and coverage only—they never enter the authentication dependency chain.
Durable state and recovery
SableDB is the online source of truth. Logical snapshots are sorted, tenant-bound, compressed and authenticated with AES-256-GCM before upload to private S3-compatible storage. Restore only accepts an empty target and invalidates sessions by default. Realm and Fleet backups remain separate because their failure and ownership boundaries are separate. The backup and disaster-recovery guide documents the complete state boundary, binary envelope and provider contract.
Signing-key lifecycle
RustyAuth prepublishes each replacement ES256 public key, activates it after the configured JWKS cache window and retains the retired public key until every old access token has expired. Private signing material is encrypted in SableDB and can be rewrapped during master-key rotation.
Responsibility split
- The Dioxus client renders state and initiates commands; it is never the authorization boundary.
- The realm backend proves identity and owns credentials, ceremonies, sessions, signing keys and authentication claims.
- The Fleet backend owns central hierarchy, operator policy, realm connections and fleet-wide projections.
- Your application owns business authorization, permissions, entitlements and resources.
- Private SableDB services and backup buckets are never browser or integration APIs.
Read the complete architecture reference for state keys, flows and failure semantics.