Why RustyAuth
Identity infrastructure
built to live everywhere.
RustyAuth combines a compact, passkey-first identity realm with an open-source Fleet control plane. Deploy identity where each product or customer needs it, then operate the estate without pulling credentials, signing keys or user records into one shared platform.
0.1.0 pre-release · Apache-2.0 · Claims separated from product direction
One operating viewRustyAuth FleetConfiguration · health · recovery
Fleet sees: operational state Fleet does not see: realm identity data
CategoryFleet-native identity infrastructure.
PromiseOne identity realm anywhere. One Fleet everywhere.
BoundaryCentral coordination. Local authority.
The differentiators
Not one enormous identity system.
A fleet of accountable boundaries.
The advantage is the combination: compact Rust runtime, passkey-first authentication, isolated state and a management plane designed around many realms.
01Fleet-native
Operate many boundaries as one estate.
Model organizations, products, environments and realms in one control plane without turning them into one shared identity database.
02Local authority
Keep identity inside its realm.
Users, passkeys, sessions, signing keys and recovery data stay with the application, customer or environment they belong to.
03Deliberately small
Understand the security-critical path.
A Rust-native authentication boundary focuses on passkeys, sessions, short-lived tokens, recovery and operations—not an unlimited identity workflow engine.
04Open by default
Own the deployment and the exit.
The Apache-2.0 core is free to run in your infrastructure. Fleet coordination does not require a hosted identity service or per-user contract.
A different scaling model
Scale by cells first.
Then scale inside a cell.
Both models are valid. RustyAuth chooses additional operational units in exchange for smaller trust, data and failure domains.
Traditional modelShared identity platform
Product AProduct BCustomer C
One logical boundaryIAM cluster + shared stateUsers · sessions · signing keys · policy
Optimises for: centralized administration, shared capacity and broad integration.
RustyAuth modelFleet-governed identity cells
Management planeFleetNo realm database access
Realm ALocal state
Realm BLocal state
Realm CLocal state
Optimises for: customer control, placement, failure isolation and local continuity.
One runtime · different boundaries
Put authentication where trust already lives.
Start with a standalone realm. Introduce Fleet when products, customers or environments turn one deployment into an estate.
01Available profile
AWS · eu-west
SaaS core
Keep the product realm close to the application and scale it as an independent cell.RustyAuth→Private state
02Fleet direction
Azure · private
Customer VPC
Place a customer-specific realm inside their network while retaining narrow Fleet visibility.RustyAuth→Private state
03Fleet direction
On-premises
Installed product
Ship the same compact identity boundary with local administration and separately verified recovery.RustyAuth→Private state
04Future profile
Disconnected
Secure enclave
Operate without a live control plane after offline release, crypto and assurance work is qualified.RustyAuth→Private state
The honest comparison
Different by architecture.
Not magically better at everything.
RustyAuth has a specific wedge. The established alternatives remain better choices when their strengths match the job.
Fleet-native identity cells
RustyAuth
Strongest fit
Independent app and customer realms governed as one estate.
Architectural difference
Current status ↗Narrower and earlier than every alternative here; OIDC interoperability, realm HA and independent assurance are still qualification work.
Lightweight Rust OIDC
Rauthy
Strongest fit
A mature lightweight Rust identity provider with passkeys, OIDC and HA deployment options.
Architectural difference
Rauthy documentation ↗The closest runtime competitor. RustyAuth is differentiating around a control plane for numerous autonomous realms, not one IdP or HA cluster.
Identity and directory platform
Kanidm
Strongest fit
Rust-based identity management with passkeys, OIDC, Unix integration and geographic replication.
Architectural difference
Kanidm documentation ↗Designed around a replicated identity domain. RustyAuth instead isolates application and customer realms that do not replicate identity data into Fleet.
Broad enterprise IAM
Keycloak
Strongest fit
Deep protocol, federation, directory and extension coverage backed by a large ecosystem.
Architectural difference
Keycloak documentation ↗Choose its breadth when you need it. RustyAuth targets a smaller operational surface and cell-by-cell placement instead of a shared general-purpose identity platform.
Flexible SSO and outposts
authentik
Strongest fit
Strong application access, proxy, LDAP and RADIUS workflows with centrally managed remote outposts.
Architectural difference
authentik outposts ↗Outposts extend authentik Core. RustyAuth realms are intended to remain complete local authentication boundaries when Fleet or the WAN is unavailable.
Scalable multi-tenant CIAM
ZITADEL
Strongest fit
Mature OIDC, OAuth and SAML capabilities with virtual instances and efficient centralized scaling.
Architectural difference
ZITADEL instances ↗Its virtual instances share a platform deployment. RustyAuth spends more infrastructure to gain physically separate realm state and failure boundaries.
Comparison reflects public product documentation reviewed 9 August 2026. It is deliberately qualitative: verify current capabilities against your own requirements.
Deliberate trade-offs
Every architecture has a bill.
This is the one we chose.
Trust comes from showing the costs as clearly as the advantages.
Isolation over consolidation
More realms mean more deployable units. In return, one customer, region or environment does not automatically become every other realm’s data and failure boundary.
A narrow core over feature abundance
RustyAuth does not try to replace an employee directory, a general authorization engine or every legacy federation protocol. Applications keep business authorization.
Local continuity over central dependence
Fleet receives less data and stays out of sign-in. That limits centralized analytics and requires explicit, privacy-preserving operational reporting.
Open ownership over hosted convenience
Self-hosting removes a mandatory identity vendor but makes deployment, monitoring, backup and upgrades your responsibility—or a managed service you choose.
Choose RustyAuth when
The boundary matters as much as the login.
- You need passkey-first authentication inside infrastructure you control.
- Products or customers require separate identity and signing-key boundaries.
- You want to govern deployments without centralizing their identity data.
- A compact, open-source runtime matters more than a huge integration catalogue.
- You can evaluate a pre-release product and help shape the Fleet operating model.
Choose an established provider when
You need breadth or assurance today.
- You require SAML, LDAP, SCIM or extensive upstream federation immediately.
- You need a long operating history, certified profiles or an existing enterprise support programme.
- Your preferred architecture is one centralized identity domain.
- You need sophisticated workforce identity workflows or directory management.
- You cannot accept pre-release software in the authentication path.
Evaluate the boundary
One realm locally.
Then see what Fleet changes.
Run the implemented authentication core with synthetic identities, inspect the data boundary, and decide whether the cellular model fits your product.