Portfolio visibility
See organizations, products, environments and realms through one operating model.
RustyAuth Fleet · Flagship control plane
Fleet-native
identity infrastructure.
Hierarchy and pairing implementedAnalytics V1 contract shipped0.1.0 pre-release
Central management planeRustyAuth FleetDashboard · Control plane · Private SableDB
01 · Railway · EU WestPayments APIProduction · HealthyRustyAuth Private SableDB
02 · AWS · LondonCustomer portalProduction · HealthyRustyAuth Private SableDB
03 · GCP · FrankfurtOperations suiteStaging · ReviewRustyAuth Private SableDB
04 · Customer cloudInstalled productProduction · IsolatedRustyAuth Private SableDB
Fleet connects to narrow management APIs—not realm databases.
The operating model
Central coordination.
Local authority.
Traditional central identity platforms often turn every product and customer into one large failure domain. Fleet coordinates independent realms instead. If the control plane is unavailable, sign-in, sessions, token verification, backups and local administration continue inside each realm.
Why Fleet
Manage the estate
without flattening it.
A consistent operating layer for leadership, platform teams and the architects protecting each deployment boundary.
Local isolation
Every realm keeps its own users, passkeys, sessions, signing keys, backups and SableDB.
Scoped control
Give platform, support and audit teams access only where their role and environment require it.
Cloud freedom
Place realms by customer, region or provider while Fleet remains one independent management plane.
Multi-cloud topology
Place authentication where the product—and the customer—needs it.
A realm can live in a different Railway project, public cloud, private network or customer account. Fleet keeps the operating model consistent without receiving that realm’s database credentials.
Web + native experienceFleet dashboardPortfolio · access · audit · health
→Central authorityFleet control planeHierarchy · pairing · policy
→Private stateFleet SableDBMetadata · roles · central audit
Revocable management connections
Realm 01Healthy
Railway · EU West
Payments API
ProductionRust backend→Private SableDB
Realm 02Healthy
AWS · London
Customer portal
ProductionRust backend→Private SableDB
Realm 03Review
GCP · Frankfurt
Operations suite
StagingRust backend→Private SableDB
Realm 04Isolated
Customer cloud
Installed product
ProductionRust backend→Private SableDB
The boundary that makes Fleet different
Customer identities, passkeys, sessions, tokens, signing material and recovery data stay in the realm. Fleet never receives a realm SableDB URL; it stores the organizational map and the minimum encrypted connection state required to manage it.
Read the control-plane architecture →Day-to-day management
From portfolio
to one realm.
Start with an organization, move through projects and environments, then act on a specific isolated realm.
01OwnershipOrganization
→Team and policy root
02ProductProject
→Application or service
03DeploymentEnvironment
→Development to production
04Trust boundaryRealm
One isolated auth runtime
Model the estate
Map organizations to products, environments and immutable realm registrations.
Pair safely
Connect through a short-lived code and a revocable, environment-scoped management credential.
Operate by role
Resolve inherited access on the server and record sensitive actions in a central audit trail.
Keep a local exit
Each realm retains local administration and continues authenticating if Fleet is unavailable.
Fleet Analytics
See the signal.
Keep identity private.
Fleet Analytics is designed to roll up operational facts—sign-in outcomes, latency, registration progress, backup age, key age and service health—without copying users, credentials, sessions or raw identity events into the control plane.
- Drill from authorized fleet scope to organization, project, environment and realm.
- Show reporting coverage so missing data is never presented as zero activity.
- Keep analytics failure completely outside the authentication request path.
Delivery status
Explore the analytics architecture →The V1 semantic contract and M10 reliable realm export are shipped. Canonical GreptimeDB serving, hierarchical reads and the live analytics dashboard remain staged M11–M14 work.
ScopeAcme portfolio / All projects
Last 24 hoursAuthentication success98.7%Across reporting realms
P95 authentication128 msMerged compatible histograms
Reporting coverage12 / 14Two realms marked stale
Oldest verified backup4h 12mAcross the selected scope
Authentication volumeCoverage-aware rollup
RealmHealthCoverage
payments-prodHealthy100%
portal-prodHealthy100%
operations-stagingStale72%
Start small · scale deliberately
One click for a realm.
One command for Fleet.
Evaluate the trust boundary first, then introduce central management when the estate needs it.
Deploy on Railway
The published template creates a self-contained RustyAuth evaluation realm with a public service and private, persistent SableDB connected over Railway’s private network.
Deploy an isolated realm ↗Pre-release · use synthetic accounts for evaluationLaunch the control plane
scripts/local-stack fleet upStarts the Dioxus Fleet dashboard, Rust control-plane service and private Fleet SableDB as a separate management project.
Open the quickstart →Separate every authority
Deploy Fleet independently, place each realm where it belongs, and pair them through scoped management endpoints. Back up Fleet and every realm separately.
Review deployment patterns →The published one-click Railway template currently deploys a standalone evaluation realm, not the complete Fleet management project. The three-service Fleet Railway topology is documented and remains release-gated.
Build the operating layer
Keep every realm independent.
Run them like one fleet.
Start with the implemented hierarchy and pairing flow, then follow Fleet Analytics as the runtime data plane moves through qualification.