Docs/Project
Status and roadmap
What is usable now, what remains deliberately gated and how RustyAuth moves from one realm to Fleet.Current release0.1.0
Support levelEvaluation
CompatibilityPin a release or commit
Capability matrix
| Capability | Status | Boundary |
|---|---|---|
| Passkey registration and sign-in | Implemented | Server-side, single-use ceremonies and durable sessions |
| Accounts and credentials | Implemented | Stable UUID, email/phone identifiers, profile and multiple passkeys |
| JWT and signing keys | Implemented | ES256, JWKS, staged rotation and retired-key overlap |
| Dioxus dashboard | Implemented | Web console and shared desktop/mobile feature builds |
| Fleet hierarchy and pairing | Implemented | Public-endpoint topology, scoped roles, audit and revocation |
| Fleet Analytics V1 | Contract shipped | Semantics and compatibility fixtures; durable projection remains |
| Encrypted backup and restore | Implemented | Logical snapshot, verification and empty-target recovery |
| Configuration as code | Implemented | Versioned YAML, schema, CLI validation and Docker/Railway inputs |
| Signed webhook delivery | Implemented on main | IaC or dashboard ownership, durable retry, history and replay |
| Account recovery | Not implemented | Required before production 1.0 |
| Email/SMS delivery | Not implemented | Events exist; challenge delivery and consumption remain |
| Independent security review | Not completed | Required before production 1.0 |
Product direction
RustyAuth supports two deployment styles without weakening realm isolation:
- Standalone: one project contains a Dioxus dashboard, one RustyAuth backend and one private SableDB for a single isolated realm.
- Fleet: a separate central dashboard, control-plane API and datastore manage organizations, projects and environments while each realm keeps its own three-service boundary.
SolidJS is retired from the shipped product path. Dioxus is the shared web, desktop and mobile presentation architecture; the Rust control-plane services remain the authority.
Before 1.0
- Ship account recovery and abuse/rate-limit controls.
- Complete durable Fleet analytics projection and private outbound telemetry.
- Qualify multi-writer behavior and cross-instance concurrency.
- Finish native credential transport, signed desktop updates and mobile packaging.
- Expand authenticator, browser and protocol-negative coverage.
- Complete an independent security assessment.
How to read status
Implemented means code and automated coverage exist in this repository. It does not by itself mean production-qualified. Contract shipped means the typed semantic boundary is reviewable and tested while a runtime projection may remain. Direction is not a product claim.
For the post-Fleet sequence, see the guided Fleet Analytics roadmap and its V1 semantic contract.
The normative roadmap, changelog and Fleet architecture preserve the detailed program.