Operational topology

Deployment

One public RustyAuth service and one private, persistent SableDB service.
Public edgeRustyAuth

TLS terminated · health checks · one writer in 0.1

Private networkSableDB

No public endpoint · persistent volume · internal port 6379

Private storageBackup bucket

Encrypted snapshots · retention · clean-room recovery

One-click Railway deployment

The Railway template creates both services inside the RustyAuth template group, generates the master key and bootstrap token, links SableDB over the private network and attaches its persistent volume. You supply the browser application's exact HTTPS origin and matching WebAuthn RP ID during the environment step.

Deploy on Railway

RustyAuth remains pre-release software. Use the template for evaluation and integration work, not as the sole identity system for a production service.

Container deployment

The supplied container builds the Rust service as a non-root user. Deploy the SableDB container separately on the same private network and attach a durable volume at its documented data path.

Scaling

The authentication service is lightweight and can scale vertically with predictable resource use. Version 0.1 intentionally supports one writer replica while cross-process identity mutations are qualified.

Backup and recovery

Adding the complete backup environment enables authenticated logical snapshots at startup and every six hours by default. Operators can run backup create, backup list, backup verify <object-key> and backup restore <object-key>. Restore requires an empty SableDB namespace and invalidates sessions by default.

Drill the recovery path

Bucket credentials are not evidence of recoverability. Restore a selected object into a clean volume, run doctor, and verify a real passkey sign-in on a regular schedule.

Use the backup and key-rotation runbook for the complete operator workflow and safe key-overlap rules.